Кто имел практику использования этого  на С++ ? В каких случаях это является целесообразным ? Какую пользу это может принести ?

Имеет в виду именно о том выравнивании на которое влияет сам программст в коде, а не компилятор и не система в целом.


на сколько я понял этим мы задаем выравнивание в 1 байт, т.е. мы отказываемся от выравнивания для какой то структуры, есть хоть какие то реальные задачи где это может потребоваться на С++ да еще и не во встраиваемых системах, а на мощном сервере ?

там, где нужно обеспечить требуемое бинарное расположение данных..

Добавлено через 3 минуты и 22 секунды
также в случаях когда выравнивание по умолчанию неприемлемо.. 

кроме как для записи и восстановления структуры в/из файла это когда может потребоется


я вот об этих случаях и спрашивал, кикие ето такие случаи ?)

Это сообщение отредактировал(а) cupper - 28.4.2011, 13:47

Например процессор Intel гарантирует атомарность операций чтения и записи для выравненных 64-х битных объектов. Конечно, одним выравниванием членов структуры здесь не обойтись, сама структура тоже должна располагаться по "правильному" адресу, но все же...

100% требуемого выравнивания для конкретного объекта насколько мне известно добиться нельзя (имеется ввиду независимо от опций проекта, компилятора и пользовательских выравниваний). Я при реализации атомарных операций в MSVC ставил __declspec(align( # ))  + assert на корректное выравнивание.


Это сообщение отредактировал(а) azesmcar - 28.4.2011, 14:01

это опять "для чего" а не "зачем". Понятия не приложу зачем может это понадобится. 

Бубуд конкретен, если например сервер обрабатывает типы какой то определенный структуры притом элементов этой самой структуры бесчисленное множество. Вот в этом случае выравнивание может дать либо выигрыш в памяти и проигрыш в производительности (когда у нас смещение будет 1 для полей структуры). Либо выигрыш в производительности и проигрыш в памяти (это вот как раз по умолчанию). Это единственный пример который я могу выдумать который как то может встретиться на практике. Например если этих объектов так много что не на первый план выходит именно не хватка памяти нежели скорость их обработки. 

Еще что то ?

А на счет жесткой последовательности байтов, это кроме как для простого сохранения структуры в файл и последующего восстановления, может для чего то понадобится ? Это по сути сераилазация получается, но без возможности использования указателей. И при условии фиксированных всех полей используемых в структуре. Опять таки можно, но зачем ? Ну хотя тут более легко найти причину. Сириальазция все таки какая никакая везде нужна.

В каком смысле? Не знаешь зачем нужна атомарность чтения/записи?


Мутный какой-то пример. В таком случае я бы пересмотрел саму структуру объектов. Отключение выравнивания - не выход а проблема переносимости.

может случиться выигрыш в памяти и выигрыш в производительности, если при таких манипуляциях данные умещаются в размер строки кэша

64бита - 8 байт = double (к примеру), я как бы думаю что по умолчанию выравнивание в структурах в которых есть 64x битное поле будет 8 байт, для того что бы как раз атомарно работать с типом. Такое поведение по молчанию уже идет. Выравниванием возможно только нарушить этот порядок, тем самым считывание этого поля будет производится в несколько заходов, т.е. мы теряем в производительности, но выигрываем памяти. Вы об этом имел в виду ? Если нет тогда я не понял вас.

Для чего такое может понадобится я написал в предыдущем посте на примере большого числа элементов структуры. Но вы назвали пример мутным и я с вами соглашусь, он просто высосан из пальца, потому что я не знаю зачем может потребоваться нарушать стандартное выравнивание. Собстно я и создал тему что бы вы мне подкинули примеры из практики 

Выравнивание будет такое, какое установлено в опциях компилятора, или локально, прагмами, и никак не зависит от того, что содержат твои структуры.
По умолчанию нонешние компиляторы действительно устанавливают 8... Но никто не мешает установить любое. Например, у меня в приложении, которое растет еще из досовских времен, установлено выравнивание = 2 - из соображений бинарной совместимости с древним форматом. В принципе, можно было бы ограничить это выравнивание  только теми модулями, которые загружают/выгружают данные или только этими сериализуемыми данными, но возиться сильно влом, других забот хватает... С другой стороны, некоторые сторонние библиотеки предполагают совершенно конкретное выравнивание, вот там и приходится прагмами обкладывать...
В общем, всякое бывает. Не нужно тебе это пока и слава богу; понадобится - вспомнишь.

мне на практике отключать выравнивание приходилось только для работы с данными предопределенного формата.
что бы не рассказывать про мутные железки, в качестве примера можно привести заголовок пакета IP

при создании динамической библиотеки, которую будут использовать необязательно в том же компиляторе. например, ты делаешь библиотеку (скажем, на студии) вот с таким интерфейсом

и отдаёшь мне вот этот h-ник (с заремленными строками) и dll-ку. у тебя в проекте установлено выравнивание на 8, а у меня (скажем в билдере) - на 4.


Это сообщение отредактировал(а) borisbn - 28.4.2011, 15:47

о как, теперь предельно понятно для чего используется. 

Только уточните как. 
Я не понял а зачем они закоменчены ?

Ведь на моем компиляторе с выравниванием 8 эта стукрута будет 16 байт занимать. И вся библиотека будет это знать.
Когда я отдаю вам, с вашим 4 байтным выравниванием, у вас библиотека будет все так же работать со стуктурой выравненной на 8 байт. А ваш код будет думать что она выравнена на 4 байта. Выйдет эпик файл. 

Тогда нужно что бы в хедере строки были раскоменчены, и либо у вас либо у меня выравнивание будет "не совсем удачное" что скажется на производительности, но зато будет работать в обоих случаях.

так ?

именно. я специально их заремил, чтобы показать, что будет эпик фэил/фэйл/фейл... хз. fail, короче 


нет. она будет занимать ровно 5, а вот следующая будет начинаться через 8.
При такой структуре

одна структура будет занимать 9 байт, а следующая будет идти через 16.

Это всё при условии 32-х битой архитектуры, ессно, т.к. int ... дальше, думаю, можно не продолжать

Это сообщение отредактировал(а) borisbn - 28.4.2011, 16:04

никак ?!   

Теперь в целом все понятно. Но. Я был уверен (так прочитал в разных местах) что прагма для выравнивания задает выравнивание полей структуры а не самой структуры. 

что то вроде:
int - первое поле,  размер 4 байта, начинает от 0 байта, выравнивание 8 байт
char - второе поле, размер 1 байт, начинает от 0+8 байт, выравнивание 8 байт. 
Итого получаем что структура имеет как бы два поля по 8 байт, хотя в первой используется 4, в втором 1. Остальное мусор для выравнивания.

А для того что бы структура из char и int занимала ровно 5 байт, смещение должно быть 1 байт. Тогда поля просто будут следовать друг за другом, и структура будет 5 байт.


А вот ваш случай, что сама стуктура 5 байт (внутри структуры выравнивание на 1 байт) но выравнивание самой структуры 8 байт. Это не совсем понятно как так. Даже если предположить что прагма задает выравнивание не полей а самой структуры, то выравнивание внутри структуры точно не будет 1 байт, а будет таким какой задано в системе, или же по умолчанию будет максимальному размеру поля структуры.

не так ?)