🚀 go-pugleaf

In article <3va81j$b4c@deneb.tm.informatik.uni-frankfurt.de> Anselm
Lingnau <lingnau@tm.informatik.uni-frankfurt.de> writes:

|> In article <KANZE.95Jul26122240@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

|> > The result of a lack of an explicit boolean type results in precisely
|> > the ambiguities you are talking about.  How often does one see:
|> > 
|> > 	if ( strcmp( s1 , s2 ) )  /*  strings are not ==   */
|> > 	if ( p )                  /*  pointer is not NULL  */
|> > 	if ( *p )                 /*  not at end of string */
|> > 
|> > Such code has become so prevalent in C that some people actually argue
|> > that it is good, or readable.

|> I can see a problem with the strcmp(), which is why I use something like

|> 	#define STR_EQ(a, b) (strcmp((a), (b)) == 0)

|> But this has nothing to do with the boolean type issue. As far as the
|> `hacky' implicit comparison to 0 in the last two examples go, as a C
|> programmer with some experience I find their meaning completely obvious,
|> though I don't use them in code that I write (well, not often, anyway).

And why not:-)?  I agree that with experience, one can get used to
reading anything, but why this insistance on making it hard for the
reader?

|> > My point is precisely that C has, at least implicitly, a built-in
|> > boolean type.  You cannot have `if' or `while' otherwise.

|> I don't buy that. The zero/non-zero convention as used by conditionals
|> doesn't make `int' a `built-in boolean type'. C doesn't have a built-in
|> character type either (the way Pascal does), and that doesn't keep us
|> from using `char' to do string operations. Anybody want to argue for
|> a built-in character type that's not an integer type?

I don't claim that `int' is a `built-in boolean type'.  What I am
saying is the the compiler requires a logical predicate to decide a
two way branch.  This predicate is your built-in boolean type.  Now,
there is no expression in C which evaluates to this type, so the
compiler is obliged to ``convert'' an int or a pointer to such a
predicate.

The analogy with characters in Pascal breaks down in that the compiler
never needs a character type; the type *doesn't* exist in C (yet).  As
one who has to work in non-English speaking environments, however, I
can tell you that this is a real problem; some of the French and
German characters are negative in my environment, which makes ctype
problematic, even with locale correctly set.

|> > (Seriously, the problem of breaking existing code means that it is
|> > impossible to adapt anything more than a compromize solution.)

|> Exactly. So all you end up with is a gratuitiously complex language
|> definition. It would be more worthwhile to fix your compiler to emit
|> a warning if you use an implicit comparison to 0, rather than force
|> a built-in boolean type down everybody's throats.

That's one solution, but it doesn't work in C++ due to function
overloading.  I will admit, however, that there is a definite conflict
between what I would really like to have, and what to do with existing
code.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung