In <DJAJ44.J5w@research.att.com>, ark@research.att.com (Andrew Koenig) writes:

>How would you arrange for the expression 3<4 to yield the right type?

   type unsigned char bool;

   inline bool operator<(int x, int y) {
      return bool(x < y); }

would probably do the trick.  Just because the definition of bool
is opaque for the purposes of typing, there shouldn't be any
problem casting a value to an opaque type because the compiler
could cast to the underlying type.  The only difference I see in
an opaque "type" vs transparent "typedef" is when matching
types.

Since I can overload on bool as defined above, I can define a
global operator (when necessary) to solve problems like this.
It should also be possible to solve the problem by...

   inline operator bool(int x) {return (bool)(unsigned char)x;}

Although this approach might be enhanced by something more
like...

   inline implicit operator bool(int x) {return (bool)(unsigned char)x;}

where the "implicit" keyword would put a user-defined type
conversion at the same level as that of the built-in type conversions.
Right now, when the user defines a type conversion it is really
a second class citizen compared to the "trivial" conversions and
the built-in conversions because of the rule that says only one
conversion can be applied.

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com writes:


>In <DJAJ44.J5w@research.att.com>, ark@research.att.com (Andrew Koenig) writes:

>>How would you arrange for the expression 3<4 to yield the right type?

>   type unsigned char bool;

>   inline bool operator<(int x, int y) {
>      return bool(x < y); }

>would probably do the trick.

Except for two things:

1. That functions suffers infinite recursion.

2. You can't create such a function in the first place. An
overloaded operator must have at least one argument of class type.
The reason for the rule is to prevent writing functions that change
the established meaning of operators.

If you change the language to allow you write a function like the
above, you would also allow
 bool operator<(int x, int y) { return bool(rand()); }
which seems like a much worse state of affairs than having a
built-in boolean type.
--
Steve Clamage, stephen.clamage@eng.sun.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

clamage@Eng.sun.com (Steve Clamage) wrote:
>vandevod@cs.rpi.edu (David Vandevoorde) writes:
>
>Stroustrup is a member of the ANSI X3J16 committee.

  Allow me to point out that he is _also_ an member (by courtesy)
of WG21 -- and that he has NO vote on either committee.

  He has, however, remained the primary guiding force in the
continued development of the language, especially templates,
exceptions, (both "experimental" in the ARM), and the introduction
of STL.





---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mzhou01 <mzhou01@barney.poly.edu> wrote:
>C++ standardization people,
>
>With all respect. I am not happy with the way the committe is
>modifying the C++ language. I think you people are enlarging the language
>by adding un-necessary keywords to it.

  Why is this a problem?

>For example the boolean type, true, false keywords.
>I spoke to my university friends about this addendum and they feel the
>say way as I do. Why do we need in boolean type?

  To standardise existing practice, which regularly causes
major portability problems in the interoperability of
separately developed components EACH using their own
version of bool.

  This is not important for a 10 line program. It is for
systems comprising 10+ million lines, and using libraries
from multiple vendors, and which has to run on multiple
platforms.

>If it was really
>necessary Dennis Ritchie would have put it in C in the place.

  Thats not an argument: C does not have function overloading.
That turns out to be a crucial factor in not only making
bool a discrete type, but also making each enumeration type
a discrete type (which is not the case in C either).

>He didn't
>put it in because boolean can be easily create using the language itself,
>ie: the #define or emum, and Stroustrup didn't added in his second editon.

  We didn't add a WHOLE LOT of things to C++ for the same reason:
it can be done with, for example, templates.

>I think your guys are forgetting what made the C language so popular. It
>is it's compactness, elegance and flexibility.

  Compactness I agree with. Elegance -- you've just got
to be kidding. Flexibility is partly true, however, C has some
very nasty deficiencies.

  What makes C popular today is primarily availability, efficiency,
and history coupled with reasonable functional power suited to
low level systems development -- which makes it possible,
if rather diffiult, to develop higher level systems too,
without too many constraints _imposed_ by the language.

  C++ carefully remains largely compatible with C.

>Let C inspire C++.

      But it did!

>P.S. Is Stroustrup on the stardardization team?

      Yes.

>Does he get the final say since it is his language?

      No. YOU do. You don't have to use it.


--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com writes:
 ...
>>How would you arrange for the expression 3<4 to yield the right type?

>   type unsigned char bool;

>   inline bool operator<(int x, int y) {
>      return bool(x < y); }

>would probably do the trick.  Just because the definition of bool

You cannot redefine an operator between builtin types -- at least
one arg has to be a user-defined type.  AND you cannot overload
a function based solely on its return type, i.e. have two operator<()
taking two int args, distinguished by one returning an int and one
returning a bool, as you seem to be trying to do here.

It might be a good idea to learn the basics of the C++ language
before expressing criticisms of the standard committee's choices.


Alex
--
DISCLAIMER: these are MY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it -- Phone: +39 (51) 597 313  [Fax: 597 120]
Cad.Lab S.p.A., v. Ronzani 7/29, 40033 Casalecchio (BO), Italia

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com writes:

>In <4acljf$ao1@engnews1.eng.sun.com:, clamage@Eng.Sun.COM (Steve Clamage) writes:
>:
>:mfinney@inmind.com writes:
>:
>::In <DJAJ44.J5w@research.att.com:, ark@research.att.com (Andrew Koenig) writes:
>:
>:::How would you arrange for the expression 3<4 to yield the right type?
>:
>::   type unsigned char bool;
>:
>::   inline bool operator<(int x, int y) {
>::      return bool(x < y); }
>:
>::would probably do the trick.
>:
>:Except for two things:
>:
>:1. That functions suffers infinite recursion.

>Correct.  I thought that I fixed that.  Replace the return
>statement with...

>   return (bool)(unsigned char)(x < y);

No, that doesn't fix anything. The expression (x<y) compares two
ints. This is the function that evaluates that expression,
so it calls itself. To avoid recursion, you must cast x and y to
some other type first, or evaluate the comparison some other way.

But who knows what other overloads might be present? Any rewrite
of the expression (x<y) is likely to wind up calling some other
overloaded function, and you might still get infinite recursion.
For example:
 return ! x >= y;
If someone has added a function
 bool operator>=(int a, int b) { return ! a < b; }
you get infinite mutual recursion. Any expression you write
for the body of operator< might get into recursion if unrestricted
operator overloading is allowed.


>:2. You can't create such a function in the first place. An
>:overloaded operator must have at least one argument of class type.
>:The reason for the rule is to prevent writing functions that change
>:the established meaning of operators.
>:
>:If you change the language to allow you write a function like the
>:above, you would also allow
>: bool operator<(int x, int y) { return bool(rand()); }
>:which seems like a much worse state of affairs than having a
>:built-in boolean type.

>True as things stand.  But the rule CAN be relaxed relative
>to opaque types without changing anything relative to
>transparent types.

I don't understand what you are trying to say. You can already
define overloaded operators for user-defined types, opaque or
not. You cannot define overloaded operators for just built-in
types for the reasons I gave.

If you were originally saying that the boolean type has some
problems, I agree. My contention is that either omitting the
boolean type entirely (status quo ante) or allowing overloading
of operators such as your example would be much worse than
the present definition of the boolean type.

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


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com wrote:

: In <49vplf$mvs@engnews2.Eng.Sun.COM>, clamage@Eng.sun.com (Steve Clamage) writes:

: >The other reason is that no user definition of a boolean type can
: >type. For example:

: This is one of the biggest problems with C/C++.  Since typedef is
: "transparent" you can't overload on it.  If C/C++ had a "type" which
: is identical to "typedef" except that the type defined is opaque so
: that overloading is possible then programming could be simplified in
: many cases.  And would have made the bool type unnecessary because
: it COULD have been defined in the language with that extension.

: Michael Lee Finney

I have not objection to boolean type.  But those added key words like
and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which
has far too many key wods.  I agree that people using C/C++ aren't fools
and they don't need those added key words.

-- joe
--------------------------------------------------------------------------
Joseph Y Chen, Grad Student             Civil Engineering, Uni. of Arizona
jychen@U.Arizona.EDU                    http://CElab3.CE.Arizona.EDU
(+1) (602) 622-6981 (home)              (+1) (602) 621-5719 (work)
1201 E Drachman, #128/Tucson, AZ 85719/USA


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Tim Hollebeek (tim@franck.Princeton.EDU) wrote:
> Matt Austern <matt@physics.berkeley.edu> wrote:
> >
> >Alternative tokens, in other words, solve the same problem that
> >trigraphs do.  Personally, though, I think that alternative
> >tokens are a much nicer solution.  I'd much rather read an
> >expression like "i < 0 or i >= n" than one like "i < 0 ??!??! i >= n".
>
> Now back to the issue at hand.  Having lots of keywords makes this
> problem even worse, unless you have an editor that can highlight them
> automatically for you.  The are simply too hard to pick out by eye.
> && is much easier to see and recognize than 'and' is.

I think you misssed Matt's point. He was not saying that 'or' was better
than '||'. We was saying that if you have a character set with no |
character, then 'or' is a far better alternative than the trigraphs ??!??!
If you've never seen trigraphs before, look them up. I think the ARM has a
list. They are truly ugly things.

--
[=======================================================================]
[ Kevin Lentin                   |      The Mighty Carlton Blues      | ]
[ K.Lentin@cs.monash.edu.au      |          1995 AFL Premiers         | ]
[ Macintrash: 'Just say NO!'     |CARLTON 21-15-141 d geelong 11-14-80| ]
[=======================================================================]


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4alt1o$13a2@news.ccit.arizona.edu> jychen@aruba.ccit.arizona.edu (Joseph Y Chen) writes:

> I have not objection to boolean type.  But those added key words like
> and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which
> has far too many key wods.  I agree that people using C/C++ aren't fools
> and they don't need those added key words.

They do if their display devices don't have the usual symbols for &,
|, ^, etc.  Those symbols are `national characters' and are permitted
to display differently in different countries.

--
    --Andrew Koenig
      ark@research.att.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <...>, tim@franck.Princeton.EDU (Tim Hollebeek) wrote:

> In article <...>, Matt Austern <matt@physics.berkeley.edu> wrote:
...
> >Alternative tokens, in other words, solve the same problem that
> >trigraphs do.  Personally, though, I think that alternative
> >tokens are a much nicer solution.  I'd much rather read an
> >expression like "i < 0 or i >= n" than one like "i < 0 ??!??! i >= n".
>
...
> Now back to the issue at hand.  Having lots of keywords makes this
> problem even worse, unless you have an editor that can highlight them
> automatically for you.  The are simply too hard to pick out by eye.
> && is much easier to see and recognize than 'and' is.

That's not the point. '&&' may be easier to pick out than 'and', and
'||' may easier to pick out than 'or' (although on a system with syntax
coloring, I would disagree with this), but if I am programming on a system
in which I _cannot_ _have_ '||', I would absolutely prefer 'or' over
'??!??!'. Trigraphs are simply abominable to read, IMHO.

Besides, having these keywords available to you does not force you
to use them. There's nothing wrong with establishing coding standards
which use an appropriate subset of the language. It's only when that
subset is chosen through fear and ignorance that you run into problems.

--
Scott Howlett, howlett@netcom.com
"Probably the earliest fly swatters were nothing more than some sort of
striking surface attached to the end of a long stick."


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

jychen@aruba.ccit.arizona.edu (Joseph Y Chen) wrote:

[ ... ]
>I have not objection to boolean type.  But those added key words like
>and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which
>has far too many key wods.  I agree that people using C/C++ aren't fools
>and they don't need those added key words.

Rather than "fools", the keywords were added to help people whose
keyboards don't include all the punctuation to which those using English
are generally accustomed.  The previous attempt along this line was
trigraphs.  The real question is not whether:
 if (( x or y ) xor z)
is better than:
 if ( (x || y) ^ z )
but whether it's better than:
 if (( x ??!??! y ) ??' z )
which is how it comes out using trigraphs.

I don't mean to insult anybody, but it's my opinion that anybody who
finds the trigraph version preferrable has serious mental problems.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "MA" == Matt Austern <matt@Austern.berkeley.edu> writes:

MA> People using C++ aren't necessarily fools; also, though, they aren't
MA> necessarily Americans.  The alternative tokens (which aren't quite the
MA> same as keywords) were added to C++ because some C++ operators use
MA> characters that exist in ASCII but not in other national character
MA> sets.

When the issue was raised in this forum two years ago, none of the
European contributers could think of any current software development
being done using the old national 7 bit character sets.

Everybody who needed national character support were using 8-bit
character sets (or better).  Has this changed meanwhile?


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Andrew Koenig (ark@research.att.com) wrote:

|> In article <4alt1o$13a2@news.ccit.arizona.edu> jychen@aruba.ccit.arizona.edu (Joseph Y Chen) writes:

|> > I have not objection to boolean type.  But those added key words like
|> > and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which
|> > has far too many key wods.  I agree that people using C/C++ aren't fools
|> > and they don't need those added key words.

|> They do if their display devices don't have the usual symbols for &,
|> |, ^, etc.  Those symbols are `national characters' and are permitted
|> to display differently in different countries.

