Xref: utzoo comp.std.c:317 comp.lang.c:12158
Newsgroups: comp.std.c,comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Third public review of X3J11 C (a scientist speaks up)
Message-ID: <1988Aug28.051702.20988@utzoo.uucp>
Organization: U of Toronto Zoology
References: <64919@sun.uucp> <8358@smoke.ARPA> <4566@saturn.ucsc.edu> <1988Aug26.162706.22671@utzoo.uucp> <899@l.cc.purdue.edu>
Date: Sun, 28 Aug 88 05:17:02 GMT

In article <899@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>> >Sounds like somebody wants an extensible C.
>> 
>> It's been done, it works well, and it's readily available:  C++.
>
>There are gross weaknesses in C++...

I didn't say it was perfect, I said it worked well.  There is a difference.
Nobody expects a language to keep everybody happy.  (Personally I doubt
that any language would keep Herman Rubin happy.)  C++ is a fairly well-done
and highly usable extensible C.

>It does not allow the introduction of new operators, for example.

There is room for debate about whether dynamic alteration of language
syntax is a good idea.  C++ does provide for new operators, provided that
you are willing to use function-call syntax for them.  Call syntax is
admittedly clumsy for anything complicated, but user-defined syntax is
a real minefield for both users and implementors.

>It does not address the problem of multiword
>hardware types, using machine dependencies where they can profitably be
>used (see the discussion about short x short -> long)...

You mean, the current *implementations* do not provide for this.  There
is no reason why the implementation of a C++ type can't use hardware-
specific extensions when they exist.  The client interface can remain
machine-independent, as it generally should be.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu