Корректен ли код - C/C++

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

D>Де-факто, такое размещение членов структур важно для низкоуровневого программирования именно для этого в Стандарте присутствуют POD и бинарная совместимость структур. Не смотря на кажущуюся вольность в размещение членов структур и битовых полей, ей никто не пользуется, так как это нарушит возможность использования языка для низкоуровневого программирования, где нужно строго контролировать раскладку структур и на самом деле реализации позволяют это делать, и не просто некоторые — а все. Выравнивание, раскладка структур, размеры типов, возможность копирования POD побайтно – это все части этой бинарной совместимости.

Пример из личной практики.

Несколько лет назад обратились ко мне коллеги из параллельной организации с вопросом: "А почему мы не можем получить из железяки данные", они использовали POD-struct ( точно не приведу его — не помню ) но в нем была, как здесь назвали "дырка", и получали они иногда мусор, а и ногда кору от ядра

Спасло коллег явное использования выравнивания 1.

К чему это ? Да к тому, что гарантия валидности копирования memcpy ничего не грит о выравнивании.
Да и проблема возникла на железном уровне

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Я не могу понять, почему Вы настолько убеждены, что компилятор для структуры вида:

АШ>

АШ>struct point
АШ>{
АШ>    double x;
АШ>    double y;
АШ>    double z;
АШ>};
АШ>

АШ>не может сделать что-то подобное:

АШ>| x |XXXX| y |XXXX| z |XXXX

АШ>Именно в этом состоял первоначалный вопрос. И компилятор волен вполне так поступить, поскольку стандарт ему это не запрещает. Поэтому код

АШ>

АШ>double operator[](size_t i) {return (&x + i);}
АШ>

АШ>является хаком в том, смысле, что безосновательно полагается на то, что между x, y и z нет "дыр".

Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.

В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше, поскольку

1. An entire structure or union object is aligned on the same boundary as its
most strictly aligned member.
2. Each member is assigned to the lowest available offset with the appropriate
alignment. This may require internal padding, depending on the previous
member.

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

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

AA>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.

AA>В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше.

А можешь дать ссылочку на этот документ? А то google находит его только для System V, а мне бы хотелось для Windows/Linux или (лучше) не зависымый от опреационной системы. Для Itanium или EM64T/AMD64 это общедоступные документы.

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

AA>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.

Цитата взята здесь

In computer software, an application binary interface (ABI) describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application. An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI.

И исходя из этого становится ясно почему все говорят о Стандарте:
Решение, которое отвечает стандарту, будет переносимым( на компиляторы поддерживающие стандарт ). В свою очередь решения затаченное под Intel Binary Compatibility Standard (iBCS) может быть н6еперносимо на другие платформы.

А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>class Vect
ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?

А почему бы (чтобы не возникали такие вопросы и не было зависимости от используемого компилятора) не написать просто

class Vect
{
...
public:
double operator [] (int i) const {return x[i];};
private:
double x[3];
};

Олег Р.

Здравствуйте, Аноним, Вы писали:

А>А почему бы (чтобы не возникали такие вопросы и не было зависимости от используемого компилятора) не написать просто

А>class Vect
А>{
А>...
А>public:
А> double operator [] (int i) const {return x[i];};
А>private:
А> double x[3];
А>};

читай внимательней предыдущие посты — человеку не нравится обращаться к значениям по индексу, хочется символьных обозначений %)

А>Олег Р.

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

S>И исходя из этого становится ясно почему все говорят о Стандарте:
S> Решение, которое отвечает стандарту, будет переносимым( на компиляторы поддерживающие стандарт ). В свою очередь решения затаченное под Intel Binary Compatibility Standard (iBCS) может быть н6еперносимо на другие платформы.

S>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО

Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

D>Здравствуйте, Alex Alexandrov, Вы писали:

AA>>Вмешаюсь в беседу, извините. Почему-то все говорят про Стандарт, забывая о том, что это лишь один из документов, регулирующих поведение компилятора. Когда мы говорим о C-структурах, т.е. о типах, поля которых используются напрямую, то большее значение имеет другой документ: ABI (Application Binary Interface) спецификация. Именно она регулирует подобные вещи в большей степени, стремясь к гарантии, что вы можете использовать библиотеки и заголовочные файлы, полученные с помощью другого компилятора.

AA>>В частности, именно Intel 386 ABI запрещает компилятору сделать "что-то подобное", приведенное выше.

D>А можешь дать ссылочку на этот документ? А то google находит его только для System V, а мне бы хотелось для Windows/Linux или (лучше) не зависымый от опреационной системы. Для Itanium или EM64T/AMD64 это общедоступные документы.

