In <comp.std.c++> dak@hathi.informatik.rwth-aachen.de (David Kastrup) writes:
>>In <comp.std.c++> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>>It would be quite reasonable for compilers to use a non-canonical
>>>representation where anything non-zero is true.  In this case,
>>>conversion from int to bool would be a no-op.
>
>>Not quite; the proposal explicitly says that a bool, when promoted to
>>int, yields the values 0 or 1.
>
>Well, what of it?

Quite right.  I read "bool to int" instead of "int to bool."


     -- Dag

In article <9334701.20716@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:

>>3) Has anyone examined the impact on performance of mixing 2 libraries, one
>>that supports the bool keyword, and one that doesn't, and the conversions that
>>will have to take place between an int and a bool (changing non-zero to 1). I
>>am thinking of the proposed String classes et al, and legacy code. Also, the
>>problems of mistyping a variable as int instead of bool in converting code.

>You are assuming that the compiler will implement bools using a normalized
>(canonical) representation where true=1 and false=0.
>It would be quite reasonable for compilers to use a non-canonical
>representation where anything non-zero is true.  In this case,
>conversion from int to bool would be a no-op.

I understand that it is required  to convert int to a bool with the value of 0
or 1. This means that converting from int to bool won't be a no-op.
Unfortunately, this means that I will be mixing old and new style bools until
ALL compiler and library vendors recognize the new keywords.

In article <trickr.11.000B9FAA@uh2372p03.daytonoh.ncr.com>
trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:

|> 4) How hard is it going to be for library vendors to write code that compiles
|> cleanly both with and without the bool keyword?

 #if GB_HASBOOL
 typedef bool  GB_bool ;
 #else
 typedef int  GB_bool ;
 #endif
 GB_bool const  GB_false = 0 ;
 GB_bool const  GB_true = ! 0 ;

I actually wanted to write:

 #if ! GB_HASBOOL
 typedef int  bool ;
 bool const  false = 0 ;
 bool const  true = ! 0 ;
 #endif

and write my library using bool, false and true, rather than GB_bool,
GB_false, and GB_true.  But what happens if someone wants to use my
library with another library that, say, uses '#define bool'?  (The
fact that the other library is not following good software engineering
practices doesn't help my user any.)  So I'll stick with private names
until *all* principle compilers have 'bool', and then do a global
search and replace.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

>>trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
>>>3) Has anyone examined the impact on performance of mixing 2 libraries, one
>>>that supports the bool keyword, and one that doesn't, and the conversions that
>>>will have to take place between an int and a bool (changing non-zero to 1). I
>>>am thinking of the proposed String classes et al, and legacy code. Also, the
>>>problems of mistyping a variable as int instead of bool in converting code.

>In article <9334701.20716@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>You are assuming that the compiler will implement bools using a normalized
>>(canonical) representation where true=1 and false=0.
>>It would be quite reasonable for compilers to use a non-canonical
>>representation where anything non-zero is true.  In this case,
>>conversion from int to bool would be a no-op.

In article <trickr.16.00100674@uh2372p03.daytonoh.ncr.com> trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
>I understand that it is required  to convert int to a bool with the value of
>0 or 1. This means that converting from int to bool won't be a no-op.
>Unfortunately, this means that I will be mixing old and new style bools until
>ALL compiler and library vendors recognize the new keywords.

Please change all "int to bool" with "bool to int" in the previous paragraph,
someone pointed out in another thread that it is possible for the
implementation to not store bool as a 0 or 1, but as some other values. This
would probably mean converting twice, once for int to bool, and once for bool
to int, but it is possible.

Thanx,
Ralph

I feel that the bool, true, and false keywords are necessary and I
applaud the efforts of Dag Bruck and Andrew Koenig in getting the proposal
passed. I wish they had been able to get them not synonymous with int, but it
is better than nothing. I think the argument about ++ is specious, especially
considering that retrofitting existing code to the bool keywords is going to
resemble retrofitting const to a project, since int * and bool * aren't
synonyms.

I have 5 questions about the new bool keyword.

1) Are changes to the proposed C++ basic class library being considered to
take advantage of the new keywords? I would assume so.

2) What is the impact going to be on run-time performance of NOT converting
existing code to bool? Looking at all the changes that have been made to the
operators, I can't help but wonder how many cases exist where the compilers
won't be able to optimize out the implicit conversion of int to bool.

3) Has anyone examined the impact on performance of mixing 2 libraries, one
that supports the bool keyword, and one that doesn't, and the conversions that
will have to take place between an int and a bool (changing non-zero to 1). I
am thinking of the proposed String classes et al, and legacy code. Also, the
problems of mistyping a variable as int instead of bool in converting code.

4) How hard is it going to be for library vendors to write code that compiles
cleanly both with and without the bool keyword?

5) Could I please ask all compiler vendors to produce at least a warning upon
the conversion of int to bool where it will impact performance (outside of if
statements, etc.)

Thanks,
Ralph

In <comp.std.c++> trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
>I feel that the bool, true, and false keywords are necessary and I
>applaud the efforts of Dag Bruck and Andrew Koenig in getting the proposal
>passed.

Thank you.

>1) Are changes to the proposed C++ basic class library being considered to
>take advantage of the new keywords? I would assume so.

Yes.

>2) What is the impact going to be on run-time performance of NOT converting
>existing code to bool? Looking at all the changes that have been made to the
>operators, I can't help but wonder how many cases exist where the compilers
>won't be able to optimize out the implicit conversion of int to bool.

I think the performance impact will be zero, at least if the
implementor decides to use the same size for both bool and int.