Andy is, of course, talking about the ISO 546 code.  Most modern
machines will use ISO 8859-1, which doesn't have this problem (but has a
number of codes with the 8th bit set, which introduces a set of problems
of its own).

Independantly of the display: using ISO 8859-1 doesn't increase the
number of keys on the keyboard.  It is often difficult, if not
impossible (X-Window doesn't understand the compose key), to enter the
characters in question with a local keyboard.  So even when the codes
exist...
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
              -- A la recherche d'une activit    dans une region francophone


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
>When the issue was raised in this forum two years ago, none of the
>European contributers could think of any current software development
>being done using the old national 7 bit character sets.
>
>Everybody who needed national character support were using 8-bit
>character sets (or better).  Has this changed meanwhile?

My greatest problem is not to display the characters -- it's to type
them.  I have a so called national keyboard with funny extra
characters that are used in C and C++.  For example, | requires me to
press three keys simultaneously: Alt + Shift + <.  Some keys have 6
different symbols.

By the way, here is a quick test of character code compatibility.  If
the line below shows 4+4 letters, then 8-bit code works as advertised.

 edv| EDV\

The letters should be circle-a, umlaut-a, umlaut-o and umlaut-u; four
lower-case and four upper-case.

And if it doesn't work....

 The difference between theory and practice is greater
 in practice than in theory.

Dag Bruck
--
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden                                URL:    http://www.dynasim.se



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>    [Considering the new tokens "or", et al...]
>|> Now back to the issue at hand.  Having lots of keywords makes this
>|> problem even worse, unless you have an editor that can highlight them
>|> automatically for you.  The are simply too hard to pick out by eye.
>|> && is much easier to see and recognize than 'and' is.

>But is ??!??! really more readable that or?

No, definitly not. One disadvantage with C that C++ has inherited is
that it is so many strange symbols you have to learn. These new
keywords is a good way to make C++ easier. Trigraphs are really ugly.

Since many editors supports syntax hilighting, many keywords shouldn't
be a problem.

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "m" == mzhou01  <mzhou01@barney.poly.edu> writes:
m> C++ standardization people,
m> With all respect. I am not happy with the way the committe is
m> modifying the C++ language. I think you people are enlarging the language
m> by adding un-
m> necessary keywords to it. For example the boolean type, true, false keywords.
m> I spoke to my university friends about this addendum and they feel the
m> say way as I do. Why do we need in boolean type? If it was really

Some of my university friends don't :-P

m> necessary Dennis Ritchie would have put it in C in the place. He didn't
m> put it in because boolean can be easily create using the language itself,
m> ie: the #define or emum, and Stroustrup didn't added in his second editon.

You cannot expect Bjarne Stroustrup's book about the C++ language to
contain information about what was not yet part of the language when
he wrote the book. Read ``The Design and Evolution of C++'' for more
up-to-date information (and the whys of certain extensions); same
author.

m> I think your guys are forgetting what made the C language so popular. It
m> is it's compactness, elegance and flexibility. I agree #define and emum
m> are not type safe, but they again C/C++ aren't intended to be used by
m> fools. Stop trying to add stuff to C++ to make it idiot-proof.

Note that C++ is not C. Also, number of keywords is not nearly a measure
of compactness, elegance or flexibility.

I've also heard many C programmers say that the one thing they like most
in C++ is type-safety. However, perhaps the two most compelling reasons
for built-in boolean types are:
 . it's standard: hopefully libraries needing some boolean type
                  will easily be mixable in the future,
 . it's overloadable (so would a user-defined bool class or
                      enum type, but that leads to strange
                      contortions with built-in operators).

