большой и прямой порядок в безумии Facebook
Я прочитал код глупости, созданный Facebook ， На этой странице https://github.com/facebook/folly/blob/master/folly/FBString.h ,Я обнаружил, что автор рассматривает порядковый номер с прямым и обратным порядком байтов, когда он устанавливает какое-либо значение, такое как емкость_, код выглядит следующим образом:
void setCapacity(size_t cap, Category cat) {
capacity_ = kIsLittleEndian
? cap | (static_cast<size_t>(cat) << kCategoryShift)
: (cap << 2) | static_cast<size_t>(cat);
}
Я хочу знать, почему автору следует учитывать порядковый номер с прямым и обратным порядком, я думаю, что нам не нужно рассматривать их на одной и той же машине, получая и устанавливая стоимость имеют дело с машинами, и мы можем их игнорировать
Решение
Эта строковая реализация обладает определенным умением распределять память в зависимости от размера строки. особенно Вот Вы можете найти, где объединение используется для обмена стратегиями.
На 64-битной машине с 8-битными символами структура MediumLarge имеет длину 24 байта и может содержать 24 символа. Однако два бита из последнего байта зарезервированы для определения стратегии хранения, поэтому короткие строки могут иметь длину до 23 символов.
Именно эта вещь «последнего байта» оправдывает необходимость беспокоиться о порядке байтов: этот «последний байт» является самым старшим адресом, и, следовательно, на машине с прямым порядком байтов, и эти флаги хранятся в двух старших битах, и вы можно извлечь длину емкости, маскируя эти два бита. На старшем байте последний байт является наименее значимым байтом, флаги хранятся в двух младших битах, и вы можете извлечь емкость, выполнив 2-битное смещение вправо.
Теперь тот факт, что код использует kIsLittleEndian и условный оператор для переключения между этими поведениями, кажется, предполагает, что эти проверки происходят во время выполнения. Тем не мение, kIsLittleEndian объявлен как constexprи все условные выражения могут быть оценены во время компиляции.
Другие решения
Других решений пока нет …