КИТА unofficial

Фрагмент программы:

Результат выполнения программы: st = 1, т.е. А не равно B !!!

Вопрос: Как такое может быть?

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

В каком месте и сколько? конкретные цифры.

НУ? неужели никто не может посчитать?

Как в анеке: "Это уже второй сложный вопрос!". )))

Если серьезно, то

1) В каком месте: ясное дело, что между полями структуры, так как члены, объявленные рядом друг с другом, компилятор не обязательно расположит в памяти вплотную друг к другу.
Вот читаем книжку:

2) Сколько - это уже третий сложный вопрос. И вопрос не языка С++, а конкретной его реализации, т.е. ответ зависит от платформы и компилятора, а не от текста твоей программы или стандарта С++.

Цитата правильная, но все таки....
В каком месте и сколько? конкретные цифры.

Для других структур показанный мной пример работает отлично и никогда никаких дыр не было!!!! И ничто не мешали сравнению структур по памяти. Но в этой структуре есть явная дыра. И ее необходимо увидеть.

На мой взгляд пример очень интересный...

Явная-неявная...с точки зрения языка С++ нет никакой дыры. Дыры делает не язык, а компилятор. Еще раз: данный компилятор для конкретной плафтормы. Другой компилятор вполне может расположить иначе члены. С++ это не регламентирует и не ограничивает, насколько я понимаю.

Sochin неправильно.

У кого нибудь есть еще варианты?

Неправильно что?

- ДА
- Да
- неправильно, настраивает и ограничивает директивами препроцессора. Но для программиста это не отмазка. Программист должен знать какой код для его программы построит компилятор, ну я так считаю  :) . У нас были случаи, когда приходилось бинарный код для контроллера открывать в дебаггере и смотреть асм код, т.к. на С все было написано без ошибок.

Дыра есть )))) Лично я ее искал долго, 30 минут. А знающий человек подошел и сразу сказал где ошибка и точные цифры назвал. Я по дампу памяти сверил.

Хотя можем об этом потом поспорить, когда ответ напечатаю, буду рад принять участие в споре  :D

Т.е. ты хочешь сказать, что стандарт С++ определяет некоторые директивы препроцессора, которые во всех реализациях языка для всех платформ позволяют четко задать в том числе и все параметры выравнивания членов структур в памяти? Я правильно тебя понял?


Ты определись для начала где дыра. В С++, в твоей программе или в дампе памяти.

1. Да. Только наверное стандарт ANSI C, мне кажется что стандарт C++ так и не принят, есть только вариации к нему. Или уже принят? Хотя со стандартами у меня слабовато. Но такая возможность есть.

2. Хихик, дыра в дампе памяти структуры, которая создана компилятором из программного кода. А в программе ошибка, неучитывающая этого.

3. Мне кажется тут кроме нас никого больше нету )))

Стандарт С++ принят после долгих мучительных лет работы по стандартизации в 1998 году.
Стандарт ISO/IEC 14882:1998 Programming Language C++. Имеется исправленная версия стандарта ISO/IEC 14882:2003 Programming Language C++.
Стандартная библиотека языка С++ целиком включает в себя стандартную библиотеку языка С, описанную в стандарте ISO/IEC 9899:1990 Programming Language C.
Рабочая группа по стандартизации С++ продолжает свою работу.

Ссылочка на сайт ISO (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=38110&ICS1=35&ICS2=60&ICS3=)
Ссылочка на сайт международной рабочей группы по стадартизации С++ (http://www.open-std.org/jtc1/sc22/wg21/)

А зря. "Стандарты надо читать!" (с) (сами знаете какой самый-самый гуманнный преподаватель кафедры АСУ.)
Было бы желание, в Сети можно бесплатно скачать последний доступный черновик стандарта. Окончательная версия правда  платная.


В конкретной реализации (читай компиляторе) вполне возможно. В стандарте - врядли.
Возможно разочарую, но скажу больше.
Стандарт говорит вот о чем: представление, размер и диапазон фундаментальных типов зависит от реализации. У некоторых типов есть ограничения по выравниванию, которые также зависят от реализации. Стандарт определяет всего лишь минимальные требования для этих типов(см. файлы <climits> для целочисленных типов, <cfloat> для типов с плавающей точкой). В файле <limits> объявлены шаблоны для получения численнных характеристик всех фундаментальных типов.

Круто, да? О каких конкретных цифрах может идти речь? ))


Ошибку в студию и тогда мы возможно подискутируем насколько это ошибка языка С++.


Ыыы. Есть еще космос и еще кое-что. )))

Ок, так и быть, раз уж тут мы с тобой вдвоем и больше никого нет.

Вобщем директива #pragma pack(n) устанавливает границы выравнивания для структур, объединений и классов. По умолчанию n=8 хотя может принимать значения 1, 2, 4, 8 и 16.

Тут получается, что

sizeof(enum) = 4 байта.
sizeof(unsigned char) = 1 байт.

sizeof(testStruct) = 8 байт ==> т.е. sizeof(enum) + sizeof(unsigned char) + 3 байта выравнивания до 8

              |  1       2      3      4     |   5     |  6      7       8     |
              |**** **** **** **** | **** |**** **** **** |
              |    enum                      | char  |      мусор           |
             
Вопрос номер два: какие строки необходимо добавить вместо "..........." чтобы структура А отличалась от В.
Ответ:
memset( (void*)&A, 0xff, sizeof(A));
memset( (void*)&B, 0xcc, sizeof(B));


PS спасибо за ссылки на стандарты.

ОК, прагма так прагма. Читаем стандарт:


Т.е. директива Pragma обрабатывается(и если обрабатывается, то как именно обрабатывается!) или не обрабатывается не зависит от твоей программы или от стандарта языка, а зависит только от реализации языка в конкретном компиляторе. Если конкретный компилятор не признает директиву #pragma pack(n), то он чихать на нее хотел и все равно выравняет члены как ему будет угодно. А если и признает, то не факт что будет выполнять именно выравнивание объектов, а может например отформатировать тебе винт. ))) И компилятор будет полностью прав, так как такое его поведение соответствует стандарту С++. ))

Мораль? В этой задаче, если ты приводишь текст программы, а решение компиляторо-платформенно-зависимое, то необходимо указывать используемый компилятор/платформу. Я так думаю.

Перечитал я все это и согласен с Sochin - решение задачи есть зависимым от компилятора.

уххххх..... ну чё я сказать могу? Твоя цитата относится ко всем директивам #pragma. А конкретно про #pragma pack ничего не сказано.Там только общие фразы и ничего конкретного.

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

Что на практике проверено, то факт, а то что на бумаге написано - то фигня. Вот мое мнение.

Компиляторы: VC, gcc, Tornado, bc, STL для Siemens - все нормально поддерживают pragma pack и никто из них пока не возмущался. А эта директива используется чтобы выравнять размер структур при передаче данных от платформы к платформе, часто используется при передаче данных в сетях.

Единственная зависимость от компилятора и от платформы: установленное значение по умолчанию для #pragma pack

Если бы я сразу указал в начале программы #pragma pack(8 ) то все бы сразу поняли в чем дело. Это ж совсем не интересно )))))
А указать место мусора в структуре тоже было несложно.

а какой компилятор С ты используешь  для какого процессора?
Для тех процов, для которых пишу я на С,этот код даст ответ 0.

ЗЫ: Потому что там выравнивание побайтовое ;) и оперативки всего 512 байт ;)

Storm может и побайтовое, если контроллер. )))))))))
Вообще-то чтобы получилось 1 или -1, надо предварительно заполнить структуру (и мусор в ней) какими-то значениями, например командой memset. По стандарту в С++ все создаваемые объекты равны 0 или заполнены 0х00.