Честно сказать, я привел цитату из того же System V ABI. Что-то мне подсказывает, что GCC ABI корнями идет оттуда. Но не смог найти явной информации.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

AA>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.

Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?

Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.

Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы

... << RSDN@Home 1.1.4 stable rev. 510>>

ЕК>class Vect
ЕК>{
ЕК>...
ЕК>public:
ЕК> double operator [] (int i) const {return *(&x+i);};
ЕК>private:
ЕК> double x,y,z;
ЕК>};

ЕК>Собственно, вопрос вызывает то, можно ли быть уверенным, что x,y,z будут расположены в памяти подряд?

Если мне не изменяет память, такая гарантия есть, если это будет не class а struct

Здравствуйте, Аноним, Вы писали:

А>Если мне не изменяет память, такая гарантия есть, если это будет не class а struct
Можно привести ссылки на первоисточники?

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

S>Здравствуйте, Alex Alexandrov, Вы писали:

AA>>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.

S>Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?

S>Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.

S>Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы

Да легко: собери одну часть своего well-formed кода одинм компилятором, а другую — другим, а потом попробуй их заставить работать вместе.

Причем это имеет место даже для одного и того же компилятора, но разных его версий, или разных ключей компиляции.
Например, Sun поменял ABI своего компилятора при переходе с версии 4.2 на 5.x.
Для нашей системы это означало то, что теперь мы должны достать новые версии всех сторонних библиотек, собранные пятеркой.
Некоторые библиотеки их получить не удалось (по разным причинам — в одном случае фирма просто перестала существовать, в другом — запросила дополнительное бабло, в третьем — вообще переписала библиотеку на java и них теперь вообще нет интерфейса для С++), и в результате у нас один и тот же код компилируется дважды разными компиляторами — для сборки со старыми библиотеками и для сборки с новыми.

И из-за недоступности версий старых библиотек, поддерживающих ABI нового компилятора, у нас нет никакой надежды перевести приложения, которые с этими библиотеками линкуются, на нормальный С++ от версии 5.x.

Вот таков горький вкус ABI.

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

[]

Немного оторвано от контекста дискуссии, но тем не менее

ГМ, в целом, я писал здесь так:

А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО

Думаю Вы согласитесь, что "очень редко" как раз описываеи привеленную Вами ситуацию

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

S>[]

S>Немного оторвано от контекста дискуссии, но тем не менее

S>ГМ, в целом, я писал здесь так:

S>

S>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО

S>Думаю Вы согласитесь, что "очень редко" как раз описываеи привеленную Вами ситуацию

S>

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

И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&only=1, а там как раз идет речь именно о смене ABI.

Еще пример — у тебя есть приложение, собранное из нескольких библиотек плюс то, что ты написал. Так вот, собирая все это дело вместе, имеет смысл помнить, что каждый компонент мог быть собран со своими ключами компиляции, а эти ключи, в принципе, могут конфликтовать (хотя это, конечно, было бы очень нехорошо со стороны разработчиков компилятора). По-моему, у VC++ или у Борланда была опция, при помощи которой которой можно было управлять бинарной реализацией множественного наследования, и предлагалось там варианта 4, по-моему. Насколько я понимаю, эти варианты были бинарно несовместимыми, а это означало, что если тебе захотелось изменить эту опцию, тебе в общем случае придется пересобрать все библиотеки, а не только парочку объектников, которые тебя интересуют. И хорошо, если все библиотеки у тебя есть в исходниках. А если нет? Ты проклянешь все в поисках причины глюков и путей их объезда.

P.S. Мы ведь на "ты" здесь, да?

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

S>>Немного оторвано от контекста дискуссии, но тем не менее

S>>ГМ, в целом, я писал здесь так:

S>>

S>>А об ABI будут думать разрабочики компилятора под конкретные программно-аппаратные платформы. ИМХО в большинстве задач только разработчики компиляторов и должны думать ABI. И очень редко должны задумываться рпзрпботчики ПО

J>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&only=1, а там как раз идет речь именно о смене ABI.

Я вот о чем: этот спор в контексте темы топика

