Почему в Visual Studio есть отдельные папки Debug и Release?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
9 ответов
Насколько я понимаю, это просто удобство на машине разработчика, позволяющее им компилировать и запускать сборки Debug и Release одновременно.
Если у вас есть скрипты или инструменты, запущенные внутри Visual Studio, IDE позволяет вам использовать ConfigurationName и другие макросы для получения путей, которые не зависят от конфигурации.
Если вы запускаете сценарии и инструменты извне из командной строки (т. Е. Вы структурируете какой-то процесс выпуска или развертывания вокруг этого), лучше сделать это на сервере сборки, где различие между отладкой и выпуском уходит.
Например, когда вы вызываете msbuild из командной строки (на сервере сборки), вы можете указать свойство Configuration для Debug или Release и свойство OutputPath для сборки только в одном месте (независимо от конфигурации).
Иногда можно столкнуться с особенно неприятной неинициализированной проблемой с памятью, которая возникает только при выпуске сборки. Если вы не можете поддерживать (как предлагает ChrisF) отдельные имена для ваших отладочных и релизационных двоичных файлов, то очень легко потерять информацию о том, какой двоичный файл вы используете в данный момент.
Кроме того, вы можете столкнуться с изменением настроек компилятора (т.е. уровня оптимизации, символов release-with-debug для легкого профилирования и т.д.), и гораздо проще держать их в порядке с помощью отдельных папок.
Однако это все дело личных предпочтений - именно поэтому Visual Studio позволяет легко менять опции.
Визуальные виды студийных видов IDes работают, что лучше всего для толпы. Они создают структуру проекта по умолчанию, двоичные папки. Вы можете сопоставить двоичные файлы в одну папку. Затем вам необходимо обучить другие разработчики, которые файлы отладки / отладки хранятся в той же папке.
Разработчики спросит вас, кто вам это нравится?
В VC ++ у нас есть разные библиотеки, и вам нужно связать соответствующие версии. В противном случае вы получите ошибку линкера.
В предыдущей компании мы обошли эту проблему, изменив названия отладочного исполняемого модуля и dll путем добавления буквы "D". Так
MainProgram.exe и library.dll
стали
MainProgramD.exe и libraryD.dll
Это означало, что они могли сосуществовать в одной выходной папке и все скрипты, пути и т.д. могли просто ссылаться на это. Промежуточные файлы все равно должны перейти в отдельные папки, так как их имена не могут быть изменены.
Очевидно, что вам нужно изменить все ссылки, чтобы указать на измененное имя для отладки - что вы в какой-то момент забудете сделать.
Дэйв, если вы будете компилировать отладку и выпуск в одну папку, вы можете столкнуться с ситуацией, когда некоторые DLL-S не будут перекомпилированы после переключения от выпуска для отладки и наоборот, потому что файлы DLL будут быть новым, чем исходные файлы. Да, «восстановление» должна помочь вам, но если вы забудете это - вы можете получить несколько дополнительных часов отладки.
Я обычно компилирую в режиме отладки, но иногда нужно компилировать в режиме выпуска. К сожалению, они не ведут себя точно так же в определенных ситуациях ошибок. Наличие отдельных папок, мне не нужно перекомпилировать все, чтобы просто изменить режимы (и полное перекомпиляр наших материалов в режиме выпуска займет некоторое время).
Одна из причин, по которой я использую отдельные папки, заключается в том, что это гарантирует, что я генерирую только программы установки, использующие код Release-build. Я использую WiX, который позволяет мне указать точный путь к файлам, которые я хочу включить в программу установки, поэтому в конце концов я указываю путь в папке Release. (Конечно, вы можете сделать то же самое, используя обычные инсталляторы VS, так что на самом деле дело не в этом). Если вы забыли переключить свой проект на Release перед сборкой, то программа установки не собирается, если только у вас нет старого кода в папке Release, и в этом случае вы получаете старую программу установки, так что это немного подводит. Я могу обойти это, используя событие после сборки в проекте инсталлятора WiX, которое очищает папку Release после сборки инсталлятора WiX.
Быть последовательным в ваших сборках - это хорошо. Вы не хотите иметь дело с проблемами, связанными с условной компиляцией / и т. Д. где ваши DLL выпуска и отладки несовместимы, но вы пытаетесь запустить их друг против друга.
Важно то, что все остальные говорили о технических аспектах. Другой аспект заключается в том, что вы можете столкнуться с условиями гонки, если одна сборка опирается на сборку с одним выходным местоположением, но между двумя сборками нет синхронизации. Если первая сборка может быть повторно запущена (особенно в другом режиме) после запуска второй сборки, вы действительно не узнаете, используете ли вы отладку сборки выпуска.
И не забывайте о человеческом аспекте: гораздо легче узнать, с чем вы работаете (и исправить неработающие сборки), если две сборки выводятся в разные места.