c++ Null vs nullptr

Но этого что-то мало и вроде я такое раз в год вызываю

Так можно про многие правила из стандарта сказать, типа я это почти не использую, а потому не нужно.

Так из-за этого и спрашиваю, где это используется?

у меня твой пример не компилируется.

 error: call of overloaded ‘foo(NULL)’ is ambiguous

MSVC 2013 собирал, там норм прошло

NULL это просто 0, ещё и определённый макросом, т.е. компилятор получит просто 0 в этом куске кода, некоторые конструкции аля auto не поймут что именно ты хотел использовать число или указатель

Effective Modern C++ Майерса.
Item 8: Prefer nullptr to 0 and NULL.

Показано развитие приведённого тобою примера для случая когда такие перегрузки за шаблонами скрыты.

nullptr нельзя по ошибке присвоить переменной, не являющейся указателем, с NULL такое скомпилируется и может потом привести к многочасовой отладке

А пример можно?

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

Если же тебе неймётся, все ответы есть на cppreference. NULL - это implementation-defined макрос который может в зависимости от реализации раскрываться в 0 или nullptr, поэтому вопрос сводится к тому почему нельзя использовать 0 (или, что эквивалентно, макрос который может в него раскрыться). Потому что это нарушает типобезопасность - 0 можно передать в функцию принимающую int, или сравнить с int’ом. Если ты сравниваешь NULL с int’ом, или передаёшь в качестве int’а - это явная ошибка, но в этом случае компилятор её не отловит. У nullptr таких проблем нет. Кроме того, он может участвовать в перегрузках (https://en.cppreference.com/w/cpp/types/nullptr_t).

сравниваю NULL с int

#include <iostream>
#include <string>
class Keker{
    };
int main()
{
    Keker *kek = new Keker;

    delete kek;   
    kek = NULL;
    int k = 0;
    if (kek == k)
        std::cout<<"lol!"<<std::endl;
}

ООП и прочая эзотерика

Дальше не читал

Я прочитал пример https://en.cppreference.com/w/cpp/types/nullptr_t т.е. если я все правильно понял, nullptr помогает явно указать, что должна вызываться ф-ия принимающая указатель и если у программиста функция, принимающая foo(int), а он где-то в дебрях кода передает ей нулевой указатель путем foo(NULL), то возможно он ошибся и nullptr от таких косяков уберегает, т.е. если даже программист забудет, чего принимает ф-ия, компилятор его поправит при nullptr, чего не будет при NULL?

Дальше не читал

да я пошутил, а то иногда напишут вместо пояснения «НАРУШАЕТ ПРИНЦИПЫ ООП» и гадай, что оно там нарушает

История примерно такая:
1) В С++ запретили неявное приведение void* к любому другому указателю, что в С разрешено. Внезапно, отломался код

int* foo = NULL;

#ifdef __cplusplus
#define NULL 0
#else
#define NULL (void*)0
#endif

И что вы хотели сказать этим примером? К NULL vs. nullptr он вообще никакого отношения не имеет.

Типобезопасность.

В чистом Си у тебя ведь перегрузки функций нет? Вот там это в ногу не выстрелит. А в костылях выстрелит и будет неприятно.

Вот и пиши nullptr, чтобы избежать двусмысленности.

А пример можно?

Например такой: #include <cstdlib>

int main()
{
        char str[] = "hello";
        char* p = str;
        /*
        что-то делаем со строкой
        */
        p = 0;
}

*p = '\0';

p = 0;

Но в gcc/clang есть полезное предупреждение

-Wzero-as-null-pointer-constant

NULL это просто 0, ещё и определённый макросом

NULL можно определить как nullptr, это не запрещено.

Довольно популярный вопрос. Потому ответ уже существует:

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nullptr

Но сломает туеву хучу существующего кода

Но сломает туеву хучу существующего кода

Забавно, но оно уже в стандарте с C++11 (provided cppreference не врет): https://en.cppreference.com/w/cpp/types/NULL

an integer literal with value zero, or a prvalue of type std::nullptr_t (since C++11)

Т.е. любишь кататься (С++11 и новее) люби и саночки возить (рефакторить).

Прикольно, не знал об этой фиче

Это разве может что-то сломать? Кроме уже сломанного кода

В стандарте много, что написано.

А вот одна из реальностей:

mingw-w64, gcc 8.2.0

#ifndef NULL
#ifdef __cplusplus
#ifndef _WIN64
#define NULL 0
#else
#define NULL 0LL
#endif  /* W64 */
#else
#define NULL ((void *)0)
#endif
#endif

Иногда, NULL определяют так:

#define NULL ((void*)0)

Иногда

Только в Си.

В стандарте много, что написано.

А небо синее.

А вот одна из реальностей:

Вполне соответствует стандарту.

Даже после моего сообщения (на которое даже ответил) не узнал о ней?

Дали им няшную растишечку - не хочу, хочу спорить о сортах NULL и nullptr.

Я не знал, что в gcc по-умолчанию такое определение

Деды говорили, что нужно писать так:

foo((int*)NULL);

Страуструп в http://www.stroustrup.com/N1488-nullptr.pdf (классный номер пропозала) утверждает, что в gcc с 98-го года (gcc 2.8.0) #define NULL __null чтобы было возможным выдавать предупреждения при преобразовании к целочисленному нулю.

Проверять я это конечно не буду.

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

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

это не компилятор а кусок говна,который слепливает из говна говно которое потом через раз работает. Если уже пользуешься ms, то минимум msvs 17 и с опциями /permissive- /Za

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

Шифт не нужно зажимать.