home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!mundil.cs.mu.OZ.AU!fjh
- From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
- Subject: Re: New C++ type: boole
- Message-ID: <9220914.11530@mulga.cs.mu.OZ.AU>
- Sender: news@cs.mu.OZ.AU
- Organization: Computer Science, University of Melbourne, Australia
- References: <DOUGM.92Jul26200316@titan.cs.rice.edu>
- Date: Mon, 27 Jul 1992 04:44:30 GMT
- Lines: 90
-
- The following is actually from Deviasse Robert N <a228devi@cdf.toronto.edu>.
- I am posting it for him, since he does not have write access to the net.
- Disclaimer: if you don't like it, blame him! :-)
-
- Fergus.
-
- ========================== PROPOSAL FOLLOWS =============================
-
- Actually there is a general way of adding a boole type without breaking any
- C++ code. Every DOS compiler I've used (and a few UNIX ones) already give
- warning for code such as "if (ch=getchar()) /*...*/;". Such warnings could
- easiliy be made manditory in the standard, or the standard could reserve
- a pragma that does this type of checking, though the implementation may
- choose not to implement it. Market pressure would probably force most
- compilers (the ones that do no implement this feature yet) to implement
- the macros anyway, although they need not. This alone would go a long
- way towards providing the benefits of a boolean type "universally". However,
- there are other cases that would be nice to fix. What most of us would like
- is protection from the following type of situation:
- void f(int x) { /*...*/ }
- void f(BOOL y) { /*...*/ }
-
- f(a==b); /* OOPS, wrong f() called!!! */
-
- The simplest way to avoid this situation is if BOOL were declared "int",
- since the second f() would be illegal. This is really not so significant
- since it is very rare for both function overloadings to be intentionally
- needed. However, if BOOL==int then we lose a lot of the nice properties
- of BOOL being an enum, such as the need for explicit casts. What we need
- is an enum that protects us from unintentional mistakes like the above.
-
- Suppose we modify the enum construct to the following form
-
- enum <integral_type> <id> { id < = value > { , id < = value > } ;
- ---- - - - - - -
-
- where an underlined word is a keyword or punctuation,
- < A > means that A is optional
- { A } means that A is repeated 0 or more times
-
- The semantics of this new enum would be that during overload resolution of
- a function, the enum would conflict with integral_type. However, no automatic
- conversion between enum and integral_type would occur beyond what is
- presently allowed in C++. Also, to make this type of enum more useful, the
- enum would have exactly the same size as the integral_type and have it's
- enumerations represented in the type of the integral_type. Thus one could
- use these enumerated types in structures that required enumerated types of
- the given size.
-
- So that if we define:
- enum int BOOL { FALSE, TRUE };
-
- then the following produce errors:
- void f(int x) { /*...*/ }
- void f(BOOL y) { /*...*/ } /* error: conflicts with f(int) */
-
- similarly
- void f(BOOL y) { /*...*/ }
- f(BOOL(a==b));
- would require a cast.
-
- It would be nice if we had such an enumerated type in the standard library,
- perhaps in <boolean.h> of the following form.
- enum int Boole { boole_false, boole_true };
- This would reduce the number of different flavours of boolean types that
- programmers currently define.
-
-
- I think that most people would like to have a boolean type in C++, although
- most people have resigned themselves to thinking that boolean types
- cannot easily be added to C++.
-
- I thing this is a fair workable compromise that allows the programmer
- to protect him/her self without turning the semantics of C++ inside-out.
- True, the above is a "humpty-dumpty" enum, but then what's wrong with
- Humpty-Dumpty, many computer science books quote from Lewis Carol :-)
-
- ------
- I don't have write-access to the net, although I have no problem reading
- from the net.
-
- BTW, I'm not going to write to the ANSI committee to extend the C++
- language to add this type of enum, I'm far too busy. If someone else
- wants to pick up this proposal, then be my guest. Otherwise, please
- post this proposal to /dev/nul.
-
- /----------------------------------+------------------------------------------\
- | Robert N. Deviasse |"If we have to re-invent the wheel, |
- | EMAIL: a228devi@cdf.toronto.edu | can we at least make it round this time"|
- +----------------------------------+------------------------------------------/
-