OSDev.org

-m32 wrote:One thing I think is just frigging stupid:

Code: Select all

nullptr

WTF? Every other language uses NULL or null. Are they just trying to defy convention? No sh|t null is used in the context of pointers.

How much code would break if they called it either of the above suggestions?

Owen wrote:

-m32 wrote:One thing I think is just frigging stupid:

Code: Select all

nullptr

WTF? Every other language uses NULL or null. Are they just trying to defy convention? No sh|t null is used in the context of pointers.

How much code would break if they called it either of the above suggestions?

Perhaps because in certain situations, 0 is a valid pointer, in which case you can define nullptr to something you would know would be invalid.

MessiahAndrw wrote:Perhaps because in certain situations, 0 is a valid pointer, in which case you can define nullptr to something you would know would be invalid.

My point is: the name 'null' already implies "null" not 0 (zero). Calling it nullptr is counter-intuitive.

If I'm writing something in C# or Java and I have a statement like this:
No one would assume that null here is at all related to the number 0 (zero). It's not like having a keyword of "null" will break any C app which uses the macro "NULL".

The fact is, there is lots of code out there which uses null as a variable name, and a tiny amount which uses nullptr as a variable name.

Hmmm...but should a language be modified unnecessarily to allow for illogical use? What exactly would go through a programmer's mind to name a variable 'null', or 'asm' for instance?

gravaera wrote:Hmmm...but should a language be modified unnecessarily to allow for illogical use? What exactly would go through a programmer's mind to name a variable 'null', or 'asm' for instance?

Your point rings true, in a perfect world. This isn't a perfect world, and people do write code which defies logic - according to us, anyway.

Should the language be modified to improve compatibility with existing code, and thus improve the transition experience? Or should it use names such as NULL or null and possibly break lots of existing code?

I don't think you should put backwards compatibility above semantic cleanness. It'd harm the usability of a language to use __null instead of the null as the name of a keyword because someone *might* use the latter in existing code. In this particular case, you'd force people to use more sense in naming which actually is a good idea IMO...

Combuster wrote:I don't think you should put backwards compatibility above semantic cleanness. It'd harm the usability of a language to use __null instead of the null as the name of a keyword because someone *might* use the latter in existing code. In this particular case, you'd force people to use more sense in naming which actually is a good idea IMO...

I agree. Besides, not to insult anyone here, but if you're a programmer who names variables or functions (etc...) something like 'null'... you're just not doing a very good job. I'm sorry. It's true. If you're someone who tries to use null as a variable name, you're probably likely to use other common keywords and won't understand why you get a compiler error when you try to name a variable int, or float.

There are lots of classes which have a logical null (i.e. invalid, or otherwise uninitialized) value. In those cases, I wouldn't be surprised if somewhere a variable called "null" was used to represent this. It perfectly describes the variable - what, would you call it SomeString::nullString, with it's redundancy? I mean, how were programmers supposed to know that they were going to add a null keyword to C++ in the future?

C++ isn't, and has never been a clean language. It's been full of backwards compatibility since it was created, and by all measures, this has been in it's favor. It's another example of purity being sacrificed for utility - the time taken to teach someone the quirks in C++ is less than that which would be taken to teach them both C and some hypothetical C++ with a different syntax, or to rewrite the program in a new language.

It's another example of "worse but compatible" winning (For another, often complained about example, see the 8086 architecture, which is source compatible with all of Intel's proceeding processors, at least through a translator...)

If they redefined the meaning of NULL or null, it'd be chaos.
The issue here is about code like:
Where x(NULL) prints int instead of void*. They needed to keep that behavior, yet it was weird. nullptr was the best solution they could find.
Either way, here's a solution for you.
This should solve all your problems.

@luiscubal: What if some silly standard made NULL a compiler constant?

I never liked most of C++ anyway, and C++0x is just making things worse. nullptr, decltype, constexpr, mixing the language with STL (only a problem in a supposedly systems-programming language), "uniform" initialization (wooooo another way to do things) and alternate declaration syntax (why not tweak scope like they did with for-local declarations?) are all ugly and/or useless.

However, a few things I do like. Lambdas and type inference are excellent. User-defined literals make implementing custom string classes waaaay nicer- no more preprocessor macros or manual constructors for string literals. Variadic templates and arguments are somewhat better than before (although templates... eugh). Enums are also much improved. The range-based for loop is a cool idea, although maybe they should require containers to explicitly implement the begin/end interface (from what wikipedia says it looks like a duck-typing kind of thing, but Iunno).

Even though using null would cause problems, nullptr is still ugly. I think a lot of uses of null are hacks to get exactly what nullptr is. If nullptr were extended to have a type so that classes could have a null constructor to define their own null values, there would be a lot less need for non-keyword null.

Type inference is great. The compiler is smart enough to know what type something should be most of the time (i.e. when you're not defaulting it to 0 or null), without sacrificing readability. In fact, it often increases maintainability (iteration, new Something definitions, etc.). There's usually no reason for the programmer to manually type in that stuff.

Solar wrote:I think it very much improves readability because it gets rid of the goto. A return, even a break, is very well-defined in where it returns / breaks to. A goto doesn't carry that kind of information, you have to search for the target label.

I'd have to disagree. Splitting the code in 100 pieces just as to avoid using the keyword "goto" is nonsense IMHO. It's not the keyword that's the problem, but the bugs that the programmers might write because of it; in this case I think your solution is more susceptible to bugs.

The reason I'm necro'ing this post is that I've been doing a little reading into the Linux kernel code (which I think we can all agree is considered to be high-quality code). It uses goto's. A lot of them even. Say you grab a bunch of locks and then some error comes up. The cleanest solution is to just goto the place where everything is unlocked again.

@Love4Boobies: The code is functional, but I consider it flawed since it is very badly (sparsely) commmented. But the uniformity of the coding style and the general quality of the code is unquestionable.

I'm very surprised that for a large project like the Linux kernel, no-one saw it needful to enforce stricter commenting doctrinology.

--Be well, be healthy, and eat fruit,
gravaera.

But... but... good code doesn't need comments, does it?

(Anyone finding the dripping sarcasm in the comment above may keep it. )

Edit: I just took the time and actually read the Wikipedia article on C++0x. My first impression: Awesome. C++ doesn't get one bit more beautiful with it, but I doubt any other language can touch it for sheer, raw power and versatility.