Как организовать дерево проекта для проекта C++, использующего nmake?
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
2 ответа
[Частичный ответ.]
В "Соглашении 2: высокоуровневые директора проекта, введите подкаталоги", Ваш единственный довод "против"
, Если существуют зависимости между проектами, Вам нужен дополнительный слой сценариев сборки выше каталогов проекта для управления порядком
сборки, Который может также быть просмотрен как про во многих проектах.
, Если бы у Вас есть много повторяющихся общих определений, можно было бы, вероятно, хотеть включать файл для сценариев сборки, где константы всего решения & параметры могли быть определены. Таким образом, "дополнительный слой сценариев сборки" будет часто происходить так или иначе, даже если не будет никаких (прямых) зависимостей.
Это - про в этом существует все еще комната для более модульного подхода в здании. С другой стороны, если бы Вы хотите снова использовать проект в другом, несвязанном решении, необходимо было бы составить различный файл определений. (На другой другой руке, если бы был единственный файл типа "build" для целого решения, как в Соглашении 1, Вам был бы нужен различный сценарий сборки.) Что касается Вашего требования к обслуживанию, это (IMO) очень проекта зависимый.
Мое чувство склоняется к Соглашению 2, но это далеко от ясной победы. На самом деле Ваш опыт с Соглашением 1, которое работало хорошо до недавнего времени, может быть самыми большими про из всех: команда людей с опытом с определенной организацией является ценным активом.
Рассмотрите использование точки соединения NTFS , таким образом, у Вас могут быть обе организации сразу. Быстрое определение: "точка соединения является реализацией Microsoft символьных ссылок, но это только работает на каталоги".
Соглашение 2 Использования для "реального" расположения, потому что это делает проекты легкими переместиться. Тогда сделайте представление Соглашения 1:
mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test
Теперь Вы имеете...
/solution
/test
/prj1
/prj2
..., который был желаемым результатом.
Вы могли сделать то же самое для/src или других каталогов при нахождении его выгодным. Сценарии тестирования, которые извлекают выгоду из представления Соглашения 1, живого в/solution/test.