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

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

__>>ожидая услышать какие-то подтверждения вашим словам

TB>Вопрос в том, что ты считаешь подтверждением. Если тебе интересно именно обсуждение моего случая с выкладками асмовыхлопа, это одно. А если тебе это неинтересно, тебе нужны лишь официальные документы, а без них ты предпочитаешь считать, что это я напортачил — ну считай дальше.

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

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

__>>не понял вас, что вы хотели этим сказать.

B>Делаете #undef перед включением cassert и, вот это да, ассерты работают и в релизе.

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

__>это не совсем корректно делать
Да ну?

__>потому что реализация самого ассерта "implementation defined"
Кто сказал?

ISO/IEC 9899:TC3

7.2 Diagnostics <assert.h>
1 The header <assert.h> defines the assert macro and refers to another macro,
NDEBUG
which is not defined by <assert.h>. If NDEBUG is defined as a macro name at the
point in the source file where <assert.h> is included, the assert macro is defined
simply as
#define assert(ignore) ((void)0)
The assert macro is redefined according to the current state of NDEBUG each time that
<assert.h> is included

[...]

7.2.1.1 The assert macro
Synopsis
1 #include <assert.h>
void assert(scalar expression);
Description
2 The assert macro puts diagnostic tests into programs; it expands to a void expression.
When it is executed, if expression (which shall have a scalar type) is false (that is,
compares equal to 0), the assert macro writes information about the particular call that
failed (including the text of the argument, the name of the source file, the source line
number, and the name of the enclosing function — the latter are respectively the values of
the preprocessing macros __FILE_ _ and __LINE_ _ and of the identifier
__func_ _) on the standard error stream in an implementation-defined format. 165) It
then calls the abort function.

__>а значит, может быть не рассчитана на работу в условиях релиза
Стандарт вообще не оперирует такими словами, как Release и Debug. Самое ближайшее, что он знает, это макрос NDEBUG.

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


__>ну, смотрите, я читаю статью, написанную разработчиком компиляторов с 30-летним опытом, в которой говорится, что ошибки компилятора сами по себе очень редки, что в подавляющем большинстве случаев все равно вина за программистом.

Ну ему виднее, ага.

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

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

>, потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов

У старых тоже. В обсуждении ещё есть подтверждение от других людей, что они сталкивались. Ну и ещё поверь на слово, что мой начальник вообще не впечатлился моим рассказом о баге в МСВЦ2003, сказал "ачётакого я вообще им 30 репортов послал уже".

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

__>>это не совсем корректно делать
B>Да ну?

__>>потому что реализация самого ассерта "implementation defined"
B>Кто сказал?

	text
	B>ISO/IEC 9899:TC3 B> B>7.2 Diagnostics <assert.h> B>1 The header <assert.h> defines the assert macro and refers to another macro, B>NDEBUG B>which is not defined by <assert.h>. If NDEBUG is defined as a macro name at the B>point in the source file where <assert.h> is included, the assert macro is defined B>simply as B>#define assert(ignore) ((void)0) B>The assert macro is redefined according to the current state of NDEBUG each time that B><assert.h> is included B>[...] B>7.2.1.1 The assert macro B>Synopsis B>1 #include <assert.h> B>void assert(scalar expression); B>Description B>2 The assert macro puts diagnostic tests into programs; it expands to a void expression. B>When it is executed, if expression (which shall have a scalar type) is false (that is, B>compares equal to 0), the assert macro writes information about the particular call that B>failed (including the text of the argument, the name of the source file, the source line B>number, and the name of the enclosing function — the latter are respectively the values of B>the preprocessing macros __FILE_ _ and __LINE_ _ and of the identifier B>__func_ _) on the standard error stream in an implementation-defined format. 165) It B>then calls the abort function.

__>>а значит, может быть не рассчитана на работу в условиях релиза
B>Стандарт вообще не оперирует такими словами, как Release и Debug. Самое ближайшее, что он знает, это макрос NDEBUG.

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

__>хорошо, согласен, в такой формулировке он должен продолжить работать и в релизе. но! появляется же опасность рассогласованности — библиотеки могут, ориентируясь на NDEBUG, выставлять у себя кучу других макросов для релизной версии, а тут вы берете и в каком-то месте отключаете NDEBUG
Ты издеваешься?

#undef NDEBUG
#include <cassert>
#define NDEBUG

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

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


>>, потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов

TB>У старых тоже. В обсуждении ещё есть подтверждение от других людей, что они сталкивались. Ну и ещё поверь на слово, что мой начальник вообще не впечатлился моим рассказом о баге в МСВЦ2003, сказал "ачётакого я вообще им 30 репортов послал уже".

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

__>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)
Я тебе даже ссылки рядом привёл, там чётко сказано:

Thanks for the bug report. I confirm this is a bug in whole program optimization (/GL)

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

__>>хорошо, согласен, в такой формулировке он должен продолжить работать и в релизе. но! появляется же опасность рассогласованности — библиотеки могут, ориентируясь на NDEBUG, выставлять у себя кучу других макросов для релизной версии, а тут вы берете и в каком-то месте отключаете NDEBUG
B>Ты издеваешься?

B>

B>#undef NDEBUG
B>#include <cassert>
B>#define NDEBUG
B>

нет, просто не думал о таком варианте

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

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

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

__>>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)
B>Я тебе даже ссылки рядом привёл, там чётко сказано:

B>

B>Thanks for the bug report. I confirm this is a bug in whole program optimization (/GL)

я не вам писал. а в контексте того разговора, я просто пытаюсь объяснить, почему у меня возникло сомнение, а не то, что T4r4sB неправ.

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

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

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

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

__>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)

Именно про ошибку, проявляющуюся именно в релизе с O2, не с O1.

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

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

__>>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)

TB>Именно про ошибку, проявляющуюся именно в релизе с O2, не с O1.

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

__>>в смысле, майкрософт признал ошибку?
TB>То есть иначе ты не признаешь, что компиль может генерить лажу?
TB>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
Пока выглядит как применение reinterpret_cast к классу с ромбовидным наследованием.

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

O>Пока выглядит как применение reinterpret_cast к классу с ромбовидным наследованием.

Ещё раз: проблема именно в слое, на которые средствами С без асмовставок влиять невозможно.

http://www.gamedev.ru/flame/forum/?id=198083

Смотри, где на стеке находится число 12345678h, и чему равно значение esp на момент вызова i.

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

__>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)

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

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

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

__>>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)

L>О бесполезности, скорее.
L>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили

ну наконец-то, а то я уже стал волноваться

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

L>>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили
__>ну наконец-то, а то я уже стал волноваться

Я просто мимокрокодил

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

Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.
И этого ещё мало будет.