Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.

Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL

Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

Здравствуйте, Аноним, Вы писали:

А>Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL

На этапе компиляции

Здравствуйте, Аноним, Вы писали:

А>Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.

А>Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL

А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

по обстоятельствам...

если проверять — надо хорошо продумывать действия в случае невыполнеия условий.

хороший копромисс Debug.Assert

Здравствуйте, Аноним, Вы писали:

А>Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.

В таком случае это ответственность метода, который заполняет массив. Если он просто перебирает все элементы — я бы не стал заморачиваться с проверкой. Если логика сложнее — добавил бы метод, который проверял все элементы и вызывался бы только для debug-сборки.

Здравствуйте, Аноним, Вы писали:

А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

если это фатальная ошибка, и если вы сможете понять что получившийся null pointer dereference это та самая ошибка — то пусть падает.
иначе — если вы можете эту ошибку как-то обработать без закрытия программы, или хотите более информативное сообщение — сделайте NullClass который например будет бросать исключение при вызове каждого метода, и инициализируйте массив его объектами.

class AClass
{
public:
   virtual void method() = 0;

   virtual ~AClass() {}
};

class NullClass : public AClass
{
public:
   virtual void method() { throw some_exception(); }

   static NullClass* instance() { static NullClass inst; return &inst; }
   void operator delete(void*) {}
};

array arr[100];
arr.fill(NullClass::instance());

Здравствуйте, Аноним, Вы писали:

А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

Делать. Яркий пример отсутствия подобной проверки

Здравствуйте, Аноним, Вы писали:
А>Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.
А>Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL
А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.
проверять конечно надо. и разумнее делать это в одном месте, а не разбрасывать проверки по коду.

Я придерживаюсь вот такого правила:
Если программист перед использованием куска кода (метода) должен сам проверять и обеспечивать корректность, то использую Debug Assert. Т.е ассерт возможен только по причине ошибки программиста.
Если возможна ошибка пользователя (или по другим независящим от программиста причинам), то использую Exceptions или проверка состояния + код ошибки.

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

R>Я придерживаюсь вот такого правила:
R>Если программист перед использованием куска кода (метода) должен сам проверять и обеспечивать корректность, то использую Debug Assert. Т.е ассерт возможен только по причине ошибки программиста.
R>Если возможна ошибка пользователя (или по другим независящим от программиста причинам), то использую Exceptions или проверка состояния + код ошибки.
в релизе ассерты-то выкидываются. поэтому в релизе приложение будет просто падать. нужно кидать исключение или возвращать какое-то дефолтное значение в случае корявых данных, но не падать ни в коем случае

Здравствуйте, Аноним, Вы писали:

А>Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.

А>Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL

А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

вопрос поставлен недостаточно полно. нужно больше данных. скажем так, если у нас есть указатель на X, то все функции, работающие с этим указателем я пишу так, что они успешно "переваривают" ноль. даже если A передает X функции B, и дальше C и D -- все они проверяют в реал-тайме. и максимально корректно обрабатывают данную ситуацию без исключений. и даже зачастую не возвращают ошибку. например, сравнить две строки одна из которых NULL. ответ -- не равны. (правда, два NULL строки тоже не равны, но это особая ситуация).

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

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

но вообще правильный ответ на вопрос такой -- если вы можете _доказать_ (например, тестами или диаграммами состояний) что тут _гарантировано_ не будет нуля, то и проверять его не надо. аргумент "вдруг" неуместен. т.к. а вдруг тут указатель на освобожденную область памяти? ведь его ж не проверишь, что он инвалиден. и какой смысл проверять на ноль "для страховки", если ноль это одно из 2^32 возможных состояний (в среднем) и 2^31 из этих состояний неизвестны валидны или нет.

а иницилизировать массив указателем на объект-пустышку? тогда не нужно проверять на ноль.

Здравствуйте, Аноним

А вы что напрямую везде массив используете? пример в студию..

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

R>>Я придерживаюсь вот такого правила:
R>>Если программист перед использованием куска кода (метода) должен сам проверять и обеспечивать корректность, то использую Debug Assert. Т.е ассерт возможен только по причине ошибки программиста.
R>>Если возможна ошибка пользователя (или по другим независящим от программиста причинам), то использую Exceptions или проверка состояния + код ошибки.
__>в релизе ассерты-то выкидываются. поэтому в релизе приложение будет просто падать. нужно кидать исключение или возвращать какое-то дефолтное значение в случае корявых данных, но не падать ни в коем случае

Да, я согласен, что приложение не должно падать в любом случае. Иногда ассерты приходится комбинировать с исключениями или проверками, когда возможна и прогерская и пользовательская ошибка.
С ситуацией с debug assert я имел в виду, что они подходят для проверки явных программистских ошибок и должны быть выявлены в момент тестирования.
В любом случае, надо смотреть по ситуации (например, есть ли требования к производительности).

Здравствуйте, <Аноним>, Вы писали:

А>Есть массив указателей на классы.

"Умные" указатели использовать, с внутренней проверкой

k>не падать ни в коем случае
лучше падать, чем если просто ничего не происходит.
Замучили орлы, пишущие в стиле if(ничего не получилось){ никого не ставя в
известность, молча return;}
Хорошо если сразу по нажатию кнопки "ничего не делается", а может в составе
пакетной операции не заполняться какое-то поле, о чём узнают только после
наступления последствий.

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

А>>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

A>если это фатальная ошибка, и если вы сможете понять что получившийся null pointer dereference это та самая ошибка — то пусть падает.
A>иначе — если вы можете эту ошибку как-то обработать без закрытия программы, или хотите более информативное сообщение — сделайте NullClass который например будет бросать исключение при вызове каждого метода, и инициализируйте массив его объектами.

В условии сказано, что в момент вызова иметь в массиве NULL запрещено. Зачем пытаться сделать программу, работающую с ошибками, вместо того, чтобы пытаться сделать правильно работающую или не работающую вовсе?

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

R>>Я придерживаюсь вот такого правила:
R>>Если программист перед использованием куска кода (метода) должен сам проверять и обеспечивать корректность, то использую Debug Assert. Т.е ассерт возможен только по причине ошибки программиста.
R>>Если возможна ошибка пользователя (или по другим независящим от программиста причинам), то использую Exceptions или проверка состояния + код ошибки.
__>в релизе ассерты-то выкидываются. поэтому в релизе приложение будет просто падать. нужно кидать исключение или возвращать какое-то дефолтное значение в случае корявых данных, но не падать ни в коем случае

Почему выкидываются? Настройте, чтобы не выкидывались, и вопрос решен.

Дефолтное значение при корявых данных дает на выходе мерзкое поведение программы, которая вроде работает, а вроде и глючит.

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

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

А>>>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

A>>если это фатальная ошибка, и если вы сможете понять что получившийся null pointer dereference это та самая ошибка — то пусть падает.
A>>иначе — если вы можете эту ошибку как-то обработать без закрытия программы, или хотите более информативное сообщение — сделайте NullClass который например будет бросать исключение при вызове каждого метода, и инициализируйте массив его объектами.

S>В условии сказано, что в момент вызова иметь в массиве NULL запрещено. Зачем пытаться сделать программу, работающую с ошибками, вместо того, чтобы пытаться сделать правильно работающую или не работающую вовсе?

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

по этому надо делать программу которая будет не позволять делать ошибки или помогать отлавливать их.

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

А>>>>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

A>>>если это фатальная ошибка, и если вы сможете понять что получившийся null pointer dereference это та самая ошибка — то пусть падает.
A>>>иначе — если вы можете эту ошибку как-то обработать без закрытия программы, или хотите более информативное сообщение — сделайте NullClass который например будет бросать исключение при вызове каждого метода, и инициализируйте массив его объектами.

S>>В условии сказано, что в момент вызова иметь в массиве NULL запрещено. Зачем пытаться сделать программу, работающую с ошибками, вместо того, чтобы пытаться сделать правильно работающую или не работающую вовсе?

A>"иметь в массиве NULL запрещено" — не означает "иметь в массиве NULL невозможно". суть ошибок в том что они нарушают запреты.
A>как бы вам не хотелось не делать ошибок, вы их будете делать, если не предпримете меры для того чтобы ошибки были невозможны.

A>по этому надо делать программу которая будет не позволять делать ошибки или помогать отлавливать их.

Надо делать программу, которая если встретила ошибку, перестает работать, а не начинает глючить.
Вместо того, чтобы делать null class и пытаться продолжать работу, когда что-то уже явно развалилось, надо честно написать assert и падать.
Сэкономит пользователям массу нервов.

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

k>>не падать ни в коем случае
O>лучше падать, чем если просто ничего не происходит.
O>Замучили орлы, пишущие в стиле if(ничего не получилось){ никого не ставя в
O>известность, молча return;}
O>Хорошо если сразу по нажатию кнопки "ничего не делается", а может в составе
O>пакетной операции не заполняться какое-то поле, о чём узнают только после
O>наступления последствий.

Я не написал ничего про диагностические сообщения, логирование, емайлы итд, думаю это и так понятно.

Здравствуйте, Аноним, Вы писали:

А>Есть массив указателей на классы. Этот массив заполняется не сразу, постепенно, но если мы какой-то элемент массивы используем, то он уже должен быть заполнен. Ну то есть так устроено, что если мы начали его использовать, то он уже должен быть не NULL.

А>Но, разуммется, всякое бывает. Но такую ошибку очень легко поймать, компилятор сам гооврит — что вот тут NULL

А>Вот и вопрос — вставлять ли везде проверки на NULL, или наоборот, как средство дебага оставить, типа пусть падает, нам же проще будет отловить.

зависит от ситуации, но я бы советовал проверять всегда, если это не поделка на коленке. Использую простую логику: public/internal/protected методы — все параметры валидируются всегда и в случае ошибки валят исключение, которое ловится глобальным уловителем (и показывается юзверю) либо вызывающим методом; private методы — параметры не валидируются никогда.

"типа пусть падает, нам же проще будет отловить" звучит как-то детски, уж извините.