From 1418068008886480544 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bf65828a2bbbc32e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-12-12 07:05:21 PST Newsgroups: comp.std.c++ Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: bool run-time performance impact Message-ID: <9334701.20716@mulga.cs.mu.OZ.AU> Keywords: bool Sender: news@cs.mu.OZ.AU Organization: Computer Science, University of Melbourne, Australia References: Date: Sun, 12 Dec 1993 14:58:39 GMT Lines: 50 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