home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!rice!news.rice.edu!dougm
- From: dougm@titan.cs.rice.edu (Doug Moore)
- Subject: Re: New C++ type: boole
- Message-ID: <DOUGM.92Jul26151240@titan.cs.rice.edu>
- Sender: news@rice.edu (News)
- Organization: Rice University Computer Science, Houston, Texas
- Date: Sun, 26 Jul 1992 21:12:40 GMT
- Lines: 178
-
- >>>>> On Sun, 26 Jul 1992 17:59:44 GMT, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) said:
-
- Dougm> P. S. The latest draft of the proposal follows.
- Dougm> Constructive feedback is still welcome. Shall I
- Dougm> officialize it and send it off to our beloved standards
- Dougm> committee?
-
- Fergus> Um, well, no. Without intending to insult anyone, I
- Fergus> have to say that this proposal has so many flaws that
- Fergus> I don't know where to start. I couldn't be bothered
- Fergus> replying the first time, reasoning that someone was
- Fergus> bound to shoot it down soon enough anyway :-). But
- Fergus> before you send it off to the committee, at the very
- Fergus> least it needs some substantial improvements. Oh well,
- Fergus> here goes...
-
- I won't take offense to your criticisms if you won't take offense when
- I find them largely groundless. Generally I find that the "so many
- flaws" you refer to boil down to just one: C++ with any builtin
- boolean type is flawed. So naturally, you wouldn't like this proposal
- either.
-
- Dougm> programming idiom. No proposed change to C++ can invalidate such
- Dougm> expressions. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Fergus> ^^^^^^^^^^^^^
- Fergus> To most of us, that point is enough to convince us
- Fergus> that any attempt to add a boolean type to C++ is not
- Fergus> going to buy us enough that it is worth the effort
- Fergus> required to implement it.
-
- So you don't want a boolean type. Fine. That is a matter of taste
- and programming style, not a technical criticism. To make one of
- those, you have to argue that the proposed changes *will* "invalidate
- such expressions".
-
- Fergus> 0t ??
- Fergus> This is woefully counter-intuitive. If you *have* to
- Fergus> have syntactically special values for true and false,
- Fergus> at least make it "1t". (What's wrong with
- Fergus> "boole::false" and "boole::true" or some such?) C++
- Fergus> is hard enough on beginners already, let's not add yet
- Fergus> another complicated and counter-intuitive syntactic
- Fergus> construct.
-
- You claim 1t is more intuitive, but that is only because you think
- that 1==true and 0==false are the natural way of thinking about
- things. They are not. The beginners about whom you are concerned are
- the ones who write
-
- #define TRUE (1==1)
- #define FALSE (0==1)
-
- because they're not entirely sure that *their* C compiler produces 1
- and 0 for truth values. Programmers in Fortran have no conceptual
- problem with .TRUE. and programmers in Scheme have no trouble with
- #t. C++ programmers are just as capable of understanding 0t.
-
- Fergus> So you are going to give me a warning if I write
-
- Fergus> if (ptr) ...
-
- Fergus> but not if I write
-
- Fergus> if (!ptr) ... ?
-
- Yes, I am.
-
- Fergus> Sounds very counter-intuitive to me.
-
- Well, I am sorry for that. To many people, the idea that a pointer to
- that character over there is also "true" and a pointer to no character
- at all is also "false" is counter-intuitive. I don't claim to have
- data to support the assertion that one set of intuitions is more
- common than another.
-
- I suggest that you disable boolean warnings.
-
- Fergus> Can you stick to proposing one extension at a time, please?
-
- I can, but I view this as a single extension. So I think I'll keep it
- as one.
-
- Fergus> The merit of &&=, ||= is very debateable, as is the
- Fergus> idea of introducing a new idiom ++ for toggling
- Fergus> logical values. (Why not just use "negate(t)" instead
- Fergus> of "t++"? The former seems to convey the meaning much
- Fergus> more clearly.)
-
- To call a thing "debateable" is not quite as useful as actually
- debating it. The idiom ++ for toggling logical values is not new.
- Here, for example, is an example taken from the Sun manual page for
- the getopt C library function:
-
- while ((c = getopt(argc, argv, "abo:")) != -1)
- switch (c) {
- case 'a':
- if (bflg)
- errflg++;
- else
- aflg++;
- break;
- case 'b':
- if (aflg)
- errflg++;
- else
- bproc ();
- break;
- case 'o':
- ofile = optarg;
- break;
- case '?':
- errflg++;
- }
- if (errflg) {
- (void)fprintf(stderr, "usage: . . . ");
- exit (2);
- }
-
- Is negate(t) clearer? I don't know. Is rem(a,b) clearer than a%b?
- Is deref(p) clearer than *p? I only know that plenty of people
- already use '++' for logical negation.
-
- Fergus> Also you are asking for a lot of work for the compiler-writers.
-
- That's their job. But if they are short of time, they can stop
- working on exception handling (try, etc.) because I don't have any use
- for it, I find it counterintuitive, and I find that it might cause all
- my programs that use "try" as a variable name to break. :-)
-
- Besides, I do not believe that the work required would be exceptional.
-
- Fergus> One more comment: what about all the standard library
- Fergus> routines? Are you going to change isdigit() etc. to
- Fergus> return booles?
-
- Were I concerned with library standardization, which I am not, I would
- suggest that routines that return only true and false values, like
- isdigit, should return booles, and that routines that return integers
- that indicate ordering, like strcmp, would not change.
-
- Fergus> Can you imagine all the conflicts you are going to
- Fergus> get, whichever way you decide to go?
-
- I am confident that your imagination is more vivid than mine in that
- regard.
-
- Fergus> I strongly suspect that even if this proposal was
- Fergus> accepted and implemented, programmers would just
- Fergus> disable the warnings rather than bother fixing all
- Fergus> their old code.
-
- Some would. You would. And how would you suffer damage? You would
- have to add -fdisable-boole-warnings to your makefile somewhere.
-
- There are several reactions to my proposal that I can respect. They
- are:
-
- 1. I don't like it, because I like to mix types as I now can in C.
- 2. I don't like it, because it is fundamentally flawed.
- 3. I don't like it, becuase <some aesthetic issue about 0t or somesuch>.
- 4. It is flawed, but fixable; here's how.
- 5. Such insight! We'll get it in our compiler right away!
-
- You claim to belong in category 2. You belong in category 1. I sense
- that the substantial improvements you would have me make would be in
- the nature of shortening the proposal. Possibly to a single blank
- character.
-
- I can accept that some people don't want change, or don't want a
- boolean type in particular. If you hold that opinion, express it and
- I won't argue with you. But don't state that a proposal is full of
- holes (i.e. ambiguities, self-contradictions, contradictions with the
- current standard, etc.) unless you are willing to present them.
-
- *Constructive* feedback is still welcome.
-
- Doug Moore
- (dougm@cs.rice.edu)
-