The D Programming Language
in [C++]
|
From: PeteK on 10 Dec 2006 00:45 Francis Glassborow wrote: > > In article <1165518686.608714.296020(a)80g2000cwy.googlegroups.com>, PeteK > > <pete_k_1955(a)yahoo.co.uk> writes >> > >I didn't say it was uninitialised, and even a default initialisation to >> > >NULL might be no help. > > Why do you say that in the context of pointers? Using a compile time > > zero (even wrapped up as a NULL) to assign to or initialise a pointer > > results in an implementation defined value which is often 'address 0' > > but is not required to be. James was asking why I thought that using uninitialised variables was a useful feature of the language. It's not. My point was that the useful feature was the ability to use any value we want in a pointer. This is sometimes necessary in a system-level language. The "default initialisation" bit was saying that just because something is initialised doesn't mean it's useful. Initialising to zero will cause a PE if the pointer is dereferenced on systems where address zero is somehow protected (which is good), but gives you nothing on systems where zero is a valid address. > > > > The real problem is when we actually want to use 'address 0' as might be > > the case in a DOS system. > > Yes, and not just in DOS. I would guess that address zero is a valid address for most (all?) processors and until you've loaded the bit of the system that actually protects address zero accessing it might be perfectly valid. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 10 Dec 2006 18:02 In article <1165692627.577203.236790(a)80g2000cwy.googlegroups.com>, PeteK <pete_k_1955(a)yahoo.co.uk> writes >I'm well aware of this (though I've never actually worked on a system >where the value used wasn't zero). Maybe I should have written it as >"null". One of my pet hates is people writing: > >if ( p ) >rather than >if( p != NULL ) > >with a system-defined vaule they couldn't (portably) do this. But, as >you say, it's just a weird rule anyway. 1) I find no difficulty with the idiom if( p ); but that is because I have become accustomed to it. And I rather dislike if( p != NULL) as that is a negative statement which requires more brain power to process (that, I am told, is a general rule, negative statements are harder for humans to process correctly) 2) I do not see how having a system defined value would change anything (every system defines the literal zero in the context of pointers, we just do not have to know what it is defined to.) -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 10 Dec 2006 20:47 PeteK wrote: > James Kanze wrote: >>> NULL is just a macro. A null pointer does contain a >>> system-defined value. It's not required to be zero, and there >>> have been systems where it wasn't zero. >>> >>> What is required is that an integral constant expression which >>> evaluates to 0 will convert implicitly to whatever the null >>> pointer value is. A rather peculiar rule, to put it mildly, >>> since the rules for converting an int to a pointer depend on >>> whether the int is a constant or not, and if it is a constant, >>> the value of that constant. >>> > > I'm well aware of this (though I've never actually worked on a system > where the value used wasn't zero). Maybe I should have written it as > "null". One of my pet hates is people writing: > > if ( p ) > rather than > if( p != NULL ) > > with a system-defined vaule they couldn't (portably) do this. But, as > you say, it's just a weird rule anyway. They can. Regardless of the actual representation of null pointers on a specific implementation, non-null pointers are considered 'true', and null pointers 'false'. It's a pure stylistic issue, between 'if (p)' and 'if (p != NULL)'. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 11 Dec 2006 08:44 Francis Glassborow wrote: > 1) I find no difficulty with the idiom if( p ); but that is because I > have become accustomed to it. And I rather dislike if( p != NULL) as > that is a negative statement which requires more brain power to process > (that, I am told, is a general rule, negative statements are harder for > humans to process correctly) > So do you write if( p == NULL) instead of if(!p)? If not I don't understand your dislike of using a negative. If so then you have an asymetric (and to my mind this is more confusing) way of testing a pointer. The general test of pointers is: if( p == q ) and if( p != q) so why would you want to write it differently to test against one specific value? One of the reasons I dislike if(p) is that it's so easy for the brain to mis-process it as "if p is NULL" (i.e. positive maps to positive) when quickly scanning code. I recently come across a similar problem with SAP's ABAP language where "if a is init." is easily read as "if a is initialised" when in fact it means the opposite. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 11 Dec 2006 08:55
Seungbeom Kim wrote: > PeteK wrote: > > James Kanze wrote: > >>> NULL is just a macro. A null pointer does contain a > >>> system-defined value. It's not required to be zero, and there > >>> have been systems where it wasn't zero. > >>> > >>> What is required is that an integral constant expression which > >>> evaluates to 0 will convert implicitly to whatever the null > >>> pointer value is. A rather peculiar rule, to put it mildly, > >>> since the rules for converting an int to a pointer depend on > >>> whether the int is a constant or not, and if it is a constant, > >>> the value of that constant. > >>> > > > > I'm well aware of this (though I've never actually worked on a system > > where the value used wasn't zero). Maybe I should have written it as > > "null". One of my pet hates is people writing: > > > > if ( p ) > > rather than > > if( p != NULL ) > > > > with a system-defined vaule they couldn't (portably) do this. But, as > > you say, it's just a weird rule anyway. > > They can. Regardless of the actual representation of null pointers > on a specific implementation, non-null pointers are considered 'true', > and null pointers 'false'. > > It's a pure stylistic issue, between 'if (p)' and 'if (p != NULL)'. > Yes, obviously it's a styalistic issue. And obviously NULL currently decays to false. But that's an artifact of the fact that C had no bools and hence made zero false and non-zero true combined with the fact that NULL is equivalent to zero. Actually I'm surprised that Francis prefers if(p), given that he teaches C/C++. if (p != NULL) is much clearer for a novice (and especially for someone who's used to a non-C-stype language). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |