Subject: Re: UT_Bool vs bool
From: Mike Nordell (tamlin@algonet.se)
Date: Mon Feb 05 2001 - 14:37:46 CST
Paul Rohr wrote:
> Mike Nordell wrote:
> >Should we allow "bool" into the src and just
> > typedef bool UT_Bool;
> > #define UT_TRUE true
> > #define UT_FALSE false
[...]
> If this is the proposal, no. That's a good test, but a bad solution.
Well, that wasn't my proposal for a solution, only an intermediate way to
reach our goal: use bool instead of the "invented" not-really-bool-type
UT_Bool.
> It seems pretty clear that all existing platforms and compilers (on
> Tinderbox at least) will tolerate the change, but that was never the
issue,
> was it?
Wasn't it? Please enlighten me (us?). If I'm not completely mistaken this
"hack" was to allow something resembling a bool datatype on the compilers
not supporting it at that moment. Am I completely wrong? Did you think of
something completely different?
> The reason for the #defines is to protect against weirdness on
> future platforms.
Well, we have apparently already agreed upon the fact that future C++
compilers will be more, not less, conforming than current ones. This is
quite certain a correct prediction re. bool. Since current ones actually
allow bool, and it has sneaked its way into the src without any problems...
I might also add that you _introduce_ errors by "inventing" a sort-of-bool
datatype on compilers supporting bool. As already mentioned by lots and lots
of people in related newsgroups, a conforming compiler evaluates any logical
expression to a bool. If you try to fake this by any other datatype the
compiler will bite you whenever you want to overload anything on the bool
datatype.
> If the consensus is that people are willing to drop support for any crufty
> old compiler that doesn't support bool and friends, then go the whole way
> and purge UT_Bool entirely. There are plenty of script whizzes here who
> could generate the necessary commit.
Then that is probably what we should do. Replace any instance of UT_Bool
with plain bool, and its instance values with the "real" ones. Since the
last one _I_ know of was MSVC4.2 (i.e. MSC 10.x), and we _require (according
to our docs) at least MSVC5.0 to even build AW, I don't see where the
problems could arise.
But this rise another question to me, one that I'd reslly like answerded:
If you *never* believed to support on of the basic datatype "bool", why the
heck did you use crippled C++?! Was it just for the sake of cripple it?!
> That way, there's no ambiguity. If you want to build AbiWord on the
> platform of your choice, and your toolchain doesn't properly support bool,
> then you're SOL.
I agree. I also say that "If your compiler don't support bool by now, then
_you_ typedef or define it. You don't let _us_ suffer from it".
> That's what the real vote should be about.
So what was it about? Wasn't it about compatibility (which in the end is
what we're talking about)???
Should I have missed anything in the above, please comment. I'd really like
to hear some statements built on a reasonably firm foundation.
> PS: Our original philosophy was to just keep typing the few extra UT_
> characters as a defensive technique to avoid ever worrying about the
issue,
> but we're old-time ANSI C guys.
I think that's actually part of the problems we're facing now. Sometimes you
just have to realize you have started to code in one language (C) and find
yourself in another (C++). The paradigm shift (i.e. thinking in interfaces
rather than "structs+functions") is hard, and sometimes it hurts. But the
end result is worth it, big time! AW currently _is_ inside such a shift, and
it probably _will_ hurt. But unless we're here to care for it in this
process, who will?
> YMMV.
As always! ;-)
I however liked your input. In this case I regarded it non-educated (so
shoot me) but most of the time you say something it's *really* worth the
time to read it. So please, continue comment. And also beware, I never back
down from a good argument! :-) (is that an invitation or what?! ;-) ).
Again, I hope I didn't offend anyone, it was never my intention. My
intention was purely to educate and enhance AbiWord.
/Mike
This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 14:49:36 CST