"nullptr" in "default" branch

[YaronCT]

Hi,

Do u have any objection if I use C++11's "nullptr" rather than "0" in the "default" branch? I think it makes the code more readable, and has the advantage that it has its own type (nullptr_t), and thus can't b confused e.g. with int. Therefore, in code like:

Code: Select all

void func(int n);
void func(char *s);
 
func(NULL);


what will b called is "func(int)", which is of course not the intention. However, if it's called with:

Code: Select all

func(nullptr);

then "func(char*)" will b called, as intended.

I suggest to always use "nullptr" in new code in the "default" branch. Now, as for replacing existing null pointers with "nullptr" - this seems like a very difficult task because there's no easy way to distinguish a "0" which is a null pointer from a "0" which is a number (this is one of the reasons I think "nullptr" is better in the first place!) so I suggest leaving them as is.

http://www.cprogramming.com/c++11/c++11 ... class.html

[Kulik]

Agreed. I am pretty sure the CEGUI team already agreed on this but unfortunately the decision was not written down anywhere.

[Ident]

The coding conventions should be edited for this sake. If you make the change, please also add this to the conventions. You can do this in v0-8 by describing that this does not affect v0-8 and v0 but affects anything targeted at default branch or newer branches (1.0 version).

[YaronCT]

Ok, I will. Btw I have a malicious plan on how to automatically change all relevant "0"-s in branch "default" to "nullptr", but I doubt if it's worth the effort.

[Ident]

Regex? In any case your efforts are probably more valuable when focussed on more important changes. nullptr replacement has absolutely no priority right now, as it gives us no direct benefit. Nevertheless, your overal suggestion to use it is good - it should be edited in whenever a line of code containing 0 is edited or if a new line is written. Basically this is what the coding conventions should say as well.

[YaronCT]

No, not a regex. The problem is that "0" may be either a number or a null pointer, and it's not easy to distinguish between them. My idea was, for each occurrence of 0 (as a whole token - that will require some lexical processing), try to change it to "nullptr" and rebuild CEGUI. Now leave the "nullptr" iff the build succeeds. It'll work for 99.9% of the cases, but will fail in places where both a number and a pointer are accepted. To avoid breaking such weird cases, u can improve the algorithm so that if the rebuild with "nullptr" succeeds - go ahead and replace the "nullptr" with "1". Now leave the "nullptr" iff the rebuild with "1" fails (this relies on the fact that e.g. "void* p=1" doesn't compile). So, to sum it up, replace a "0" with "nullptr" iff replacing it with "nullptr" and rebuilding succeeds, whereas replacing it with "1" and rebuilding fails. I doubt if I'm ever that bored that I'll implement it, but it was nice to think of it as an exercise

Well, if we used "NULL" rather than "0" it would all b simpler

[Ident]

Sure NULL would be easier to replace, but whoever the CEGUI team consisted of back then decided not to use NULL, probably mostly because it is a thing from C and this is a C++ library. They didn't plan for nullptr either I guess. But like I said, no big deal. No urge to replace it, just change how we do things in the future and what we allow in default branch.