On 15 Aug 1996 18:14:29 GMT, Tom Chatt <tom-chatt@vertel.com> wrote:
:While I understand your point, and agree with it in general,
:it seems a bit of a stretch to agree with you in the case
:of 'bool'. Unlike many other new features of ANSI C++, the
:'bool' keyword is thoroughly straightforward and well-understood
:by everybody, trivial to implement, and would have virtually
:no breakage on existing code. The only code breakage that
:would occur is where people are using 'bool', 'true', or
:'false', which weren't previously keywords. But anyone using
:these is probably using them with the exact same semantics
:as the new keywords. In fact anybody supporting multiple

    yes, but imagine a situation where bool was emulated in a class
    library thusly:

    enum TBool { false, true };
    typedef TBool bool;

    this is clearly not a perfect emulation of the type bool (of
    course, there are no perfect emulations of any builtin type..),
    but it seems that just about any reasonable use of the above will
    be source code compatible with a future compiler implementing the
    type bool.

    it turns out, however, that the above enum was implemented by the
    compiler as a 4 byte integral type.  the developers of a future
    version of this same compiler chose, for technical reasons, to
    implement the builtin bool with a 1 byte integral type, breaking
    binary compatibility with code from the previous compiler.

    was this the right choice by either set of implementors?  i'm not
    certain --- there are valid arguments that can be made for either
    case (builtin type being binary compatible vs. it being more
    "optimal" for the target architecture).  in any event, progress
    was _not_ free.  in addition to not being binary compatible with
    this class library, the compiler was also not binary compatible
    with the other "obvious" bool emulation (typedef int bool;...).

 --xmsb



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 1ADD@vertel.com, Tom Chatt <tom-chatt@vertel.com> writes:
>James Kanze US/ESC 60/3/141 #40763 wrote:
>> I'm tempted to say: what bool keyword?  In the absense of any official
>> standard, I'd say that the ARM is the closest we can get, and there is
>> no bool keyword in the ARM:-).
>>
>> If you are developing production code, stability in your compiler is an
>> important virtue.  You don't want to have to rewrite your code with
>> every new release of the compiler, just because the compiler is trying
>> to track a still changing draft standard.
>
>While I understand your point, and agree with it in general,
>it seems a bit of a stretch to agree with you in the case
>of 'bool'. Unlike many other new features of ANSI C++, the
>'bool' keyword is thoroughly straightforward and well-understood
>by everybody, trivial to implement, and would have virtually
>no breakage on existing code.

Sorry, that simply isn't true.

Bool is a new type, with its own promotion and conversion rules.
Some library functions which traditionally had int parameters
or return types get bool types instead. Functions with bool
parameters must have different mangled names than with older
code that might have used a bool typedef or class. You might not
be able to link code from earlier compilers if bool was used
anywhere. Old and new object code might not be able to use the same
runtime (dynamically-linked or not) library.

If the identifiers 'bool', 'true', or 'false' were used in code,
that code probably won't compile, or may have the wrong semantics
if it does compile.

For a one-person project of a few thousand lines of code, switching
to a compiler that knows about bool costs at most a few hours work.
For project involving hundreds of people and having millions of lines
of code, it could delay product shipping for months.

Sun cares about such customers, and Sun itself is such a customer.
(We eat our own soup.) Within major revisions, compilers generate
upward-compatible code, so you don't have to recompile everything
on the system when you upgrade compilers. Code compiled with the
4.0 compiler can be linked with 4.2 libraries. That might not be
true if bool had been added.

---

In case the name-mangling (type-safe linkage) issue isn't clear,
consider this header:
 typedef int bool; // old code
 void foo(bool);
Code compiled with the old compiler would have seen this as
 void foo(int);

The header won't compile if the compiler has the bool type. You might
edit the header by removing the typedef. Function foo taking a bool has
a different calling sequence from function foo taking an int parameter.
Unless you recompile everything, there are going to be mismatches.
Functions with the same name but different calling sequences must
not get linked together, so name mangling must differ. Old code won't
know about the new name mangling scheme.

OK, instead of removing the typedef, change bool to Bool everywhere.
That means editing source files and headers (which on a big project
might take authorization from the local god), you have to recompile
everything. The end result and costs are similar to removing the
bool typedef.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze US/ESC 60/3/141 #40763 wrote:
> I'm tempted to say: what bool keyword?  In the absense of any official
> standard, I'd say that the ARM is the closest we can get, and there is
> no bool keyword in the ARM:-).
>
> If you are developing production code, stability in your compiler is an
> important virtue.  You don't want to have to rewrite your code with
> every new release of the compiler, just because the compiler is trying
> to track a still changing draft standard.

While I understand your point, and agree with it in general,
it seems a bit of a stretch to agree with you in the case
of 'bool'. Unlike many other new features of ANSI C++, the
'bool' keyword is thoroughly straightforward and well-understood
by everybody, trivial to implement, and would have virtually
no breakage on existing code. The only code breakage that
would occur is where people are using 'bool', 'true', or
'false', which weren't previously keywords. But anyone using
these is probably using them with the exact same semantics
as the new keywords. In fact anybody supporting multiple
compilers, including GNU g++ for instance (which has supported
'bool' for a good long time now), probably has some portation
include file with "#ifndef BOOL_SUPPORTED typedef int bool;" etc.
It's not like 'bool' is a moving target.

--
---------------------------------------------------------------
Tom Chatt                                  tom-chatt@vertel.com
Vertel
550 N. Continental Blvd.                    Voice: 310/606-0800
El Segundo, CA 90245                          Fax: 310/335-0186


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ug78e$f4i@news1.radix.net> may@ssims.nci.nih.gov (Chuck May) writes:


