3 ms·

> If we assume that nullptr and auto mean the same as in C++ then what problem does nullptr fix in C? For starters, it fixes the same problems it fixed on C++.

> If we assume that nullptr and auto mean the same as in C++ then what problem does nullptr fix in C? For starters, it fixes the same problems it fixed on C++. I'm talking about stuff like automatic type conversion to ints and consequently being forced to babysit when your compiler called foo(int) instead of food(bar *) just because you passed NULL. Also, keep in mind that these features are low-hanging fruits to any compiler writer, especially those who already maintain compilers that support C and C++. Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features".

pjmlp 4y ago
As addendum to that, in C++ there was a period before nullptr came to be, that best practice for null pointers was to use 0 directly instead of NULL exactly because of that. https://stackoverflow.com/questions/54098794/is-null-guaranteed-to-be-0 https://stackoverflow.com/questions/54098794/is-null-guarant...
robalni 4y ago
> when your compiler called foo(int) instead of food(bar *) just because you passed NULL That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name (assuming you meant foo instead of food). > Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features". That's not an argument; that's a question. I wanted to know whether there was any reason to start using nullptr, like if there is a risk of making a bug if I use NULL. I did later find a page about nullptr in C [1] that talks about some risks of using NULL with varargs. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm
- yakubin 4y ago
  > That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name But you can have a macro foo which expands to a generic selection: <https://docs.microsoft.com/en-us/cpp/c-language/generic-selection?view=msvc-170 https://docs.microsoft.com/en-us/cpp/c-language/generic-sele...>
  - hgs3 4y ago
    The committee should have standardized on defining NULL as (void*)0 which would have allowed _Generic to catch NULL with a void* type. This seems better than adding a whole new nullptr concept just for this one off "problem".
    - GabrielTFS 4y ago
      Great idea ! Now, try to convince the 30 implementers that did the wrong choice and will tell you they'll never change it because of backwards compatibility.

pjmlp 4y ago

As addendum to that, in C++ there was a period before nullptr came to be, that best practice for null pointers was to use 0 directly instead of NULL exactly because of that. https://stackoverflow.com/questions/54098794/is-null-guaranteed-to-be-0 https://stackoverflow.com/questions/54098794/is-null-guarant...

robalni 4y ago

> when your compiler called foo(int) instead of food(bar *) just because you passed NULL That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name (assuming you meant foo instead of food). > Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features". That's not an argument; that's a question. I wanted to know whether there was any reason to start using nullptr, like if there is a risk of making a bug if I use NULL. I did later find a page about nullptr in C [1] that talks about some risks of using NULL with varargs. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm

yakubin 4y ago
> That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name But you can have a macro foo which expands to a generic selection: <https://docs.microsoft.com/en-us/cpp/c-language/generic-selection?view=msvc-170 https://docs.microsoft.com/en-us/cpp/c-language/generic-sele...>
- hgs3 4y ago
  The committee should have standardized on defining NULL as (void*)0 which would have allowed _Generic to catch NULL with a void* type. This seems better than adding a whole new nullptr concept just for this one off "problem".
  - GabrielTFS 4y ago
    Great idea ! Now, try to convince the 30 implementers that did the wrong choice and will tell you they'll never change it because of backwards compatibility.