Комментарии 4
извиняюсь, если в статье уже объяснено, но...
почему 16 байт? а не 23
По сути можно использовать последний байт как индикатор на стеке строка или хипе. Тогда первые 23 - свободный буфер. Длину строки на стеке думаю можно и за O(n) посчитать.
Кстати можно использовать 0 для последнего байта, если строка на стеке, и что угодно иное если на куче. Благодаря этому можно ещё и нуль-терминированную строку будет вернуть для совмести с Си
Ну и максимальный размер строки в таком случае будет 2^56) Хотя это вряд ли кого-то огорчит.
По-моему у Александреску есть замечательный доклад на эту тему. Он когда-то проектировал такую строку для folly, если не ошибаюсь
UPD:
ага, я понял. У вас строка всего 16 байт.
Но тогда не понятно почему по той же логике не 15 для SSO
Есть отличный доклад на эту тему. Если кратко, то приходится выбирать между оптимальным layout (как следствие максимальной вместимостью) и производительностью.
Если расположить в capacity (равно как и в любом другом месте, например, в старший/младший бит ptr, size) некий флаг SSO (обычная строка или оптимизированная small string), то в каждый data(), каждый c_str() и size() необходимо добавляется if. Что помешает оптимизаторам (равно как и процессорам) творить "магию" (branch prediction и проч.)
Потому и имеем под полезную нагрузку: 15 байт + 1 байт под NULL. А строка (объект) как правило занимает сегодня 32 байта (не 24 байта).
Все написанное применимо к C++, наверняка косвенно применимо и к Rust.
Круто! А производительность создания, сравнения проводили?
Почему за математиков больше?
Оптимизация, которая невозможна в Rust