Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!uflorida!gatech!udel!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!sun-barr!ames!hc!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: C++ design
Summary: Syntax could HAVE BEEN made simpler...
Keywords: information
Message-ID: <1022@aber-cs.UUCP>
Date: 22 Jul 89 14:01:27 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal)
Lines: 90

In article <9476@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
    
    The complexity of C++ reflects this range of uses and requirements.
    Given this, estimates of C++'s complexity is often greatly inflated.

Well, well. C++ is a nice job, but but... Several "features" seem to have
been put in because they *looked* right. A much too experimental attitude,
let's say. Example: visibility rules. They are not well understood, or
at least there is no consistent model of them, and there are many dark spots.

    It would be trivial to design a syntax for C++ that was noticeably
    easier to parse,

Ah no! You should have written "It would HAVE BEEN trivial ...". It can be
argued that some ambiguities and problems of the C++ syntax descend from
mistakes or at least questionable laxity on your part. Example:

	a b(c);

This is fairly ambiguous. Old C hands know that C itself once allowed a
similar syntax

	a b { c };

that was dropped in favour of the

	a b = { c };

syntax because the former could confuse the compilers (as said in K&R and/or
the V7 Unix C docs). I understand that

	complex i(0,1);

looks neater than

	complex i = complex(0,1);

but the latter is amply sufficient... Why ever was a variant of the ambiguous
initialization syntax without '=' crept back into the language when it had
been expunged precisely because of ambiguities?

This is the most glaring example, in that a (arguable) *mistake* has been
actually *reintroduced* in the language. The other ambiguities or problems
are also often fairly pointless, in that their benefit is not great (e.g.
automatically typedef'ed class and struct names, casts that look function
calls or declar), and they have obvious counterindications (ask Michael
Tiemann...).

    but we would also have a major conversion and education
    problem on our hands

Yes, because it is now too late to rectify mistakes or pointlessly
sophisticated syntax features. Too many users depend on them; and users
outnumber compiler writers by a wide margin...

    (and I'd probably get tarred and feathered by irate C programmers).

What does this mean? That to make C++ syntax simpler and less ambiguous
you would want to change C syntax, because it is C that gives you problems?
If so (as the parts I have not commented on of this article seem to imply),
I beg to differ. The underlying C syntax and semantics have their warts (e.g.
"typedef", "enum", "int;", bit fields that may be signed or unsigned at the
compiler's whim even if explicitly declared "int" or "unsigned", ...), but
they have proven livable with.

C++ *adds* to them, and sometimes with fairly gratuitous incompabilities
(e.g. typedef). It is not unusable for this, far from it, but a bit of the
sense of grace that emanates from C has been lost.

Finally my point on the Eiffel/C++ controversy: I use C++ because I am a
systems person, and even if Eiffel has very clever technology, it simply
cannot go where C++ can. The claim that C++ goes wherever C could have gone
(in both lowly hackerism and tightness) is substantially true. Eiffel seems
an higher level language, somewhat intermediate between C++ and Smalltalk.

But the main difference is that C++ has been designed *without* the backing
of a comprehensive philosophy of object orientedness, but rather in a
pragmatic, trial-and-error fashion (and it shows). Eiffel is the result of
specific conscious high brow analysis of OO program development (even if
adjustments are being made) from time to time, and as such has its
attractions to those that are persuaded by it.

I tend to agree to the Modula-2/C (less worrying to Eiffel advocates than
the Pascal/C one... :->) analogy for Eiffel/C++; the C style of language is
a sharper tool than most others, and if you can handle its (optional) unsafe
features you can go a long way.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk