From 2357581618320572830 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bf65828a2bbbc32e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-12-14 10:04:56 PST Newsgroups: comp.std.c++ Path: gmd.de!xlink.net!josef!josef!kanze From: kanze@us-es.sel.de (James Kanze) Subject: Re: bool run-time performance impact In-Reply-To: trickr@uh2372p03.daytonoh.ncr.com's message of 10 Dec 93 16:37:20 GMT Message-ID: Sender: news@us-es.sel.de Organization: SEL References: Date: 14 Dec 1993 13:28:49 GMT Lines: 34 In article 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