In article <KANZE.94Nov14190307@slsvhdt.us-es.sel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@us-es.sel.de> wrote:
[...]
>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.

Didn't someone around here propose something like template variables? Using
something like that, we could come up with
    template<class T>
    const NULL = (T)0;
Would this fix your order of initialization problem? I guess it doesn't
really matter, since template variables aren't part of the language.

--
ed.dy \'ed-e-\ n [ME (Sc dial.) ydy, prob. fr. ON itha; akin to OHG ith-
   again], L et and 1a: a current of water or air running contrary to the main
   current; esp)X : a small whirlpool 1b: a substance moving similarly  2: a
   contrary or circular current  - eddy vb

What is the reason that there is no keyword "nil" in C++ ?
It's quite funny that people try to implement it with templates etc.

In article <3al1hk$3am@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
>What is the reason that there is no keyword "nil" in C++ ?
>It's quite funny that people try to implement it with templates etc.

 James Kanze wrote a proposal.

 The extensions subgroup rejected it.

 There was no "nil" previously, a proposal for it was rejected,
 so there is no "nil" now either.

 Hope that answers your question.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

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

Unread news in comp.std.c++
In article <slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze
US/ESC 60/3/164 #71425) writes:
|> In article <39a79t$87h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi
|> H|yn{l{nmaa) writes:
|>
|> |> James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) wrote:
|> |> : In article <1994Oct25.144408.21066@datascope.com>
sfc@datascope.com
|> |> : (Steve F. Cipolli (P/M)) writes:
|>
|> |> : |> Also, while were on this topic, has anyone continued the
fight to make "nil" a
|> |> : |> legitimate keyword; thus removing ambiguity like this:
|> |> [text deleted]
|>
|> |> : I made a proposal along these lines.  It was not accepted.
|>
|> |> What about
|> |> #define nil ((void*)0)
|>
|> As other posters have pointed out, it doesn't work.
|>
|> 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 >() ;
|>
|> I recently tried to experiment with this.  Although I finally gave
it
|> up because of a compiler bug (my compiler will not instantiate a
class
|> template if its use is as an explicite constructor call), I was able
|> to play around with it long enough to find a major flaw: it is *not*
a
|> constant expression, and so initialization takes place at a later
|> point in time than one would expect.

My compiler complains too, unless I add a definition of
a default constructor:

  Nil() { }

to the template class definition.
Or is this something you try to avoid? (Sorry, your comment is not
clear
to me.)

|> Still, I would have liked to have been able to experiment a little
bit
|> more.
|> --
|> 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
|>
|>


-----------------------------------------------------------------------
Johan Vanslembrouck - SE99            Tel    : +32 3 2407739
Alcatel Bell Telephone                Telex  : 72128 Bella B
Francis Wellesplein  1                Fax    : +32 3 2409932
B-2018 Antwerp                        e-mail : jvsb@sebb.bel.alcatel.be
Belgium
-----------------------------------------------------------------------

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.

Scott

James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) wrote:
: In article <1994Oct25.144408.21066@datascope.com> sfc@datascope.com
: (Steve F. Cipolli (P/M)) writes:

: |> Also, while were on this topic, has anyone continued the fight to make "nil" a
: |> legitimate keyword; thus removing ambiguity like this:
[text deleted]

: I made a proposal along these lines.  It was not accepted.

What about
#define nil ((void*)0)

In article <CypBvL.93H@microsoft.com> jimad@microsoft.com "Jim Adcock" writes:

>In article <38om99$120@hpsystem1.informatik.tu-muenchen.de>
> schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:
>|
>|In article <9430004.4492@mulga.cs.mu.OZ.AU>, fjh@mundil.cs.mu.OZ.AU (Fergus
> Henderson) writes:
>||> >This would certainly produce a more symmetric type system and avoid the
>||> >rather ugly "wchar_t" keyword recently added.
>||>
>||> If you want to avoid ugly keywords, campaign for it to be called "long
> char".
>|
>|How/where can I campaign for "long char" ?
>
>long char implies to me 32-bits, and there are standards describing such

Why? It doesn't imply this to me at all, otherwise I would also expect
long double to be 32 bits. On some machines long int is 64 bits, on others
a long can be 36 bits, etc.

Besides, nobofy said that wchar_t was 16 or 32 bits, just that it was
implementated of one of the existing integral types. Just as long int
doesn't imply a 32 bit version of an int - it only implies that it is at least
32 bits and may be larger than an int - long char would be at least the
size a char and probably larger (16 or 32, typically).

>a beast too, so we should leave our options over there.  How about if
>we more accurately name the 16-bit character flavor:
>
>        "double char"
>
>;-)

Why is this more 'accurate'? double char implies a floating point type
to me ;-)

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

In article <39a79t$87h@tethys.otol.fi>
           tohoyn@janus.otol.fi "Tommi H|yn{l{nmaa" writes:

>James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) wrote:
>: In article <1994Oct25.144408.21066@datascope.com> sfc@datascope.com
>: (Steve F. Cipolli (P/M)) writes:
>
>: |> Also, while were on this topic, has anyone continued the fight to make
> "nil" a
>: |> legitimate keyword; thus removing ambiguity like this:
>[text deleted]
>
>: I made a proposal along these lines.  It was not accepted.
>
>What about
>#define nil ((void*)0)

Because

 char *ptr = nil;

won't work. Nuff said.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

In article <39a79t$87h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi
H|yn{l{nmaa) writes:

|> James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) wrote:
|> : In article <1994Oct25.144408.21066@datascope.com> sfc@datascope.com
|> : (Steve F. Cipolli (P/M)) writes:

|> : |> Also, while were on this topic, has anyone continued the fight to make "nil" a
|> : |> legitimate keyword; thus removing ambiguity like this:
|> [text deleted]

|> : I made a proposal along these lines.  It was not accepted.

|> What about
|> #define nil ((void*)0)

As other posters have pointed out, it doesn't work.

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 >() ;

I recently tried to experiment with this.  Although I finally gave it
up because of a compiler bug (my compiler will not instantiate a class
template if its use is as an explicite constructor call), I was able
to play around with it long enough to find a major flaw: it is *not* a
constant expression, and so initialization takes place at a later
point in time than one would expect.

Still, I would have liked to have been able to experiment a little bit
more.
--
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

In article <38om99$120@hpsystem1.informatik.tu-muenchen.de>
           schuenem@Informatik.TU-Muenchen.DE "Ulf Schuenemann" writes:

>
>In article <9430004.4492@mulga.cs.mu.OZ.AU>, fjh@mundil.cs.mu.OZ.AU (Fergus
> Henderson) writes:
>|> >This would certainly produce a more symmetric type system and avoid the
>|> >rather ugly "wchar_t" keyword recently added.
>|>
>|> If you want to avoid ugly keywords, campaign for it to be called "long
> char".
>
>How/where can I campaign for "long char" ?

I have already written a proposal for this:

 "An alternative wide character type"
 X3J16/94-0120
 WG21/N0507

Lean on one of your national standards committee reps; I have - w/ any luck
he's proposing it :-)

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

In article <38om99$120@hpsystem1.informatik.tu-muenchen.de> schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:
|
|In article <9430004.4492@mulga.cs.mu.OZ.AU>, fjh@mundil.cs.mu.OZ.AU (Fergus Henderson) writes:
||> >This would certainly produce a more symmetric type system and avoid the
||> >rather ugly "wchar_t" keyword recently added.
||>
||> If you want to avoid ugly keywords, campaign for it to be called "long char".
|
|How/where can I campaign for "long char" ?

long char implies to me 32-bits, and there are standards describing such
a beast too, so we should leave our options over there.  How about if
we more accurately name the 16-bit character flavor:

 "double char"

;-)

>>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

> What about
> #define nil ((void*)0)

There is no standard conversion from (void*)0 to any other pointer type
unless you are using GNU C++.

Jason

In article 21066@datascope.com, sfc@datascope.com (Steve F. Cipolli (P/M)) writes:
>
>Why then does "short" not provide a similar capability for wide characters?
>This would certainly produce a more symmetric type system and avoid the
>rather ugly "wchar_t" keyword recently added.

There is no requirement that wide chars are the same size as short.
On many systems they are 32 bits. On some systems they are signed,
on others they are unsigned, whatever their size.

In C, wchar_t is a typedef. In C++, a typedef prevents writing a portable
program that overloads on wide characters. Example:

 void write(int i) // convert to text representation of value
 { ... }
 void write(wchar_t c) // write the character
 { ... }

This code works on systems where wchar_t is not an int. It won't compile
and provides no way to differentiate ints from wchar_t's on those systems
where wchar_t is typedef'd to int. Now consider input, where you need
to overload on each integral type plus wchar_t.

That is the reason for making wchar_t a type. It will have the same
representation as some integer type, but is still a distinct type,
permitting overloading. (Compare: On most systems, int has the same
representation as either short or long, but the three types are always
distinct no matter what the representation.)

BTW, why is wchar_t more ugly when it is a keyword than when it is a
typedef in a header? I agree that the spelling is ugly, but the spelling
is a given.

---
Steve Clamage, stephen.clamage@eng.sun.com

sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

>Jason Merrill (jason@cygnus.com) wrote:
>: >> There is.  'char' is used for character values, 'unsigned char' and
>: >> 'signed char' are used for bytes.  'char' is not the same type as either
>: >> of the other two.
[...]
>Why then does "short" not provide a similar capability for wide characters?

Because "short" is already defined to be the same as "signed short".

>This would certainly produce a more symmetric type system and avoid the
>rather ugly "wchar_t" keyword recently added.

