[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: NULL vs. 0 (was Re: PATCH: flicker in startup identification)
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2001-05-18 13:48:45
[Download RAW message or body]

Dne pá 18. květen 2001 14:59 Guillaume Laurent napsal(a):
> On Friday 18 May 2001 14:44, Lubos Lunak wrote:
> >  Hmm. Such a long patch for a one-line change. Is there any serious
> > reason why you want to replace all the NULL's with 0's ? It's the same.
>
> Not quite, according to Stroustrup use of NULL is discouraged, 0 is
> preferred. I think it's because NULL is typed while '0' is "more flexible"
> or something like that. I don't have my copy of TC++PL 3rd at hand.

 I can't find it in the C++ draft available on www, but IIRC :
- NULL is either 0 or 0L, C++ forbids NULL to be (void*)0
- which means there's no real difference besides NULL being more readable IMHO
- it can cause trouble when overloading on both int and a pointer, but since 
NULL is just 0 it's not really different and everybody writing code depending 
on this is asking for trouble anyway, so that's no argument against NULL
- some buggy platforms use #define NULL (void*)0 , because that's what it 
should be in ANSI C , but there is plenty of NULL's all over KDE sources and 
nobody complained yet AFAIK, so this is no argument either

 In other words, if you're going to convert NULL -> 0 in someone else's code 
just because you think you're doing a good thing, you're just wasting your 
time. And unless it's written somewhere in ISO C++ that NULL is bad bad, 
arguing against using NULL is wasting your time too. I'd feel like a complete 
idiot if I would have problems reading my own code. I can convert it to the 
most often used style in the app sources after it's finished ( which is BTW 
different from the style used in this change ).


 Thank you


 Lubos Lunak
--
 l.lunak@email.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

[prev in list] [next in list] [prev in thread] [next in thread]