J>Еще пример — у тебя есть приложение, собранное из нескольких библиотек плюс то, что ты написал. Так вот, собирая все это дело вместе, имеет смысл помнить, что каждый компонент мог быть собран со своими ключами компиляции, а эти ключи, в принципе, могут конфликтовать (хотя это, конечно, было бы очень нехорошо со стороны разработчиков компилятора). По-моему, у VC++ или у Борланда была опция, при помощи которой которой можно было управлять бинарной реализацией множественного наследования, и предлагалось там варианта 4, по-моему. Насколько я понимаю, эти варианты были бинарно несовместимыми, а это означало, что если тебе захотелось изменить эту опцию, тебе в общем случае придется пересобрать все библиотеки, а не только парочку объектников, которые тебя интересуют. И хорошо, если все библиотеки у тебя есть в исходниках. А если нет? Ты проклянешь все в поисках причины глюков и путей их объезда.

Дык что да, то да

Но опять, в контексте темы отпика и первого сообщения того, с кем я спорил

ABI не при чем

Что я и озвучил здесь

J>P.S. Мы ведь на "ты" здесь, да?

По правилам вроде на Вы

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

J>>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&only=1, а там как раз идет речь именно о смене ABI.

S>Я вот о чем: этот спор в контексте темы топика

в контексте темы топика нам от ABI достаточно sizeof

J>>P.S. Мы ведь на "ты" здесь, да?

S>По правилам вроде на Вы

S>

ОК, прошу прощения за тыканье!
Постараюсь запомнить, что с Вами надо на Вы

Ну или на брудершафт

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

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

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

J>>>И потом, ты ведь спорил конкретно с http://rsdn.ru/Forum/Message.aspx?mid=1512742&only=1, а там как раз идет речь именно о смене ABI.

S>>Я вот о чем: этот спор в контексте темы топика

J>в контексте темы топика нам от ABI достаточно sizeof

И чем нам
здесь

достаточно sizeof

Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?
ИМХО — не выход.

J>>>P.S. Мы ведь на "ты" здесь, да?

S>>По правилам вроде на Вы

S>>

J>ОК, прошу прощения за тыканье!
J>Постараюсь запомнить, что с Вами надо на Вы

Ну или на брудершафт

Ах, оставьте...

... << RSDN@Home 1.1.4 stable rev. 510>>

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

S>достаточно sizeof

S>Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?
S>ИМХО — не выход.

Ну почему же

если sizeof(массив) == sizeof(структура) — значит, нечему там больше быть, кроме этих несчастных членов в порядке их объявления в классе.

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

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

S>>достаточно sizeof

S>>Для того что-бы забить на выравнивание и статически проверять при компялиции валидность утверждения ?
S>>ИМХО — не выход.

J>Ну почему же

J>если sizeof(массив) == sizeof(структура) — значит, нечему там больше быть, кроме этих несчастных членов в порядке их объявления в классе.

Я же написал ИМХО

Потому что нет гарантии что в следующей версии компилятора, или на другом компиляторе все будект ОК ( ABI прнимаешь

)

ИМХО лучше, по возможности, придерживаться стандарта

ЗЫ
Можно не отвечать ибо еще немного и нас можно в философию отправлять

... << RSDN@Home 1.1.4 stable rev. 510>>

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

S>Здравствуйте, Alex Alexandrov, Вы писали:

AA>>Разработчики ПО обязаны знать об ABI. Когда ты пишешь библиотеку под Unix, тебе надо понимать это хотя бы для того, чтобы понять, является ли новая версия твоей библиотеки ABI-совместимой с предыдущей, и какую цифру в версии таки надо менять (major/minor/patch). Когда начинаются глюки с С++ рантаймом также надо знать, что такое ABI и когда у GCC он поменялся. И т.д.

S>Насколько сильно я ошибусь предположив что руководствуясь стандартом языка С/С++ я могу абстрагироваться от АБИ?

S>Если Вас не затруднит — приведите пример когда с точки зрения стандарта код будет well-formed, но при этом Он не будет удовлетворять AАБИ.

S>Стандарт ИМХО для того и писан, чтобы абстрагироваться от платформы

Я смотрю, вы тут уже с Джаззером поговорили.

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

Дядя Саттер тоже об этом пишет: http://www.cuj.com/documents/s=8188/cuj0412g/0412sutter.html (для прочтения необходимо иметь регистрацию на cuj.com. Вроде можно бесплатно на полгода зарегистрироваться.)

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

	От:	srggal
	Дата:	25.11.05 10:55
	Оценка:

	От:	Alex Alexandrov
	Дата:	26.11.05 10:50
	Оценка:	5 (1) +2 -1

	От:	dupamid
	Дата:	26.11.05 13:15
	Оценка:

	От:	srggal
	Дата:	28.11.05 08:32
	Оценка:

	От:	Аноним
	Дата:	28.11.05 10:28
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	30.11.05 10:56
Оценка:	4 (1) +1