3 ms·
> N3042 - Introduce the nullptr constant They should have formally defined NULL as void* instead. > Someone recently challenged me, however: they said this ch
by hgs3 4y ago
> N3042 - Introduce the nullptr constant
They should have formally defined NULL as void* instead.
> Someone recently challenged me, however: they said this change is not necessary and bollocks, and we should simply force everyone to define NULL to be void*.
I'm glad someone brought it up. The scenarios nullptr "fixes" are so minor adding a new null concept to fix them is the sort of overkill solution I expect from the C++ committee, not the C committee. It's a shame this wasn't thought-out more.
> I said that if they’d like that, then they should go to those vendors themselves and ask them to change and see how it goes.
The C committee has already broken compatibility on numerous occasions: forcing 2's complement representation, changing the type of u8"" string literals from char to unsigned char, removing mixed wide string literal concatenation (allowed in C11, disallowed in C23). It's difficult to be convinced by the argument of backwards compatibility when the committee has already broken it on multiple occasions. Furthermore, I seriously doubt compiler vendors who define NULL as 0 would take issue with redefining it as void*. This change is so minor and inconsequential there should be no push back.
- stonemetal12 4y agoI am not all that standards savvy, so pardon my ignorance. >Introduce the nullptr constant >They should have formally defined NULL as void* instead. That doesn't make any sense to me. void* is a type isn't it? nullptr is a value. I don't see the overlap.
- hgs3 4y ago> That doesn't make any sense to me. void* is a type isn't it? nullptr is a value. I don't see the overlap The C standard permits NULL to be defined as (void*)0 or 0. The issue is this creates an inconstancy when NULL is used with _Generic selection: a compiler defining NULL as (void*)0 will cause NULL to be caught by a pointer case whereas a compiler defining NULL as 0 will cause it to be caught by an integer case. This inconsistently could be solved by mandating NULL be defined as (void*)0 so it will always be caught by the pointer case. The issue is instead of mandating (void*)0 the C committee decided to introduce a whole new nullptr concept. This duplicates the concept of null in the language and requires all C compiler vendors to modify the languages type system to account for it. So it creates more work for vendors and duplicates the concept of null all to solve this minor use case.
- deleted 4y ago[deleted]