🚀 go-pugleaf

Anselm Lingnau (lingnau@tm.informatik.uni-frankfurt.de) wrote:
|> In article <KANZE.95Aug3174437@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

|> > 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). [...]

|> I still don't see a fundamental difference between the convention that
|> `0' is taken as `false' and `non-0' is taken as `true' in conditionals
|> and the convention that certain (small, as yet) integers correspond to
|> characters that you can print.

|> If anything, the `char' situation is worse: there is no guarantee that
|> the value 65 will get you an `A', for example, while the correspondence
|> between integers and `truth values' is fixed. And what sense is there in
|> having a `char' type that you can *increment* -- in a German locale,
|> should `char c = 'A'; ++c' give you `B' or `A-umlaut'? This seems to me
|> ample justification for a true character type where such operations are
|> outlawed, so we can avoid subtle errors :^)

The only case in C/C++ where incrementing a `character' (as opposed to a
`char' type) is portably defined is for digits: '0' + n (for n <= 9)
gives the character representation of n.  As this function is better
done with a table anyway (think about expanding it to handle
hexadecimal.  Remember, 'A' + 5 is *not* guaranteed to be 'F'.), there
is some justification in what you say.

In fact, there *is* some discussion in certain cercles that the basic
character type should *not* be `char', but wchar_t.  I do know that
allowing 8 bit signed `char' makes my life more difficult, and I'm not
concerned about internationalization -- if it can handle the French
characters, that's enough (for many applications).

All more arguements for having a special character type:-).

|> > 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.

|> I can see the justification for a built-in Boolean type as far as C++
|> is concerned. IMHO, it does not follow that C needs to go along with it.
|> C is nice, comparatively simple and *small*. Keep it that way.

Overall, I agree.  If I want C++ (and I generally do), I know where to
find it.  But I'd like to keep C (as a separate and different language)
available as an option.  I just don't see where a boolean type (or, for
example, C++ style comments) will make C significantly less simple or
bigger.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung