Scott Meyers wrote:
> I'm told that one of the members of a struct declared in the Microsoft OLE
> headers is called "bool".  This would seem to present a problem for MS,
> because they'll have to change their header file (thus annoying their
> customers) if they want to produce a compiler that supports bool.  Does
> anybody know (1) how the MS representatives on the ANSI/ISO committee let
> this get through, and (2) whether there are any plans to change the keyword
> as a result?

This is flame bait, I assume.  MS may be big, but they don't have
veto power over the ISO.  The X Window System headers commonly (used to)
have a declaration with a variable named "new".  People dealt with it
in their various ways, and lately the header is different.

There are no plans to change the keyword published in any issues list
I have seen.  I would place the odds of a change there between about
zero and epsilon.

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <2p2c51$dgk@agate.berkeley.edu>
           ivin@monoceros.EECS.Berkeley.EDU "Ilya Vinarsky" writes:

>It seems so unnatural that C didn't have it in the first place...
>Why wasn't it introduced into ANSI C along with enumerated types?

Because enums had been in the language for many years, even though not
in K&R Old Testament, and bool had not. Basically, prior art.

The committee invented a few new types which were obviously required and
made the language more complete - eg. signed char, long double. The
real missed opportunity was in not adding long char, resorting to the
wchar_t hack instead. It is obviously a primitive type, having its own
manifest constant form, and should have been a builtin not a typedef.
Instead C++ has had to fix this by adding wchar_t as a builtin,
getting my vote for possibly the worst keyword ever introduced into a
language. The fix is obvious: add long char (no new keywords) and simply
mandate that wchar_t is typedef'd to long char under C++.
--
Kevlin Henney

In article <766836016snz@wslint.demon.co.uk>, <kevlin@wslint.demon.co.uk>
writes:
 had not. Basically, prior art.
>
> The committee invented a few new types which were obviously required and
> made the language more complete - eg. signed char, long double. The
> real missed opportunity was in not adding long char, resorting to the
> wchar_t hack instead. It is obviously a primitive type, having its own
> manifest constant form, and should have been a builtin not a typedef.
> Instead C++ has had to fix this by adding wchar_t as a builtin,
> getting my vote for possibly the worst keyword ever introduced into a
> language. The fix is obvious: add long char (no new keywords) and simply
> mandate that wchar_t is typedef'd to long char under C++.
> --
> Kevlin Henney

Great idea.  Should we inform the Central Committee or have they already
rejected such appeals.

Rodney

In article <766836016snz@wslint.demon.co.uk>, kevlin@wslint.demon.co.uk (Kevlin Henney) writes:
[`wchar_t' should have been `long char']

I agree, but then I also feel the the Algol 68 system was a good idea:
 ... , short short int, short int, int, long int,
 long long int, long long long int, ...
where the number of `short's and `long's that was actually effective
was implementation defined.  Something similar could be done for floats.

Such a system would work fairly graceful on machines where more than 4
integer or more than 3 float sizes would be reasonable.  It would also
reduce the need to use `char' for small integers as opposed to
printable characters.

Also nice (IMHO) would be the ability to use `long' and `short'
qualifiers in typedefs:
 template <class F> class Complex { ... };
 ...
 typedef Complex<float> short complex;
 typedef Complex<double> complex;
 typedef Complex<long double> long complex;
 ...
 long complex z(1.0,1.0);

Would there be any support for a proposal to add any of this?

-- Olaf Weber

In article <1994Apr20.180255.25409@tin.monsanto.com>
           raspar@ccmail.monsanto.com  writes:

>
>In article <766836016snz@wslint.demon.co.uk>, <kevlin@wslint.demon.co.uk>
>writes:
>>
>> The committee invented a few new types which were obviously required and
>> made the language more complete - eg. signed char, long double. The
>> real missed opportunity was in not adding long char, resorting to the
>> wchar_t hack instead. It is obviously a primitive type, having its own
>> manifest constant form, and should have been a builtin not a typedef.
>> Instead C++ has had to fix this by adding wchar_t as a builtin,
>> getting my vote for possibly the worst keyword ever introduced into a
>> language. The fix is obvious: add long char (no new keywords) and simply
>> mandate that wchar_t is typedef'd to long char under C++.
>> --
>> Kevlin Henney
>
>Great idea.  Should we inform the Central Committee or have they already
>rejected such appeals.
>
>Rodney
>

I don't know if anyone has proposed this yet. As I outlined, this
would be more in keeping with the spirit of the language, and the
retrofit is simple. Any takers/proposers?
--
Kevlin Henney

Seems it was raspar@ccmail.monsanto.com who said:
>
>In article <766836016snz@wslint.demon.co.uk>, <kevlin@wslint.demon.co.uk>
>writes:
> had not. Basically, prior art.
>>
>> The fix is obvious: add long char (no new keywords) and simply
>> mandate that wchar_t is typedef'd to long char under C++.
>
>Great idea.  Should we inform the Central Committee or have they already
>rejected such appeals.

This is particularly elegant, since it would restore wchar_t and its
"_t" suffix to typedef status.  It also introduces no new keywords,
and slightly improves the orthogonality of the language.  I suppose that
it just hasn't been suggested yet.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    | (602) 732-2549 (work)  Joseph_Hall-SC052C@email.mot.com

Olaf Weber (olaf@cwi.nl) wrote:
: In article <766836016snz@wslint.demon.co.uk>, kevlin@wslint.demon.co.uk (Kevlin Henney) writes:
: [`wchar_t' should have been `long char']

: I agree, but then I also feel the the Algol 68 system was a good idea:
:  ... , short short int, short int, int, long int,
:  long long int, long long long int, ...
: where the number of `short's and `long's that was actually effective
: was implementation defined.  Something similar could be done for floats.
...

You then need to introduce a new keyword eg  "maxlong" so one can
declare  maxlong int  to get an int of the largest size that you know will
take any representable integer value.
--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semicondutors Ltd
Southampton                                 My views are my own.
United Kingdom

In article <CoLnsp.8Hz@cwi.nl> olaf@cwi.nl "Olaf Weber" writes:

>In article <766836016snz@wslint.demon.co.uk>, kevlin@wslint.demon.co.uk (Kevlin
> Henney) writes:
>[`wchar_t' should have been `long char']
>
>I agree, but then I also feel the the Algol 68 system was a good idea:
>        ... , short short int, short int, int, long int,
>        long long int, long long long int, ...
>where the number of `short's and `long's that was actually effective
>was implementation defined.  Something similar could be done for floats.
>[...]

I'm not so sure. I proposed long char in place of wchar_t in this
thread because it is more in keeping with the spirit and practice of the
language. I think there could be a danger of over generalisation here -
I believe this was one of the problems with Algol-68. The standard library
would get out of hand with overloading for all possibilities (what is a
reasonable upper limit? long long long long?), and the manifest constant
forms would breed like rabbits.

>Also nice (IMHO) would be the ability to use `long' and `short'
>qualifiers in typedefs:
>[...]
>Would there be any support for a proposal to add any of this?
>
>-- Olaf Weber

This was (sort of) possible in pre-ANSI C. It causes more problems
than it solves.
--
Kevlin Henney

 In DOS, I know not why I am so sad,
 It wearies me; you say it wearies you;
 But how I caught it, found it, or came by it,
 I am to learn;

  The Merchant of Venice (I.i)

Kevlin Henney (kevlin@wslint.demon.co.uk) wrote:
> In article <1994Apr20.180255.25409@tin.monsanto.com>
>            raspar@ccmail.monsanto.com  writes:

> >
> >In article <766836016snz@wslint.demon.co.uk>, <kevlin@wslint.demon.co.uk>
> >writes:
> >>
> >> The committee invented a few new types which were obviously required and
> >> made the language more complete - eg. signed char, long double. The
> >> real missed opportunity was in not adding long char, resorting to the
> >> wchar_t hack instead. It is obviously a primitive type, having its own
> >> manifest constant form, and should have been a builtin not a typedef.
> >> Instead C++ has had to fix this by adding wchar_t as a builtin,
> >> getting my vote for possibly the worst keyword ever introduced into a
> >> language. The fix is obvious: add long char (no new keywords) and simply
> >> mandate that wchar_t is typedef'd to long char under C++.
> >> --
> >> Kevlin Henney
> >
> >Great idea.  Should we inform the Central Committee or have they already
> >rejected such appeals.
> >
> >Rodney
> >

> I don't know if anyone has proposed this yet. As I outlined, this
> would be more in keeping with the spirit of the language, and the
> retrofit is simple. Any takers/proposers?
> --
> Kevlin Henney

I totally agree. What do I do? Where do I send tons of e-mail? 8^)

Gonzalo

It seems so unnatural that C didn't have it in the first place...
Why wasn't it introduced into ANSI C along with enumerated types?

--------------------------------------------------------------------------------
Ilya Vinarsky The supreme achievement of neuron megaloplasma!
 The divergent field's curl follows the gradient back, and there,
 inside, transforms the matter of the question into spiritually
 electromagnetic vortexes, and from them there arises the synecdoche
 of answering.