Здравствуйте, _hum_, Вы писали:
__>и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?
glogs, например.
N>>2. Если всё такое кроссплатформенное, то Linux. __>а при чем тут Ос? вроде, проблема кросс-платформенная
В другой ОС другие средства для анализа, другой компилятор.
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, lpd, Вы писали:
lpd>>Здравствуйте, _hum_, Вы писали:
__>>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>>вот и непонятно, в какую сторону двигаться
lpd>>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
__>мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект __>может, есть какие-то сторонние анализаторы именно такой проблемы?
Можно попробовать запустить под valgrind. Также в аналогичной ситуации мне однажды пришлось перегружать во всем проекте функции выделения памяти, метить границы буферов и вести счетчики выделения/освобождения, — эти меры помогли. Но скорее всего, дело в недавних изменениях, и может оказаться легче откатывать постепенно все правки, пока программа не начнет стабильно работать
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
Можно поставить генерацию отладочной информации в Release.
Ложных ( а может, и не ложных, у меня он в boost-библиотеке ошибки нашел, но мне не до отладки boost) тревог будет много, но, возможно, найдешь что-то важное. Я нашел.
Дальше надо искать причину путем отладки, можно в Debug.
Еще для этой же цели можно использовать Bounds Checker
Когда-то он был очень хорош, пока был от Numega. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.
P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо. __>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться. __>первым делом включил уровень /w4 ворнингов, с надеждой обнаружить нужное. но нет, ничего значительного. __>далее попытался проверить код встроенным в VS2013 анализатором кода, но анализатор споткнулся на попытках проанализировать используемые boost-овские файлы и выдал internal error __>была надежда на psv-студию, но она только под win x64, а у меня стоит win7 x32 __>думал попробовать вручную — сделать ассерты для релизной версии, но хорошего решения, не засоряющего код, пока не нашел (у меня код, относящийся к бизнес-логике, работает только с boost и cereal, а код gui — на qt. выбросить ассерт через std::excеption (а как по-другому, чтоб универсально?) оказалось в qt проблематичным (qt, по-видимому, не очень дружит с c++ exception-ами)
__>вот и непонятно, в какую сторону двигаться
Здравствуйте, _hum_, Вы писали:
__>вот и непонятно, в какую сторону двигаться
1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса
2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
Здравствуйте, 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_, Вы писали:
L>>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили __>ну наконец-то, а то я уже стал волноваться
в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М 1.2М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.
первым делом включил уровень /w4 ворнингов, с надеждой обнаружить нужное. но нет, ничего значительного.
далее попытался проверить код встроенным в VS2013 анализатором кода, но анализатор споткнулся на попытках проанализировать используемые boost-овские файлы и выдал internal error
была надежда на psv-студию, но она только под win x64, а у меня стоит win7 x32
думал попробовать вручную — сделать ассерты для релизной версии, но хорошего решения, не засоряющего код, пока не нашел (у меня код, относящийся к бизнес-логике, работает только с boost и cereal, а код gui — на qt. выбросить ассерт через std::excеption (а как по-другому, чтоб универсально?) оказалось в qt проблематичным (qt, по-видимому, не очень дружит с c++ exception-ами)
вот и непонятно, в какую сторону двигаться
upd. суть оказалось в использовании неинициализированных переменных (почему-то vs не все случаи может отслеживать) — при установке в vs /sdl вероятно, студия начала перезаписывать эти переменные, и у меня перестал работать даже debug версия, что позволило легко обнаружить место и саму пробелему простым дебагингом.
всем спасибо за советы. приму на будущее к сведению
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
N>1. Логи.
и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?
N>2. Если всё такое кроссплатформенное, то Linux.
а при чем тут Ос? вроде, проблема кросс-платформенная
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
V>1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса
во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить
V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
но ведь w4 не ругался (обычно он ругается на неинициализированные).
Здравствуйте, _hum_, Вы писали:
__> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить
Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.
__>но ведь w4 не ругался (обычно он ругается на неинициализированные).
Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.
дебаг-версия работает, как надо, релизная не так, как надо
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>вот и непонятно, в какую сторону двигаться
Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.
Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, kov_serg, Вы писали:
_>>Попробуй разные уровние оптимизации в release.
__>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?
Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.
Здравствуйте, tdiff, Вы писали:
T>Здравствуйте, _hum_, Вы писали:
__>>Здравствуйте, kov_serg, Вы писали:
_>>>Попробуй разные уровние оптимизации в release.
__>>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?
T>Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.
во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить V>Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.
это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный?
__>>но ведь w4 не ругался (обычно он ругается на неинициализированные). V>Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.
вроде, проверяет. по кр. мере, при попытке использования неинициализированной переменной он выдавал исключение.
V>
V>дебаг-версия работает, как надо, релизная не так, как надо
V>что изменяется то хоть можно узнать ?
есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна
[да-да, знаю, что можно повводить коды невалидности и отслеживать, что да как. но это все-таки серьезный кусок работы, ис перва хотелось бы выслушать другие варианты решения, чтоб уже с чистой совестью закасывать рукава]
Здравствуйте, _hum_, Вы писали:
__> во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>вот и непонятно, в какую сторону двигаться
lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект
может, есть какие-то сторонние анализаторы именно такой проблемы?
Здравствуйте, _hum_, Вы писали:
__> это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный?
ну придумайте метрику какую-нибудь
__>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна
Эмулятор конечно же "черный ящик". Упростить модель можно? Пустая модель тоже невалидна?
А многопоточность есть?
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна V>Эмулятор конечно же "черный ящик".
все — белый ящик. просто очень большой и не совсмем прозрачный. поэтому лезть в него ох как неохота.
V>Упростить модель можно? Пустая модель тоже невалидна?
пустая модель невалидна для эмулятора по определению
V>А многопоточность есть?
Здравствуйте, _hum_, Вы писали:
__>вот и непонятно, в какую сторону двигаться
Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
вы были правы — проблема крылась в использовании неинициализированных переменных
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, _hum_, Вы писали:
__>>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.
Pzz>А никак. Отлаживать заново.
Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.
проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>вот и непонятно, в какую сторону двигаться
lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
нет, если бы был выход за пределы, то студия бы обнаружила в дебаг версии (потому что она такие проверки делает). а вот с использованием неинициализированных переменных сложнее. именно этот случай у меня и вылез.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
EP>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
я почему-то думал, что вы опять начнете про юнит-тестирование говорить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, _hum_, Вы писали:
PD>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
PD>Можно поставить генерацию отладочной информации в Release.
PD>https://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx
PD>Будут работать точки прерывания. Хотя по моему опыту ничему тому, что показывает отладчик, верить нельзя — слишком уж хорошо код оптимизирован.
PD>Лучше попробуй запустить для Debug версии (или Release версии с отладочной информацией) вот это
PD>http://www.drmemory.org/
PD>Ложных ( а может, и не ложных, у меня он в boost-библиотеке ошибки нашел, но мне не до отладки boost) тревог будет много, но, возможно, найдешь что-то важное. Я нашел.
PD>Дальше надо искать причину путем отладки, можно в Debug.
PD>Еще для этой же цели можно использовать Bounds Checker
PD>http://www.borland.com/en-GB/Products/Software-Testing/Automated-Testing/Devpartner-Studio
PD>(Как вам имя сайта, а ? Жив курилка
PD>Когда-то он был очень хорош, пока был от Numega. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.
спасибо. приму к сведению на будущее. а дело было в "использование неинициализированных переменных/полей " (студия это не может напрямую обнаружить, но специально делает разное заполнение в дебаг и релиз версии начальные значения, чтобы хоть как-то указать на то, что что-то не так )
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
L>Может еще не совсем актуальность потеряло: L>http://rsdn.org/article/vcpp/survrls.xml
L>)
L>P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
BFE>"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?
самый худший вариант — работает не так, как ожидалось, но не не падает.
Здравствуйте, _hum_, Вы писали:
__>>>вот и непонятно, в какую сторону двигаться EP>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций. __> я почему-то думал, что вы опять начнете про юнит-тестирование говорить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, _hum_, Вы писали:
PD>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.
И вообще, что значит "не так, как надо"?
/w4 полезно держать включенным постоянно.
Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.
А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>>>вот и непонятно, в какую сторону двигаться EP>>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций. __>> я почему-то думал, что вы опять начнете про юнит-тестирование говорить
EP>В контексте чего я про него говорил?
ааа. сори, это я вас с Stanislav V. Zudin перепутал (тоже ник — фамилия, имя)
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, _hum_, Вы писали:
PD>>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
TB>Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...
Оптимизирующий компилятор делает различные предположения о той сущности, с которой он имеет дело. Проблема в том, что взгляд компилятора на реальность целиком базируется на ряде предположений, все из которых программист на C может очень легко нарушить. Результатом этой неправильной интерпретации реальности будет то, что вы можете обмануть компилятор, заставив его генерировать "плохой код". В действительности, он не плохой — это совершенно правильный код, при условии, что предположения компилятора были верны. Если вы явно или неявно лгали компилятору, то с него взятки гладки.
Здравствуйте, VTT, Вы писали:
VTT>Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.
нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М [просто это, имхо, наиболее адекватная оценка объема информации в коде. все остальные оценки наподобие — число строк, число слов и проч. — очень сильно зависят от стилистики]
VTT>И вообще, что значит "не так, как надо"?
писал выше — работает не так, как ожидалось, когда "2+2 = 5"
VTT>/w4 полезно держать включенным постоянно.
ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
VTT>Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.
статические как раз-таки помогли бы. тут проблема найти рабочий
VTT>А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.
ассерты в дебаг версии не работают. надо писать свои. вот и проблема, как лучше это сделать.
Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал.
Пруф могу найти.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>
__>>"Ошибки" компилятора
TB>Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал. TB>Пруф могу найти.
По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.
__>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
Можно явно указывать, что они не используются.
__>ассерты в дебаг версии не работают
-_-'
это как так?
даже просто __debugbreak?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.
__>>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
VTT>Можно явно указывать, что они не используются.
как именно?
__>>ассерты в дебаг версии не работают VTT>-_-' VTT>это как так?
Здравствуйте, _hum_, Вы писали:
__>в смысле, майкрософт признал ошибку?
То есть иначе ты не признаешь, что компиль может генерить лажу?
Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, _hum_, Вы писали:
__>нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М
Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>в смысле, майкрософт признал ошибку?
TB>То есть иначе ты не признаешь, что компиль может генерить лажу? TB>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М
EP>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.
да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта]
Здравствуйте, _hum_, Вы писали:
EP>>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка. __>да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта]
Не не не Девид Блейн, мегабайт это у Eigen исходники столько весят.
Найди все исходники по расширению, скопируй в отдельную папку и потом измерь.
Здравствуйте, _hum_, Вы писали:
__>>>в смысле, майкрософт признал ошибку? TB>>То есть иначе ты не признаешь, что компиль может генерить лажу? TB>>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект. __>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость
Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>Здравствуйте, _hum_, Вы писали: EP>>>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка. __>>да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта] EP>Не не не Девид Блейн, мегабайт это у Eigen исходники столько весят. EP>Найди все исходники по расширению, скопируй в отдельную папку и потом измерь.
может, архиватор плохо архивирует...но вроде ничего не поменялось:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>может, архиватор плохо архивирует...но вроде ничего не поменялось:
EP>Например сколько строк в файле BasicLevel_ControlUnit.cpp? Ты его сам писал или всё-таки сгенерировал?
__>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость
Я понял, тебе не интересно почитать про конкретные детали моего случая. Тебе хочется самоутвердиться. У тебя нет нормального любопытства, только желание тупо возвыситься.
Досвиданья.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
__>в смысле, майкрософт признал ошибку?
А чему вы так удивляетесь?
Мне, например, хорошо запомнился баг с возвращением float'ов из switch-case блоков в MSVC-11.0. Ловил целый день.
Баг-репорты тут и тут.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость
TB>Я понял, тебе не интересно почитать про конкретные детали моего случая. Тебе хочется самоутвердиться. У тебя нет нормального любопытства, только желание тупо возвыситься. TB>Досвиданья.
T4r4sB, вы меня огорошили таким ответом. вы же научный сотрудник, насколько я понимаю. вам ли не знать, что всякое высказывание нужно подвергать разумному сомнению. вот я его и высказал (ни коим образом не собираясь тем самым как-то принизить вас как специалиста), ожидая услышать какие-то подтверждения вашим словам (например, как сделал Evgeny.Panasyuk , приведя ссылки на зафиксированные баги компилятора).
на всякий случай, прошу прощения, если мои слова вас все-таки задели.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>вы были правы — проблема крылась в использовании неинициализированных переменных
V>О-о-о! Очень рад за вас . Но это вам звоночек. Следующий раз так не повезет. Лучше пишите сразу нормально, с инициализацией, ассертами и юнит-тестами.
я все время пишу с инициализациями, просто помимо написания кода есть еще и переписывание. и вот на этом этапе уследить уже за такими вещами становится сложнее
__>>>ассерты в дебаг версии не работают B>>Чёт не понял. Не работают или не срабатывают?
__>там просто пропустил "не" — в "не дебаг версии" ассерты не работают
Здравствуйте, b0r3d0m, Вы писали:
__>>>>ассерты в дебаг версии не работают B>>>Чёт не понял. Не работают или не срабатывают?
__>>там просто пропустил "не" — в "не дебаг версии" ассерты не работают
B>
B>#undef NDEBUG
B>#include <cassert>
B>
B>???
не понял вас, что вы хотели этим сказать.
Standard library header <cassert>
C++
Standard Library header files
This header was originally in the C standard library as <assert.h>.
This header is part of the error handling library.
Здравствуйте, _hum_, Вы писали:
__>ожидая услышать какие-то подтверждения вашим словам
Вопрос в том, что ты считаешь подтверждением. Если тебе интересно именно обсуждение моего случая с выкладками асмовыхлопа, это одно. А если тебе это неинтересно, тебе нужны лишь официальные документы, а без них ты предпочитаешь считать, что это я напортачил — ну считай дальше.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>ожидая услышать какие-то подтверждения вашим словам
TB>Вопрос в том, что ты считаешь подтверждением. Если тебе интересно именно обсуждение моего случая с выкладками асмовыхлопа, это одно. А если тебе это неинтересно, тебе нужны лишь официальные документы, а без них ты предпочитаешь считать, что это я напортачил — ну считай дальше.
ну, смотрите, я читаю статью, написанную разработчиком компиляторов с 30-летним опытом, в которой говорится, что ошибки компилятора сами по себе очень редки, что в подавляющем большинстве случаев все равно вина за программистом.
тут вы говорите, что у вас был именно такой случай. вот я и высказал сомнение (я же вас лично не знаю, насколько вы компетентны в данной области). технические детали мне скорее всего будут непонятны (ибо я в низкоуровневом программировании не силен), потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов (например, через отсылку на баг-фиксы того же майкросовфт), или какое-то обоснование роста вероятности таких ошибок (например, из-за роста сложности компиляторов и ограниченности возможностей их автоматической проверки). только и всего. ничего личного (я вас как раз наоборот ценю за аналитический ум, хоть вы порой и очень категоричны )
__>ну, смотрите, я читаю статью, написанную разработчиком компиляторов с 30-летним опытом, в которой говорится, что ошибки компилятора сами по себе очень редки, что в подавляющем большинстве случаев все равно вина за программистом.
Ну ему виднее, ага.
__>технические детали мне скорее всего будут непонятны (ибо я в низкоуровневом программировании не силен)
Жаль. Там асмто достаточно знать на уровне "куда указывает есп, и что сидит в еах".
>, потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов
У старых тоже. В обсуждении ещё есть подтверждение от других людей, что они сталкивались. Ну и ещё поверь на слово, что мой начальник вообще не впечатлился моим рассказом о баге в МСВЦ2003, сказал "ачётакого я вообще им 30 репортов послал уже".
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, 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
Ты издеваешься?
Здравствуйте, 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>
Здравствуйте, 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.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)
TB>Именно про ошибку, проявляющуюся именно в релизе с O2, не с O1.
хорошо. спасибо. теперь буду иметь в в иду и о таких превратностях судьбы (надеюсь, меня они минут, ибо в анализе дезасемблированнго кода я не мастер).
__>>в смысле, майкрософт признал ошибку? TB>То есть иначе ты не признаешь, что компиль может генерить лажу? TB>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
Пока выглядит как применение reinterpret_cast к классу с ромбовидным наследованием.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, _hum_, Вы писали:
__>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)
О бесполезности, скорее.
Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
__>>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)
L>О бесполезности, скорее. L>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.
И этого ещё мало будет.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]