D>>Утверждение: D>>если есть массив D>>T array[99]; D>>то стандарты С/С++ требуют чтобы выполнялись следующие ассерты: D>>assert(sizeof(T) == sizeof(arr[0])); D>>assert(&array[1] == array + 1); D>>assert(array + 1 == (T*)((char*)array + sizeof(T))); D>>Ты не согласен с каким-то из этих ассертов?? D>>Тебе непонятно, почему из этих ассертов следует что выравнивание должно включаться в sizeof? V>Ну пример, компилятор может захотеть выровнять массив на определеную величину при этом sizeof останется прежним, кто мешает?
Выровнять массив -- это добавить паддинг между каждым элементом массива?
Без изменения sizeof это мешает сделать третий ассерт.
я же написал список ассертов, которые должны выполняться.
Наводящий вопрос: все знают что sizeof структур не обязан быть равен сумме sizeof членов. Что знают не все -- это то что компилятор может вставить паддинг не только _между_ членами структуры, но и _в конце_ структуры. Как ты думаешь зачем это делать компилятору? Ситуация здесь полностью аналогична рассматриваемой ситуации.
Re[10]: для x86 10 байтовый вещественный тип в gcc и msvc
Здравствуйте, dilmah, Вы писали:
D>>>Утверждение: D>>>если есть массив D>>>T array[99]; D>>>то стандарты С/С++ требуют чтобы выполнялись следующие ассерты: D>>>assert(sizeof(T) == sizeof(arr[0])); D>>>assert(&array[1] == array + 1); D>>>assert(array + 1 == (T*)((char*)array + sizeof(T))); D>>>Ты не согласен с каким-то из этих ассертов?? D>>>Тебе непонятно, почему из этих ассертов следует что выравнивание должно включаться в sizeof? V>>Ну пример, компилятор может захотеть выровнять массив на определеную величину при этом sizeof останется прежним, кто мешает? D>Выровнять массив -- это добавить паддинг между каждым элементом массива? D>Без изменения sizeof это мешает сделать третий ассерт. D>я же написал список ассертов, которые должны выполняться.
Тем не менее это не мешает компилятору сделать соответствующую оптимизацию.
D>Наводящий вопрос: все знают что sizeof структур не обязан быть равен сумме sizeof членов. Что знают не все -- это то что компилятор может вставить паддинг не только _между_ членами структуры, но и _в конце_ структуры. Как ты думаешь зачем это делать компилятору? Ситуация здесь полностью аналогична рассматриваемой ситуации.
Я как раз про другое выравнивание, которое может делать компилятор без ведома программиста. Intel C++ таким кстати балуется.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[11]: для x86 10 байтовый вещественный тип в gcc и msvc
V>Тем не менее это не мешает компилятору сделать соответствующую оптимизацию. V>Я как раз про другое выравнивание, которое может делать компилятор без ведома программиста. Intel C++ таким кстати балуется.
какую оптимизацию? можешь четко объяснить?
Re[7]: для x86 10 байтовый вещественный тип в gcc и msvc
Здравствуйте, Vain, Вы писали: V>Непонятно что вы хотели сказать выделенной фразой. Sizeof это фиксированная величина, заданная заранее, никакой alignment её не меняет. Это значит что выравнивание может быть больше чем sizeof. Отсюда если выравнивать нужно на 16, то sizeof не обязан быть 16.
Выделите-ка malloc-ом память для 10 элементов long double. Чему равен адрес первого элемента? А второго?
Re[12]: для x86 10 байтовый вещественный тип в gcc и msvc
Здравствуйте, dilmah, Вы писали:
V>>Тем не менее это не мешает компилятору сделать соответствующую оптимизацию. V>>Я как раз про другое выравнивание, которое может делать компилятор без ведома программиста. Intel C++ таким кстати балуется. D>какую оптимизацию? можешь четко объяснить?
Ну оптимизирующий компилятор может взять и за тебя решить что выравнивание 16 лучше чем 8, к примеру.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[13]: для x86 10 байтовый вещественный тип в gcc и msvc
V>Ну оптимизирующий компилятор может взять и за тебя решить что выравнивание 16 лучше чем 8, к примеру.
может. только в каком конкретном случае?
Если у long double будет sizeof равный 12, то компилятор конечно сможет выровнять long double в ситуации когда выделяется единичный объект этого типа на стеке, пожалуйста, какие проблемы; либо если он является членом структуры.
Если же есть массив, то возникают проблемы связанные с потребностью удовлетворять стандартам, и такую оптимизацию можно будет сделать только в самых тривиальнейших случаях. Скажем, если ты передаешь массив или вектор в любую внешнюю функцию, то компилятор не может ничего выровнять -- потому что он не знает что делает эта внешняя отдельно компилируемая функция, а она имеет полное право применять адресную арифметику, делать касты к (char*) и т.п.
Тебе уже упомянули про идиому malloc(sizeof(T)*n) -- компилятору придется все такие вещи автомагически править (увеличивать размер). Ты видимо не понимаешь сколько магии придется применить компилятору, и при раздельной компиляции это в большинстве случаев все равно не будет работать.
И все это ради чего? ради того чтобы люди которые плохо понимают С не удивились странному размеру sizeof?