If you want to avoid ugly keywords, campaign for it to be called "long char".

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <1994Oct25.144408.21066@datascope.com> sfc@datascope.com
(Steve F. Cipolli (P/M)) writes:

|> Also, while were on this topic, has anyone continued the fight to make "nil" a
|> legitimate keyword; thus removing ambiguity like this:

|> class X {
|> public:
|>  X(int i);
|>  X(void *p);
|> };

|> void F() {
|>  X x(0);  // Ambiguous: Is it nil or zero?
|> }

I made a proposal along these lines.  It was not accepted.
--
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

In article <9430004.4492@mulga.cs.mu.OZ.AU>, fjh@mundil.cs.mu.OZ.AU (Fergus Henderson) writes:
|> >This would certainly produce a more symmetric type system and avoid the
|> >rather ugly "wchar_t" keyword recently added.
|>
|> If you want to avoid ugly keywords, campaign for it to be called "long char".
|>
|> --
|> Fergus Henderson - fjh@munta.cs.mu.oz.au

How/where can I campaign for "long char" ?


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de
WWW:   http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle9/~schuenem/index.html

Jason Merrill (jason@cygnus.com) wrote:
: >>>>> Douglas Alan <nessus@mit.edu> writes:

: > In article <JASON.94Oct14170259@phydeaux.cygnus.com> jason@cygnus.com
: > (Jason Merrill) writes:

: >>>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

: >> Currently, the type 'char' is used for bytes in C++.
: >> I think that there should be a separate type for characters and
: >> bytes (numerical values).

: >> There is.  'char' is used for character values, 'unsigned char' and
: >> 'signed char' are used for bytes.  'char' is not the same type as either of
: >> the other two.

: > Yes, but if you do 'cout << x;' where 'x' is an 'unsigned char', do
: > you get a character or a number written to 'cout'?  It would be nice
: > to have such a type where you don't have to cast 'x' before writing it
: > to an ostream.

: This is a problem with the specification of iostreams, not the type system.
: If the operators

:       ostream_type& operator<<(unsigned char_type c)

: 7 Returns operator<<((char_type)c).
:       ostream_type& operator<<(signed char_type c)

: 8 Returns operator<<((char_type)c).

: were left out, signed char and unsigned char would promote to int, and all
: would be well.  Their status is currently uncertain; this seems like a good
: reason to remove them.

Why then does "short" not provide a similar capability for wide characters?
This would certainly produce a more symmetric type system and avoid the
rather ugly "wchar_t" keyword recently added.

Also, while were on this topic, has anyone continued the fight to make "nil" a
legitimate keyword; thus removing ambiguity like this:

class X {
public:
 X(int i);
 X(void *p);
};

void F() {
 X x(0);  // Ambiguous: Is it nil or zero?
}

In article <JASON.94Oct14170259@phydeaux.cygnus.com> jason@cygnus.com
(Jason Merrill) writes:

   >>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

   > Currently, the type 'char' is used for bytes in C++.
   > I think that there should be a separate type for characters and
   > bytes (numerical values).

>   There is.  'char' is used for character values, 'unsigned char' and
>   'signed char' are used for bytes.  'char' is not the same type as either of
>   the other two.

Yes, but if you do 'cout << x;' where 'x' is an 'unsigned char', do
you get a character or a number written to 'cout'?  It would be nice
to have such a type where you don't have to cast 'x' before writing it
to an ostream.

|>oug /\lan
   <nessus@mit.edu>

>>>>> Douglas Alan <nessus@mit.edu> writes:

> In article <JASON.94Oct14170259@phydeaux.cygnus.com> jason@cygnus.com
> (Jason Merrill) writes:

>>>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

>> Currently, the type 'char' is used for bytes in C++.
>> I think that there should be a separate type for characters and
>> bytes (numerical values).

>> There is.  'char' is used for character values, 'unsigned char' and
>> 'signed char' are used for bytes.  'char' is not the same type as either of
>> the other two.

> Yes, but if you do 'cout << x;' where 'x' is an 'unsigned char', do
> you get a character or a number written to 'cout'?  It would be nice
> to have such a type where you don't have to cast 'x' before writing it
> to an ostream.

This is a problem with the specification of iostreams, not the type system.
If the operators

      ostream_type& operator<<(unsigned char_type c)

7 Returns operator<<((char_type)c).
      ostream_type& operator<<(signed char_type c)

8 Returns operator<<((char_type)c).

were left out, signed char and unsigned char would promote to int, and all
would be well.  Their status is currently uncertain; this seems like a good
reason to remove them.

Jason

Currently, the type 'char' is used for bytes in C++.
I think that there should be a separate type for characters and
bytes (numerical values).

>>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

> Currently, the type 'char' is used for bytes in C++.
> I think that there should be a separate type for characters and
> bytes (numerical values).

There is.  'char' is used for character values, 'unsigned char' and
'signed char' are used for bytes.  'char' is not the same type as either of
the other two.

Jason