Соответствующие варианты использования для нулевых указателей
- Перенаправление на что-то вроде более глубокого узла дерева, который может не существовать или еще не был связан. Это то, что вы всегда должны хранить в отдельности в специальном классе, поэтому удобочитаемость или краткость не являются большой проблемой.
Динамические броски. Приведение указателя базового класса к конкретному производному классу (то, что вы должны снова попытаться избежать, но иногда может оказаться необходимым) всегда завершается успешно, но приводит к нулевому указателю, если производный класс не совпадает. Один из способов проверить это
Derived* derived_ptr = dynamic_cast<Derived*>(base_ptr);
if(derived_ptr != nullptr) { ... }
(или, предпочтительно, auto derived_ptr = ...). Теперь это плохо, потому что он оставляет (возможно, недопустимый, то есть нулевой) производный указатель за пределами области действия защитного ifблока. В этом нет необходимости, поскольку C ++ позволяет вводить переменные, логически конвертируемые в if-условии :
if(auto derived_ptr = dynamic_cast<Derived*>(base_ptr)) { ... }
который не только короче и безопаснее по объему, но и гораздо более понятен в своем намерении: когда вы проверяете на null в отдельном условии if, читатель задается вопросом: « derived_ptrХорошо, поэтому здесь не должно быть null ... ну, зачем это будет ноль? В то время как однострочная версия говорит очень просто: «Если вы можете безопасно привести base_ptrк Derived*, то используйте ее для ...».
То же самое работает и для любой другой операции возможного сбоя, которая возвращает указатель, хотя в IMO следует избегать этого: лучше использовать что-то вроде boost::optional«контейнера» для результатов возможных неудачных операций, а не указателей.
Итак, если основной сценарий использования нулевых указателей всегда должен быть написан в варианте неявного стиля приведения, я бы сказал, что по соображениям согласованности всегда следует использовать этот стиль, т. Е. Я бы рекомендовал использовать if(ptr)более if(ptr!=nullptr).
Боюсь, я должен закончить рекламой: if(auto bla = ...)синтаксис - это всего лишь немного громоздкое приближение к реальному решению таких проблем: сопоставление с образцом . Зачем вам сначала предпринимать какие-то действия (например, приведение указателя), а затем считать, что может произойти сбой ... Я имею в виду, это смешно, не правда ли? Как будто у вас есть продукты и вы хотите приготовить суп. Вы передаете его своему помощнику с задачей извлечь сок, если он окажется мягким овощем. Вы сначала не смотрите на это. Когда у вас есть картошка, вы все равно отдаете ее своему помощнику, но они бьют ее по лицу с запиской об ошибке. Ах, императивное программирование!
Намного лучше: рассмотрите сразу все случаи, с которыми вы можете столкнуться. Тогда действуй соответственно. Haskell:
makeSoupOf :: Foodstuff -> Liquid
makeSoupOf p@(Potato{..}) = mash (boil p) <> water
makeSoupOf vegetable
| isSoft vegetable = squeeze vegetable <> salt
makeSoupOf stuff = boil (throwIn (water<>salt) stuff)
На Haskell также есть специальные инструменты для случаев, когда существует серьезная вероятность отказа (как и для целого ряда других вещей): монады. Но это не место для объяснения этого.
⟨/объявление⟩
0илиnullptr. (NULLявляется C'ism и требует включения заголовочного файла.)