From 5833757239549599639 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bf65828a2bbbc32e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-12-14 00:03:41 PST Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!ncrgw2.ncr.com!ncrhub2!torynews!ncrlnk!usglnk!uc2372c!uh2372p03.daytonoh.ncr.com!trickr From: trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) Newsgroups: comp.std.c++ Subject: Re: bool run-time performance impact Keywords: bool Message-ID: Date: 13 Dec 93 21:01:24 GMT References: <9334701.20716@mulga.cs.mu.OZ.AU> Sender: news@uc2372c.DaytonOH.NCR.COM (News Administrative Login) Organization: NCR Lines: 20 X-Newsreader: Trumpet for Windows [Version 1.0 Rev A] 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.