From 6239473697377747175
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,f86cdbd4280bf4a1
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1994-11-14 10:09:24 PST
Newsgroups: comp.std.c++
Path: nntp.gmd.de!xlink.net!slsv6bt!slsv6bt!kanze
From: kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: Bytes and Characters
In-Reply-To: smeyers@netcom.com's message of Thu, 10 Nov 1994 20:20:09 GMT
Message-ID: <KANZE.94Nov14190307@slsvhdt.us-es.sel.de>
Sender: news@lts.sel.alcatel.de
Organization: SEL
References: <KANZE.94Oct26220005@slsvhdt.us-es.sel.de> <39a79t$87h@tethys.otol.fi>
	<KANZE.94Nov8192744@slsvhdt.us-es.sel.de>
	<smeyersCz2J5M.8yt@netcom.com>
Date: 14 Nov 1994 18:03:07 GMT
Lines: 74

In article <smeyersCz2J5M.8yt@netcom.com> smeyers@netcom.com (Scott
Meyers) writes:

|> In article <KANZE.94Nov8192744@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
|> | One of the reasons given for not accepting the proposal was that it
|> | could be simulated by a template class, something along the lines of:

|> | 	template< class T >
|> | 	class Nil
|> | 	{
|> | 	public :
|> | 	    operator T*() { return 0 ; }
|> | 	} ;

|> | and then writing things like:

|> | 	char* p = Nil< char >() ;

|> In Effective C++, I considered this possibility:

|>   class Null {
|>   public:
|>     template<class T>
|>     operator T*() const { return 0; }
|>   };

|>   const Null NULL;

|> Then you should be able to do:

|>   char *p = NULL;

|> At the time, templates were only allowed at global scope.  Now that member
|> function templates are allowed, perhaps it's worth revisiting this idea.
|> It seems as valid as the smart-pointer conversion trick that Bjarne
|> describes in section 15.9.1 of his DEC++ book.

I've been playing around with this idea a little.  The main drawback
of this, and of all of the other variants I've seen, is the order of
initialization problem.  There is a lot of code (at least, I have a
lot of code) which counts on the fact that pointers that the
initialization of a static pointer to NULL occurs before any dynamic
initialization takes place.  The above, however, *is* a dynamic
initialization, and it will take place at an unspecified time during
the dynamic initialization.

The pointer will be initialized (by default) to NULL during the static
initialization anyway, and be reinitialized to NULL during the
dynamic.  Consider what will happen with the omnipresent:

	if ( p == NULL )
	    p = new XXX ;

if this expression is executed during the dynamic initialization
*before* the dynamic initialization of p.

For the moment, I'm using:

#define	GB_NIL( T )		((T)0)

This seems to work fairly well, and I will probably continue using it
irrespective of what the standard finally says.

If the use of a macro is to be considered a flaw in the language
design (I believe that is what Bjarne once said), then so be it.  (On
the other hand, the above macro works so well, why bother.  Just get
rid of the *implicit* conversion of 0 to a pointer, and let it stay.)
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung