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

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


на сколько я понял этим мы задаем выравнивание в 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 байт, а будет таким какой задано в системе, или же по умолчанию будет максимальному размеру поля структуры.

не так ?)

т.е. ты считаешь, что размер следующих структур будет разным (при условии sizeof(double) == 8, sizeof(int) == 4)?

поспешил я сказать что выравнивание по идет по максимальному типу. Но тут либо я неправильные мануалы читал, либо я из не правильно понял, что вероятнее.
к примеру размер структуры

будет 12байт, тогда я не понимаю смысл выравнивание на 8. Вернее как оно работает в этом случае.


Но я правильно сказал что


будет не 5 байт. Она 8 байт, независимо идет ли выравнивание на 4 или на 8, потому что они кратны ?

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

Ты хоть проверял? У меня размер получился 16.

Господа, у меня к Вам, кажется, плохие новости.

вот gcc (или minGW... что там на liveworkspace...):

http://liveworkspace.org/code/2c2d100a5a5e...1ac0e3beb06aa3c

а вот в студии 2008:


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

Добавлено через 1 минуту и 24 секунды
borisbn, у тебя студия, случаем, не 64-хбитный код генерит? А то есть подозрение, что pragma pack работает только на понижение выравнивания.

хммм. тогда как вот это понять ?
http://liveworkspace.org/code/d993132e2828...3646f22214910a1

P.S. Уже в третий раз прошу boostcoder'а высветить на морде liveworkspace'а версию компилятора... Может по русской сказочной традиции он в третий раз улсышит 

в качестве примера для размышления :
http://liveworkspace.org/code/99bfeb182277...ac92132b93409fa
  



Добавлено через 7 минут и 37 секунд

gcc 4.6.0, если не ошибаюсь 



Это сообщение отредактировал(а) mes - 28.4.2011, 18:29

так ну всетаки pragma push задает выравнивание полей структуры а не самой структуры. Другое дело как она это делает.



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

как это "поле char ... выравнивается ... " ?   
выравнивается _стартовый_ адрес поля или размер структуры.. 


Это сообщение отредактировал(а) mes - 28.4.2011, 21:05

это так что поле char после int в структуре заняло на 1 байт как положено, а 4, т.е. как бы выровнило адрес для следующего поля структуры (как если бы следующим полем был опять int). Но оно же в данном конкретном случае является последним полем, и непонятно почему так. Если вам это очевидно тогда лучше объясните мне, ибо на все свои вопросы я получаю в ответ так же вопросы 

нет. у меня и винда и студия 32-х разрядные


хммм. тогда почему там 

а у bsa





причём выравнивается, судя по всему либо на 4 либо на 1.

либо на два 

ага...
http://liveworkspace.org/code/4a641cbbf10a...9b0f1aa1504564c
чего-то я перестал понимать эту логику

пример приведен как контраргумент к высказыванию, что выравнивание никак не зависит от содержимого.. 


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

Вообще-то, я имел в виду, что минимальный размер выравнивания не зависит от размера содержимого. Так как перед этим было высказывание, что мол если есть double, то все остальное тоже будет равняться по 8 байт.

а я почему то думал, что то высказывание, в котором засомневался, принадлежит Earnest.. 

Добавлено через 3 минуты и 3 секунды

хм... а что подразумевается под минимальным размером выравнивания ?

Я тоже именно на это отвечала

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


проблема состояла именно в том что я брал размер заголовка при помощи sizeof(hdr), который был неправильным.

Не, не так, чар по-любому будет идти сразу вслед за интом. Если бы там был инт64 вместо чара, тогда да.
Например стркутура из 2-ух чаров, при любом выравнивании будет иметь 2 байта длины.
Выравнивание начинает играть роль тогда, когда размер типа больше выравнивания, например:
struct S {
    char a;
    __int64 b; 
};
при выравнивании 1 - размер стркутуры - 9 байт
при 2 - размер стркутуры - 10 байт
при 4 - размер стркутуры - 12 байт
при 8 - размер стркутуры - 16 байт
и дальше при любом выравнивании, размер будет 16 байт.

Добавлено через 4 минуты и 50 секунд
Упс, сори, тут еще 3 страницы, после того поста, извиняюсь, не заметил.

Добавлено через 11 минут и 34 секунды
Ну прочитал 3 страницы. вобщем-то этой мысли вроде не было. так что оставляю.

большая часть трепа, была как раз по этому поводу.

http://liveworkspace.org/code/46f54a6f9b75...fd6707aa49d1fb9

и на компиляторе VS оно как раз 16.

Экспериментальным путем и путем проб и ошибок вроде бы пришли к мнению что выравнивание везде работает одинаково только для 1, 2, и 4.