3 ms·
> 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 c
by 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 agoThe 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 agoGreat 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.