m> Basically I browsed the 57 C++ keywords web page and was disappointed.
m> Well for those of you who has authority in setting the standard, keep in
m> mind that C's success is due to its flexibility, compactness, and elegance.
m> Let C inspire C++. Don't turn C++ back to Pascal or PL/I.

I don't have that authority, but the number of keywords has never
been a problem to me.

m> Mike

m> P.S. Is Stroustrup on the stardardization team? Does he get the final
m>      say since it is his language?

Yes (team = ANSI X3J16 and ISO WG21). I don't think he gets the
`final say', but I'm quite sure his words are not taken lightly.

 Daveed



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

|> Solution 1 was status quo, and was judged by a great many people to be
|> inadequate. Hence we adoped solution 2. (For most practical purposes,
|> putting a boolean type in the standard library instead would be equivalent.
|> It doesn't have any advantages over using keywords that I can see.)

Having worked in situations where there were conflicting typedefs in different
third party libraries I can sympathise with the original poster (Mike). I have
come to realize, however, that adding a boolean type to C++ will help since in
the case of conflict one vendor's headers will cease to compile under the new
C++.  As a customer I may then press a vendor to rectify the situation.  As
things are now I have absolutely no recourse in the above-described situation
(other than code hackery).

--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <49vplf$mvs@engnews2.Eng.Sun.COM>, clamage@Eng.sun.com (Steve Clamage) writes:

>The other reason is that no user definition of a boolean type can
>type. For example:

This is one of the biggest problems with C/C++.  Since typedef is
"transparent" you can't overload on it.  If C/C++ had a "type" which
is identical to "typedef" except that the type defined is opaque so
that overloading is possible then programming could be simplified in
many cases.  And would have made the bool type unnecessary because
it COULD have been defined in the language with that extension.

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <Pine.SOL.3.91.951203010216.13007A-100000@barney> mzhou01 <mzhou01@barney.poly.edu> writes:

> With all respect. I am not happy with the way the committe is
> modifying the C++ language. I think you people are enlarging the language
> by adding un-
> necessary keywords to it. For example the boolean type, true, false keywords.
> I spoke to my university friends about this addendum and they feel the
> say way as I do. Why do we need in boolean type? If it was really
> necessary Dennis Ritchie would have put it in C in the place. He didn't
> put it in because boolean can be easily create using the language itself,
> ie: the #define or emum, and Stroustrup didn't added in his second editon.

You are quite right: C does not need a built-in Boolean type.

But C++ does, mostly because of function overloading.  Function overloading
makes the types of expressions much more visible, because an expression with
an inappropriate type can cause the wrong function to be called.

So, in particular, if boolean were a library-defined class type, we might
be able to write

 void foo(int);
 void foo(bool);

but there would be no way to make foo(3<4) call foo(bool) instead of foo(int).

> P.S. Is Stroustrup on the stardardization team? Does he get the final
>      say since it is his language?

Stroustrup is on the committee.  He does not get final say,
nor does any other single individual.  People do listen to him, though.
--
    --Andrew Koenig
      ark@research.att.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4a12d7$vps@mujibur.inmind.com> mfinney@inmind.com writes:

> This is one of the biggest problems with C/C++.  Since typedef is
> "transparent" you can't overload on it.  If C/C++ had a "type" which
> is identical to "typedef" except that the type defined is opaque so
> that overloading is possible then programming could be simplified in
> many cases.  And would have made the bool type unnecessary because
> it COULD have been defined in the language with that extension.

How would you arrange for the expression 3<4 to yield the right type?
--
    --Andrew Koenig
      ark@research.att.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]