On Fr, 2011-06-24 at 12:24 +0200, Murray Cumming wrote: > On Fri, 2011-06-24 at 11:41 +0200, Patrick Ohly wrote: > > commit 581339e3b2c0a4492a4c92d765af12a9158d85f6 > > Author: Murray Cumming <[email protected]> > > Date: Wed Jun 15 11:08:43 2011 +0200 > > > > dbus-server: Do not use NULL in C++ code. > > > > NULL does not meant the same thing in C as in C++. It can lead to > > hard-to-debug problems. > > > > Why should NULL not be used? It can't be the (void *)0 definition as > > in > > C, but both 0 (the generic C++ null pointer) or g++'s __null [1] > > should > > be fine. > > Firstly, this is my commit, not Chris's. It's a pet thing of mine.
I know. I didn't mention it explicitly because of Author: field. > > I personally like to use NULL because it makes C and C++ code more > > consistent and as additional indicator that a type is a pointer. > > But NULL is not a pointer in C++. It is in C. > > > [1] http://gcc.gnu.org/onlinedocs/libstdc > > ++/manual/bk01pt02ch04s03.html > > NULL is a particular problem when calling varargs functions, passing > NULL as a sentinel, and then it's a hard one to debug. I personally > prefer to clean all NULLs out of code to make it impossible for that to > ever happen. In other words, NULL works as long as it is defined to __null but fails in this case on 32 bit systems when it is 0? And you prefer to write (void *)0 (when needed) or just 0 (when not)? Okay, I see how that can be tricky because using NULL is a portability problem: works on our test platform, may fail elsewhere. > I believe this is why C++0x has nullptr: > http://en.wikipedia.org/wiki/C%2B%2B0x#Null_pointer_constant > > If you don't like the change, we don't have to have it. It's a very > minor thing. I'm undecided ;-) If we ban NULL, we would have to do it consistently. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