Chuck> I just started using the SPARCompiler C++ 4.1, and cannot believe that
Chuck> this compiler does not yet support the bool keyword.  Am I missing
Chuck> something?  Thanks for any help,


That is right, Sun C++ compiler does not understand the bool type. But
GNU's compiler does.

Anyway you can define bool to be an enum.

-- Gaby

--


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <3213544B.1ADD@vertel.com> Tom Chatt <tom-chatt@vertel.com>
writes:

|> James Kanze US/ESC 60/3/141 #40763 wrote:
|> > I'm tempted to say: what bool keyword?  In the absense of any official
|> > standard, I'd say that the ARM is the closest we can get, and there is
|> > no bool keyword in the ARM:-).
|> >
|> > If you are developing production code, stability in your compiler is an
|> > important virtue.  You don't want to have to rewrite your code with
|> > every new release of the compiler, just because the compiler is trying
|> > to track a still changing draft standard.

|> While I understand your point, and agree with it in general,
|> it seems a bit of a stretch to agree with you in the case
|> of 'bool'. Unlike many other new features of ANSI C++, the
|> 'bool' keyword is thoroughly straightforward and well-understood
|> by everybody, trivial to implement, and would have virtually
|> no breakage on existing code.

See the posting by Steve Clamage as to why this may not be the case with
bool.  I think my point is more general, however.  The question is, if
you opt for stability, the question is: where do you draw the line?  I
actually wouldn't mind if they introduced bool, for example; most of the
problems mentioned by Steve don't happen to affect *MY* code.  And
mutable or explicit seem even easier.  But what about member templates?
I think that they would affect even *less* working code than bool; they
are a pure extension which doesn't even introduce new keywords.  Yet
they would hardly qualify under your criteria of "thoroughly
straightforward and well-understood".

It is difficult to guess what effect a change may have.  For example, I
would have judged bool about like you did.  But Steve showed us that
this is not really the case.  Now put yourself in the place of the
product manager, who must decide which features to add.  Can you be sure
that any specific feature won't cause any number of problems that you
simply don't think of?  On the other hand, not adding a feature is sure
to not break code.

Again, I would like to stress that this is a marketing decision,
dependant upon the market you are targetting.  While Sun's decision
happens to correspond very well with my needs, this is not to say that
e.g. Borland is wrong in persuing a different policy.  They are simply
targetting a different market.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-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.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Gabriel Dos Reis wrote:
>
> That is right, Sun C++ compiler does not understand the bool type. But
> GNU's compiler does.
>
> Anyway you can define bool to be an enum.
>

It's not that easy! Defining bool to be an enum doesn't have the same
behaviour. Testing code and later using the same code with the real
bool type without revalidating the code is dangerous.

But the question is why doesn't SUN implement bool, member templates
etc. and allows and option to enable the new features?
By doing that, people could start to investigate the features but
no code will be broken (if you are not sure if you code will be
broken, don't enable the features).

Also, getting the features as soon as possible will enable to make
modifications to be up to date as soon as the are defined by the
standard - I bet SUN will sooner or later implement them when this
happens.

Peter Jakubek
pjak@berlin.snafu.de



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I just started using the SPARCompiler C++ 4.1, and cannot believe that
this compiler does not yet support the bool keyword.  Am I missing
something?  Thanks for any help,

Chuck May
IMS, Inc.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4ug78e$f4i@news1.radix.net> may@ssims.nci.nih.gov (Chuck
May) writes:

|> I just started using the SPARCompiler C++ 4.1, and cannot believe that
|> this compiler does not yet support the bool keyword.  Am I missing
|> something?  Thanks for any help,

I'm tempted to say: what bool keyword?  In the absense of any official
standard, I'd say that the ARM is the closest we can get, and there is
no bool keyword in the ARM:-).

If you are developing production code, stability in your compiler is an
important virtue.  You don't want to have to rewrite your code with
every new release of the compiler, just because the compiler is trying
to track a still changing draft standard.

What the compiler really needs is a -just-playing-around option, which
turns on all of the new features, and which you could use when you were
just playing around, rather than compiling production code.  The vendor,
of course, would make no guarantee that code compiled using this option
will still compile with the next release.  This basically would come
down to maintaining two compilers for the price of one, from the
vendor's point of view, so I can understand why they don't do it.

BTW: the "just playing around" is not meant to be perjorative.  We need
to play around some in order to learn the new features, before using
them in production code, and it is good that some compilers offer the
features immediately, so that the standards committee can get real user
feedback, from people actually trying them out.  On the other hand, I
don't want the compiler I use for production code to support these
features.

My impression is that the Sun compiler tries to be a production
compiler.  As such, I would be very angry with them if they made any
significant changes in the language they compile without changing the
major release number (e.g.: from 4.1 to 5.0).  It is worth noting that
the language compiled by 4.0 was certainly frozen before the bool type
was added to the language.  Sun is not one of the players in the version
of the month club.  (Sun is probably particularly sensitive concerning
the compatibility issues.  After all, they tried the "let's go with the
newest standard" once, with Solaris, with the result that they are now
supporting two OS's, instead of just one.)

Whether this is an advantage or a disadvantage of their compiler depends
on whether you are using it for production code or as an experimental
tool.  As a production tool, my major complaint concerning the Sun
compiler is the differences between 3.0.1 and 4.x with regards to
template instantiation.  The newer version may be closer to the current
draft, but it meant that some production code had to be reworked.  And
I'm still hoping that the final draft will support the template
instantiation model in 3.0.1:-), or something similar.  (The real bother
is that there are silent changes, without even a warning about an
anachronism.  Because of defensive programming, I was not too much
affected by the changes, but I still get nervous that I might have
missed one somewhere, and that some time in the future, one of my
programs is going to fail because of it.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]