Я заметил, что при создании нового проекта C++ с помощью MS Visual Studio 2008 сборка Выпускать содержит символы отладки - в частности, включены следующие параметры:
Я никогда не замечал этого в более ранних выпусках Visual Studio.
Итак, есть ли какие-либо недостатки в том, чтобы оставить эти настройки включенными, кроме создания более крупного EXE-файла?
Это верно и для VC10 ...





Что ж, вы можете предоставить эту отладочную информацию, и кто-то может использовать ее для дизассемблирования вашего кода. Для некоторых напуганных людей это само по себе может быть причиной не оставлять это таким образом.
Лично я думаю, что иногда полезно иметь доступную отладочную информацию для окончательной версии - так намного проще анализировать аварийный дамп, который будет сохранен доктором Ватсоном в случае сбоев приложения. Таким образом я обнаружил несколько очень малоизвестных ошибок.
Эти параметры не обязательно увеличивают размер ваших исполняемых файлов. Отладочная информация хранится в отдельном файле с расширением PDB. Наличие отладочной информации никогда не является плохой идеей, если вам действительно не хватает свободного места для хранения.
Возможно, поэтому они включены по умолчанию: они не вредят вашим исполняемым файлам. В сборках выпуска используются такие оптимизации, как встраивание функций и генерация оптимизированного кода, что затрудняет пошаговое выполнение, в то время как в сборках отладки эти параметры отключены.
Здесь нет недостатков.
Дэйв
Мы уже много лет включаем эти настройки в наших коммерческих выпусках без видимых недостатков. Однако положительные стороны огромны.
Мы интегрировали упаковщик аварийного дампа, который упаковывает дамп вместе с некоторой другой информацией и отправляет его (с согласия пользователя) в почтовый ящик компании. Это помогло нам найти проблемы, на воспроизведение которых потребовалось бы навсегда, и найти их иначе.
Хотя это немного не по теме, вот ссылка на отличный вклад, сделанный кем-то, который дает вам простой способ включить репортер сбоев в приложение C++ / Windows: http://www.codeproject.com/KB/debug/crash_report.aspx
Примечание. Было бы разумно не включать файл PDB в ваш выпуск. Тем не менее, вы должны сохранить файл PDB, который соответствует вашей выпущенной версии, чтобы вы могли правильно отладить проблему в будущем. Если используется файл PDB, который не был создан с использованием того же кода, что и для exe, стек, который вы видите при попытке отладки dmp, будет неправильным.
На аналогичный вопрос несколько лет спустя следующий ответ дал еще несколько подробностей: stackoverflow.com/a/6364789/2937955 (см. Интересное примечание о реверс-инжиниринге и опции / PDBSTRIPPED)
.Exe будет немного больше из-за ссылки на файл .pdb (т. Е. Дополнительного пути). Вот об этом.
Добавление переключателя / Zi делает файл .exe большего размера в дополнение к PDB. Однако вы можете установить отдельную ссылку с помощью / OPT: REF, чтобы минимизировать размер файла .exe.
В Visual Studio 2008 этот параметр находится в разделе «Свойства-> Компоновщик-> Оптимизация-> Ссылки». Вы также можете рассмотреть возможность включения «Включить COMDAT Folding», который также уменьшит двоичный размер.
По умолчанию они включены, потому что:
Включение отладочной информации в Visual C++ приводит к добавлению небольшой записи в двоичный заголовок, идентифицирующей PDB для этого двоичного файла. Он слишком мал, чтобы иметь какое-либо значение, и не содержит каких-либо полезных секретов, которыми вы, возможно, захотите поделиться.
(Заголовок помечен как RSDS: кто может догадаться, почему?)
Конечно, эти PDB будут использовать больше дискового пространства на вашей машине сборки / в ваших резервных копиях. Смирись с этим. Эти PDB нужны, когда приходит время что-то отлаживать.
Пожалуйста, уточните, действительно ли у вас есть EXE-файлы большего размера или (если, как предлагает Дэйв Ван ден Эйнде) вся дополнительная информация будет отправляться в файл PDB.