Здравствуйте, Mr.Delphist, Вы писали:

BZ>>>но это же займёт целых два такта! как можно в форуме C++ такое святотатство предлагать...
MD>·>Тогда можно переписать как
MD>·>data[2] = 255; data[3] = 255;
MD>·>чтобы оно распараллелиось.
MD>Вы троллите, или в самом деле полагаете, что работу с двумя соседними байтами планировщик отдаст двум ядрам, а затем доблестно будет бороться с рассинхронизацией ядерных кэшей?

Записано же в одну строчку, значит, распараллелится

Здравствуйте, Mr.Delphist, Вы писали:

MD>Вы троллите, или в самом деле полагаете, что работу с двумя соседними байтами планировщик отдаст двум ядрам, а затем доблестно будет бороться с рассинхронизацией ядерных кэшей?

Вы троллите, или о каком таком планировщике идёт речь??

Здравствуйте, HAXT, Вы писали:

HAX>Помогайте коллеги,

HAX>есть массив элементов char

HAX>unsigned char data[255]; (255 по 1 байту каждый)

HAX>нужно начиная с третьего его элемента записать значение unsigned short (2 байта)

HAX>почему-то так не получается
HAX>(unsigned short*)(data[2]) = 65535;

HAX>пишет expression must be a modifiable lvalue

HAX>а мне нужно этой операцией перезаписать 2 байта в этом массиве, 2, и 3 по индексу с нуля

Объясни, почему именно элементы по 2му и 3му индексу. Может быть, на самом деле там какая-то структура? Тогда почему бы к ней сразу не привести?
Типа

struct MyCoolFormat
{
    uint8_t foo, bar;
    uint16_t myvalue;
};

...
unsigned char data[255]; (255 по 1 байту каждый)
// получаем данные
MyCoolFormat* mcf = reinterpret_cast<MyCoolFormat*>(&data[0]);
mcf->myvalue = 65535;

Здравствуйте, T4r4sB, Вы писали:

TB>Объясни, почему именно элементы по 2му и 3му индексу. Может быть, на самом деле там какая-то структура? Тогда почему бы к ней сразу не привести?

а это потенциальные проблемы с выравниванием. так что лучше такие штуки распрягать сериализацией с явным указанием выравниваний/яйцеконечности

Здравствуйте, BulatZiganshin, Вы писали:

BZ>а это потенциальные проблемы с выравниванием. так что лучше такие штуки распрягать сериализацией с явным указанием выравниваний/яйцеконечности

Выравнивание прагмапаками делается. Индеец — специальными типами, не int16_t, а int16be.

Здравствуйте, T4r4sB, Вы писали:

BZ>>а это потенциальные проблемы с выравниванием. так что лучше такие штуки распрягать сериализацией с явным указанием выравниваний/яйцеконечности

TB>Выравнивание прагмапаками делается. Индеец — специальными типами, не int16_t, а int16be.

вот на мой скромный взгляд — это неправильный подход. хотя хрен его знает почему...

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, T4r4sB, Вы писали:

BZ>>>а это потенциальные проблемы с выравниванием. так что лучше такие штуки распрягать сериализацией с явным указанием выравниваний/яйцеконечности

TB>>Выравнивание прагмапаками делается. Индеец — специальными типами, не int16_t, а int16be.

BZ>вот на мой скромный взгляд — это неправильный подход. хотя хрен его знает почему...

Наверное, потому, что архитектуре проца на прагмапаки начихать.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Наверное, потому, что архитектуре проца на прагмапаки начихать.

Ну если проц кидает исключение при невыровненном доступе, и при этом надо работать с поганым форматом, в котором нет выравнивания, то придётся действовать другими методами, каждое поле восстанавливая побайтово.

HAXT:

HAX>почему-то так не получается
HAX>(unsigned short*)(data[2]) = 65535;

Тогда уж так:

*reinterpret_cast<unsigned short*>(data+2) = 65535;
//или
reinterpret_cast<unsigned short &>(data[2]) = 65535;

Этот код плох. endiannes, reinterpret_cast, экономия на тактах...

Здравствуйте, HAXT, Вы писали:

HAX>а мне нужно этой операцией перезаписать 2 байта в этом массиве, 2, и 3 по индексу с нуля

uint16_t value = 12345;
size_t pos = 1;
data[pos++] = static_cast<uint8_t>(value >> 8);
data[pos++] = static_cast<uint8_t>(value);