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

List:       kde-core-devel
Subject:    Re: PATCH: flicker in startup identification
From:       Scott Manson <Maniac () Alltel ! net>
Date:       2001-05-19 0:46:31
[Download RAW message or body]

On Friday 18 May 2001 01:00 pm, Lubos Lunak wrote:
> Dne pá 18. květen 2001 19:43 Dirk Mueller napsal(a):
> > On Fre, 18 Mai 2001, Rik Hemsley wrote:
> > > <even_more_pedantic>
> > > -    if( !startup_widget ) {
> > > +    if (0 == startup_widget) {
> > > </even_more_pedantic>
>
> <insanely pedantic>
> -  if(0 == startup_widget ) {
> + if( static_cast< QWidget* >( 0 ) == startup_widget ) {
> </insanely pedantic>
>
> > > Just kidding, but I don't like to see boolean operators
> > > used to test pointer values. Call me pedantic ;)
> >
> > Discussing this is more of philosophical nature, but IMHO using a boolean
> > operature is just right. you can't assume anything about a pointer value,
> > so I think using a boolean operator in the sense of "is this valid?" is
> > better.
>
>  Integral 0 is always converted to null pointer, regardless of how the null
> pointer is represented. Even if null pointer is actually binary represented
> as integral 0x12348765 , as long as NULL is #define NULL 0 ( or const int
> NULL = 0; ... who cares ), everything is fine.
>  The important thing is that it works, and I think we should continue in
> this discussion only when something really breaks ( and I think I can with
> very good accurancy say the exact date when this will happen : 'never' ).
You stated as long as NULL is ..... who cares. Well YOU do as someone can 
accidently change the definition of NULL but they can't accidently change the 
definition of 0.

This may not seem to be a large problem yet but what would happen if someone 
tried a #define NULL (something that would break) in a header file you are 
now depending on the NULL <==> 0. I don't know if the compiler would flag 
this as an error/warning ; but working on a project as large as KDE and 1 
define statement can/could cause a whole bunch of problems that debugging and 
or tracking down would be more difficult than necessary.
I do understand that this is more of a personal preference whether you test 
against 0 or NULL but IMHO with the size of the codebase and the many 
platforms we are supporting we should come to some sort of consensus on this.

QT has very few checks against NULL with some X11 specific code i.e 
*_x11.{h.cpp} that I suggest that we follow their lead. 


-- 
Maniac@alltel.net 40° 37' 9" N, 96° 57' 24" W  
A single tasking guy in multi tasking world

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