From 8804443576733704169
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,bf65828a2bbbc32e
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-12-11 12:21:02 PST
Path: gmd.de!newsserver.jvnc.net!yale.edu!cmcl2!news.ans.net!howland.reston.ans.net!pipex!sunic!news.lth.se!dag
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.std.c++
Subject: Re: bool run-time performance impact
Date: 11 Dec 1993 11:02:52 GMT
Organization: Department of Automatic Control, Lund, Sweden
Lines: 58
Message-ID: <2ec9cs$41i@nic.lth.se>
References: <trickr.11.000B9FAA@uh2372p03.daytonoh.ncr.com>
NNTP-Posting-Host: control.lth.se
Keywords: bool

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