Subject: RE: bool accepted == true ? (was Re: Abi string class)
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Thu Feb 01 2001 - 13:21:37 CST
> -----Message d'origine-----
> De : owner-abiword-dev@abisource.com
> [mailto:owner-abiword-dev@abisource.com]De la part de Thomas Fletcher
> Envoye : jeudi 1 fevrier 2001 18:00
> A : Mike Nordell
> Cc : AbiWord-dev
> Objet : Re: bool accepted == true ? (was Re: Abi string class)
>
>
> On Thu, 1 Feb 2001, Mike Nordell wrote:
>
> > Joaquin Cuenca Abela wrote:
> > > of course it will be cool to use map, vector, the algos, etc. but I
> > > think it's better to wait for our "supported" compilers to implement
> > > correctly the STL (btw, are there any "supported" compiler (not an
> > > imaginary one) that right now fails to implement this stuff?
> >
> > Yes. MSVC. PJP wasn't able to implement a conforming
> implementations since
> > M$ (the largest software company on earth?) couldn't produce a
> conforming
> > compiler. His implementation was buggy. Btw, it's confirmed they're not
> > going to deliver a conforming C++ compiler even with the 7.0. :-<
> > There are available bugfixes for the header files at dinkumware
> site, but M$
> > still ships the old buggy stuff.
>
> QNX is going to be using the latest from dinkumware.
>
> > But there is another problem we face. What "supported"
> compilers do we have?
> > Sam, feel free to pitch in any time. We maintain a "least common
> > denominator" approach atm which I _do_ approve of, no matter what my
> > postings might suggest. But I think we at least once in a while
> (6 months,
> > one year?) should evaluate our position re. these issues.
>
> I think that re-evaluating our position is fine, but I don't think that
> this switch to deciding that all of a sudden wham-o namespaces, templates
> and any or all of the other "advanced" (all in perspective) features
> are required or are needed. I believe that you should look at using
> a tool when that tool is required. We have done very well in terms
> of a size/speed/programmer burden trade-off in implementing our own
> components. I don't really want to have us only use half of one
> thing or half of another since halfs tend to fall apart and get
> really messy.
Just to be clear, me too, I think me too that we are sure that an addition
will not hurt us. Here, are the subject says, we are discussing about the
"bool" keyword (the rest are: "it would be cool if..." stuff).
Now, are there any supported compiler without "bool"? The reply is: no
supported compiler doesn't support bool. (And Dom has "proved" it :)
Anybody thinks that there is anybody out there that could understand what
means UT_Bool, UT_True & UT_False, and that could not understand what means
bool, true & false? I suppose that nobody will reply "yes" to this question
:)
So I think that it's ok to add to the guidelines that bool is a supported
keyword, and to run
find . -name "*.cpp" -exec perl -pi~ -e 's/#include "UT_Bool.h"//g;' '{}'
';'
find . -name "*.h" -exec perl -pi~ -e 's/#include "UT_Bool.h"//g;' '{}' ';'
find . -name "*.cpp" -exec perl -pi~ -e 's/UT_Bool/bool/g' '{}' ';'
find . -name "*.h" -exec perl -pi~ -e 's/UT_Bool/bool/g' '{}' ';'
find . -name "*.cpp" -exec perl -pi~ -e 's/UT_True/true/g' '{}' ';'
find . -name "*.h" -exec perl -pi~ -e 's/UT_True/true/g' '{}' ';'
find . -name "*.cpp" -exec perl -pi~ -e 's/UT_False/false/g' '{}' ';'
find . -name "*.h" -exec perl -pi~ -e 's/UT_False/false/g' '{}' ';'
and nuke UT_Bool.{cpp,h}
(sorry, I'm too tired to do a only one script ;)
PS: btw, I still think that namespace's and simple templates will be a nice
addition :)
-- Joaquin Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Thu Feb 01 2001 - 13:21:50 CST