[RFC] Using KPassivePopup from KSystrayIcon

[Boyd Stephen Smith Jr.]

On Thursday 05 April 2007, Lubos Lunak <l.lunak at suse.cz> wrote about 'Re: 
[RFC] Using KPassivePopup from KSystrayIcon':
> On čt 5. dubna 2007, Boyd Stephen Smith Jr. wrote:
> > On Wednesday 04 April 2007 08:40:54 Lubos Lunak wrote:
> > > On Wednesday 04 of April 2007, Boyd Stephen Smith Jr. wrote:
> > > > The standard says they are the same (after preprocessing).
> > >  Not true.
> > Hrm, I'll take Stroustrap's word (linked from my mail) instead of
> > yours and assume standard NULL is defined to be 0
>  I wasn't questioning Stroustrup's word, it is "The standard says they
> [NULL and 0] are the same" that isn't true. The standard says something
> like that NULL is an implementation-dependent representation of the null
> pointer or something like that. Neither the standard (AFAIK) nor
> Stroustrup on that page anywhere say NULL is 0.

Wrong.

Here's the relevant Stroustrap quote from that page:
"In C++, the definition of NULL is 0, so there is only an aesthetic 
difference."

I'll agree that Stroustrap may have been sloppy though.  It's *probably* 
only required to be a null pointer constant, so it could be defined as 0, 
0L, g++'s __null, and some other things, but not (void *) 0.

In any case, I agree with you that we should all be using NULL to mean the 
null pointer.  It's been a roughly a decade since C++ was standardized; I 
think that's enough time for compilers to quit defining NULL as (void *) 
0.  In g++ and C++0x, using NULL will have the additional advantage of 
warning or erroring when it's being cast to an integer.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03 at volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070405/46aa1e15/attachment.sig>