DS
Понял, впервые слышу о таком
Ну вектор он же универсальный, он должен учитывать что его элементы могут иметь нетривиальные конструкторы копирования и т.п. А string как то больше ориентирован на Char как literal type.
Size: a a a
2020 June 28
D
Ну логично что копирование надо делать через memcpy. Для string это сдано в traits::copy. А вот вектор вызывает std::copy, а там уже перегрузка которая определяет можно ли memcpy. Результат тот же, но traits дешевле для компилятора, это не перегрузки для trivially copyable.
Так она же в любом случае в compile time определяет. Есть ли особая разница?
DS
Так она же в любом случае в compile time определяет. Есть ли особая разница?
Не знаю, может и нет. Просто предполагаю что явный вызов traits::copy для компилятора проще чем выбор перегрузки, может сократить compile time.
DS
Так она же в любом случае в compile time определяет. Есть ли особая разница?
Ну или другой пример, сравнение. Может vector compare соптимизироваться в memcmp?
D
Ну или другой пример, сравнение. Может vector compare соптимизироваться в memcmp?
Он использует std::equal - а та может оптимизироваться в memcmp
VS
Зачем тебе ABI стандарте?
50 лет не было - как-то жили все люди.
50 лет не было - как-то жили все люди.
И получали задницу после смены или обновления компилятора, в лучшем случае неразрешенные символы, в худшем - сегфолты из-за изменения формата внутренних структур
IZ
И получали задницу после смены или обновления компилятора, в лучшем случае неразрешенные символы, в худшем - сегфолты из-за изменения формата внутренних структур
Так пересобери, и всё.
EP
Так пересобери, и всё.
у проприетарщины часто исходников нет
VS
Так пересобери, и всё.
Или держи тучу версий libstdc++, да. Про Qt я вообще молчу.
ПК
у проприетарщины часто исходников нет
У такой проприетарщины и интерфейс должен быть ABI стабильный. Например, сишный или aka COM
DS
В С++20 не появилось ничего нового для передачи и хранения кусков сырых данных с неизвестным во время компиляции размером? Использовать для этого
std::vector<uint8_t / std::byte>?Во, идея для proposal:
- добавить std::ubyte как unaliased byte для "сырых" массивов байтов
- добавить std::char_traits<ubyte>
- zero-termination requirement как часть char_traits
- добавить специализации ubstring, ubstring_view
- добавить std::ubyte как unaliased byte для "сырых" массивов байтов
- добавить std::char_traits<ubyte>
- zero-termination requirement как часть char_traits
- добавить специализации ubstring, ubstring_view
A
А я ж могу объявить std::basic_string<std::byte>?
Да
DS
А я ж могу объявить std::basic_string<std::byte>?
Только определив самостоятельно специализацию std::char_traits<std::byte>.
DS
Хм. А для uint8_t есть char_traits в библиотеке?
N
Во, идея для proposal:
- добавить std::ubyte как unaliased byte для "сырых" массивов байтов
- добавить std::char_traits<ubyte>
- zero-termination requirement как часть char_traits
- добавить специализации ubstring, ubstring_view
- добавить std::ubyte как unaliased byte для "сырых" массивов байтов
- добавить std::char_traits<ubyte>
- zero-termination requirement как часть char_traits
- добавить специализации ubstring, ubstring_view
кстати, а чем char8_t не подойдет?
DS
кстати, а чем char8_t не подойдет?
Тем что для ubyte например можно определить свои std format спецификации, типа hex/base64 например.
N
Тем что для ubyte например можно определить свои std format спецификации, типа hex/base64 например.
ну тогда ток старое доброе
enum class ubyte : unsigned char {};