KO
и есть код который делает сначала условный memcpy(&int64_val, ar.begin())
Size: a a a
2020 December 07
KO
а потом который делает *int64_val = *reinterpret_cast<int64_t*>ar.begin())
KO
про memory alignment давайте забудем на секнуду и разберёмся со strict aliasing.
IZ
тут вместо char в коде за каким-то лядом для сериализованного представления используется int8_t. Зачем, почему не char, не byte, а int8_t - отдельный, важный, блин, вопрос, но не в этот канал.
Это не очень важно. int8_t наверняка внутри - signed char.
KO
signed char как раз не в списке similar types :(
KO
byte, char и unsigned char в списке.
KO
дык это разные типы :(
D
дык это разные типы :(
Именно
ПК
а int8_t* и int64_t*?
Да, если int8_t это char
ПК
а могу ли я char* к int64_t* скастоватЬ?
Можешь если там реально int64
m
про memory alignment давайте забудем на секнуду и разберёмся со strict aliasing.
С алиасингом проблемы нет, если
Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
int8_t является тайпдефом char. Но есть проблема с лайфтаймом. Чтобы прочитать int64_t его нужно создать по этому адресу. И, кажется, даже С++20 здесь не поможет с implicit object creation, так как я не видел чтобы оно распространялось на std::array. Поэтому лучше memcpy делать сразу в std::array<int64_t, 2>.Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
AP
На SO тогда нашёл обсуждение смежной темы
https://stackoverflow.com/questions/12612488/aliasing-t-with-char-is-allowed-is-it-also-allowed-the-other-way-around
https://stackoverflow.com/questions/12612488/aliasing-t-with-char-is-allowed-is-it-also-allowed-the-other-way-around
d
С алиасингом проблемы нет, если
Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
int8_t является тайпдефом char. Но есть проблема с лайфтаймом. Чтобы прочитать int64_t его нужно создать по этому адресу. И, кажется, даже С++20 здесь не поможет с implicit object creation, так как я не видел чтобы оно распространялось на std::array. Поэтому лучше memcpy делать сразу в std::array<int64_t, 2>.Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
кстати, а ведь для int8_t может быть прописан и signed char, а для uint8_t начиная с 20ых плюсов может быть char8_t, и вот тут точно не будет исключения из правила про алиасинг
KO
С алиасингом проблемы нет, если
Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
int8_t является тайпдефом char. Но есть проблема с лайфтаймом. Чтобы прочитать int64_t его нужно создать по этому адресу. И, кажется, даже С++20 здесь не поможет с implicit object creation, так как я не видел чтобы оно распространялось на std::array. Поэтому лучше memcpy делать сразу в std::array<int64_t, 2>.Совсем недавно обсуждали очень похожий вопрос: https://t.me/ProCxx/417256
удивительно как много всяких невероятных магических пони есть у стандарта, таких как "конструирование" объекта int64_t
m
удивительно как много всяких невероятных магических пони есть у стандарта, таких как "конструирование" объекта int64_t
Суть strict aliasing'а в том, что в С++ по одному адресу не могут находится два разных объекта (с некоторыми оговорками). Это позволяет оптимизатору генерировать более оптимальный код. Все остальное вытекает из этого.
VS
а. ну так-то можно хоть массив байтов в дабл преобразовать с reinterpret'ом
нет, такое можно только через
bit_castVS
а потом который делает *int64_val = *reinterpret_cast<int64_t*>ar.begin())
здесь UB не в касте, и даже не в разыменовании, а в чтении значения через результат разыменования — нарушение strict aliasing именно в этом
соответственно, int8_t* к int64_t* можно кастить, если делать только это — reinterpret_cast такое поддерживает
соответственно, int8_t* к int64_t* можно кастить, если делать только это — reinterpret_cast такое поддерживает
KO
Я не понял сейчас.
KO
Вроде как договорились, что если два типа - similar, то можно один читать через другой? (читать например int через указатель на unsigned int можно)
KO
(если оставить в стороне lifetime issues, за ссылку на которые отдельное спасибо)