Все там конкретно: семантика конкретной прагмы зависит от реализации в конкретном компиляторе. Т.е. два компилятора, соответствующих стандарту С++ могут ее по разному интерпретировать и реагировать на нее.


Возможно узнать действия компилятора. Для этого нужно узнать какие прагмы в данном компиляторе поддерживаются и что делают. ))


Это мнение студента-первокурсника «но программа ведь компилится и работает!!!» в ответ на замечание преподавателя о наличии логической ошибки в программе. ))


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


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

Да, стандарт - это не авторитетный источник.
привели конкретный пример платформы или компилятора, где не работает #pragma pack

Все вопросов больше не имею.


Товарищ, язык С++ - это язык программирования, который описан в стандарте, а не компилятор, уж прости за то что приходится повторять очевидные казалось бы вещи. Есть компиляторы, нету компиляторов, поддерживают они стандарт или нет, вне зависимости от этого если ты пишешь в условии задачи про исходник на С++ без указания компилятора, то это подразумевает, что решение доступно стандартными средствами, а все нестандартные фокусы неприменимы. Иначе твоя задача несостоятельна. Заметь, даже при условии, что я такой платформы или компилятора могу и не знать.

Sochin ты меня замучал своими придирками. Нормальная задача, нормальные требования и нормальный ответ. Все твои слова - вода. Я, в отличие от тебя, привел конкретную реализацию, конкретный ответ и конкретные компиляторы где все это работает.
Если ты уверен что я ошибаюсь, тогда приведи конкретный пример, как Storm.

Нестандартных фокусов тут нет. Если ты не сталкивался с такой проблемой на практике, это не значит что я тут шаманю.

Именно, AVR фирмы Atmel и MicroCHIP PIC. в них считаешь каждый бит и раскидываться на выравнивание непозволительная роскошь.

Придирки? Вода? Цитаты пожалуйста.
Куда уж конкретнее -
#pragma pack не описана в стандарте языка, т.е. она не является стандартной для С++. Ее употребление - это нестандартная фича. Если мы говорим о конретном компиляторе - нет вопросов. Но ты настаиваешь на том, чтобы не указывать конкретную реализацию. А если мы говорим о языке в целом, то твой ответ на твою же задачу не является верным для общего случая.
Вода?


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


Компилятор назвать? Пожалуйста, в качестве примера IBM Rational Apex® C/C++ compiler (http://www-1.ibm.com/support/docview.wss?rs=980&context=SSSGW8&dc=DB520&uid=swg21216846&loc=en_US&cs=UTF-8&lang=en&rss=ct980rational)

Вот посмотри, что пишут ребята из IBM (понимаю, что для тебя это возможно полная туфта, также как и стандарт языка, но все же):


Ой я тебя умоляю. Твой ответ не соответствует стандарту С++. Если ты не уважаешь стандарты, это другой вопрос. Менее нестандартным (с точки зрения стандарта С++ конечно, а то может у тебя другое понимание «стандартности/нестандартности») он от этого не становится. И я тут ни при чем. Все вопросы - в комитет по стандартизации.

Отлично! IBM -> http://www-1.ibm.com/support/ авторитетный для меня источник. Хорошая статья.

1. Теперь согласен, #pragma pack работает не на всех компиляторах.
В данной статье отлично показано как изменить расположение членов структуры в памяти используя С++.

2. Специалисты IBM отлично умеют расчитывать дыры в структурах и их конкретный размер. Это не случайный процесс, а четко определенный, его можно изучить и научится расчитывать самому.

3. Мой пример показывает, что необходимо хотябы примерно прикидывать расположение объектов в памяти и исключать подобные ошибки еще на этапе программирования.

4. Я думаю надо заканчивать эту дискуссию. На твое следующее сообщение отвечать не буду.

ДА, забыл,  Sochin +1 за ссылку на статью.

Хе-хе. Цитируемое тобой замечание касалось конкретно твоего примера простой структуры без битовых полей. ))

З.Ы. До встречи в очередной дискуссии. Закрывай тему. )))