>3) Has anyone examined the impact on performance of mixing 2 libraries, one
>that supports the bool keyword, and one that doesn't, ...

No.

>4) How hard is it going to be for library vendors to write code that compiles
>cleanly both with and without the bool keyword?

First, the library vendor needs to know if a particular compiler
supports bool or not.  C now has something called __STDC_VERSION__,
which I think can be used for that purpose.

If you do not have a built-in bool type, I suggest you use these
definitions instead:

 typedef int bool;
 static const bool false = 0;
 static const bool true = 1;

If you write "decent" code that use these definitions, it should be
easy just to remove the definitions when you have a built-in bool
type.

Decent means for example that you do not use operator --!

>5) Could I please ask all compiler vendors to produce at least a warning upon
>the conversion of int to bool where it will impact performance (outside of if
>statements, etc.)

I think you should ask for an optional warning for conversions

 int  =>  bool
 T*   =>  bool

not for performace reasons, but for safety reasons.


    -- Dag

In article <trickr.11.000B9FAA@uh2372p03.daytonoh.ncr.com> trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
> I feel that the bool, true, and false keywords are necessary and I
> applaud the efforts of Dag Bruck and Andrew Koenig in getting the proposal
> passed. I wish they had been able to get them not synonymous with int, but it
> is better than nothing. I think the argument about ++ is specious, especially
> considering that retrofitting existing code to the bool keywords is going to
> resemble retrofitting const to a project, since int * and bool * aren't
> synonyms.

They are not synonymous with int.  And ++ is there merely as a transition aid;
I would encourage compiler vendors to warn about it use and hope it can be
removed from the next version of the standard.

> 1) Are changes to the proposed C++ basic class library being considered to
> take advantage of the new keywords? I would assume so.

Yes -- library functions will return bool where appropriate.

> 2) What is the impact going to be on run-time performance of NOT converting
> existing code to bool? Looking at all the changes that have been made to the
> operators, I can't help but wonder how many cases exist where the compilers
> won't be able to optimize out the implicit conversion of int to bool.

I would expect old code to work exactly the way it does now.  I can't think
of any cases where the optimization would be any harder than current practice.

> 3) Has anyone examined the impact on performance of mixing 2 libraries, one
> that supports the bool keyword, and one that doesn't, and the conversions that
> will have to take place between an int and a bool (changing non-zero to 1). I
> am thinking of the proposed String classes et al, and legacy code. Also, the
> problems of mistyping a variable as int instead of bool in converting code.

I don't see why there's an issue.  Again, such conversions are done today,
every time you write an `if,' `for,' or `while' statement.

> 4) How hard is it going to be for library vendors to write code that compiles
> cleanly both with and without the bool keyword?

Easy.  Use int or some other integral type for Booleans and call it something
other than `bool.'

> 5) Could I please ask all compiler vendors to produce at least a warning upon
> the conversion of int to bool where it will impact performance (outside of if
> statements, etc.)

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

trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:

>1) Are changes to the proposed C++ basic class library being considered to
>take advantage of the new keywords? I would assume so.

I would hope so, but I wouldn't put any money on it.

>2) What is the impact going to be on run-time performance of NOT converting
>existing code to bool? Looking at all the changes that have been made to the
>operators, I can't help but wonder how many cases exist where the compilers
>won't be able to optimize out the implicit conversion of int to bool.

For any reasonable implementation, there would be NO impact on the
performance of existing code which didn't explicitly use bool.

>3) Has anyone examined the impact on performance of mixing 2 libraries, one
>that supports the bool keyword, and one that doesn't, and the conversions that
>will have to take place between an int and a bool (changing non-zero to 1). I
>am thinking of the proposed String classes et al, and legacy code. Also, the
>problems of mistyping a variable as int instead of bool in converting code.

You are assuming that the compiler will implement bools using a normalized
(canonical) representation where true=1 and false=0.
It would be quite reasonable for compilers to use a non-canonical
representation where anything non-zero is true.  In this case,
conversion from int to bool would be a no-op.

>4) How hard is it going to be for library vendors to write code that compiles
>cleanly both with and without the bool keyword?

Not that hard.

 #include "config.h"
 #ifndef COMPILER_SUPPORTS_BOOL
 typedef int bool;
 #endif

Determining whether or not the compiler supports bool will require
a little effort, but no more than is already required for a whole
bunch of other things.  Any large and portable program will already
have some configuration scheme in place to handle these sorts of
things.

They also need to be somewhat careful to ensure that their code doesn't
depend on the newly available ability to overload on bool.
(Compiling with a compiler that doesn't support bool would be enough
to ensure this.)

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In <comp.std.c++> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>It would be quite reasonable for compilers to use a non-canonical
>representation where anything non-zero is true.  In this case,
>conversion from int to bool would be a no-op.

Not quite; the proposal explicitly says that a bool, when promoted to
int, yields the values 0 or 1.

     -- Dag

dag@control.lth.se (Dag Bruck) writes:

>In <comp.std.c++> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>It would be quite reasonable for compilers to use a non-canonical
>>representation where anything non-zero is true.  In this case,
>>conversion from int to bool would be a no-op.

>Not quite; the proposal explicitly says that a bool, when promoted to
>int, yields the values 0 or 1.

Well, what of it? Which of the two conversions has the work of
unifying was not specified, or was it? Is it told anywhere that
a pointer to a true bool has to convert to a pointer to a numeric
1? Certainly not. And the representation might differ between CPUs.
For 68xxx, I could imagine using the byte 0xff for true, 0x00 for false,
and usually bytewise logical operations for logic, if that proves
faster and without sideeffect.
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen