Xref: utzoo comp.object:3581 comp.lang.c++:13646
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!hp4nl!media03!pkr
From: pkr@media03.UUCP (Peter Kriens)
Newsgroups: comp.object,comp.lang.c++
Subject: C++ and waitresses (summary, long)
Message-ID: <2326@media03.UUCP>
Date: 24 May 91 14:44:02 GMT
Organization: Mediasystemen, Netherlands
Lines: 191


Not so long ago I posted a message about my feelings
ABout C++. Though there were not so many responses on
the net, I received a lot of messages through direct
mail. I will not mention the names because they
posted it directly to me. I put > ahead of quotes.

When I posted I expected a lot of flames for me having
doubts about the effectiveness of C++. Surprisingly there
was only one person who disagreed. He actually liked 
having many choices. This addresses the basic point
of my previous posting: Is the attractiveness of choices
depending on country? I know that the USA loves choices,
Jim Showalter (well know in comp.object) had the following
joke:

> There's an old joke about a guy ordering in a super-ritzy restaurant,
> and when it comes to the coffee he says he wants coffee and the
> waiter says "Very good sir: Kona or French Roast?", the guy selects
> Kona and the waiter says "Very good sir: cream or sugar?", the guy
> selects cream and the waiter says "Very good sir: Guernsey or Holstein?".

Which I think quite nicely reflects the C++ language. So the
question is do we really win with options. I remember a
story about why the Americans have been so succesfull in
industry in the past centuries. While the English build
everything custom, the Americans started to standardize. For example
on ships the Americans used 2 or 3  types of pump while the
English used about 20 different types. The Americans 
needed less people to train. The disadvantage was that
they did not use the optimum solution for a certain case.

I think this equals a computer language. Having only very
few constructs, allow you to build everything though it
may not be the most optimal construct for a certain problem.

But that reminds me of the case where I tried to optimize
a piece of code because it was used so heavily. I changed
the sequence of code and just goto's to let the most
used path become the sequential thread (thereby allowing
the instruction queue to work most efficient). The end was that I just
made things worse because the compiler stopped optimising. So
it seemed that adding information to the function disallowed
the compiler to make optimisations. This seems through in
many cases. Adding informations makes reuse worse. And if 
we want to save this industry, we have got to find a way
to increase the reuse of code.

And do we really need all that optimisation? I have always
been surprised about how much time people spent in 
optimising things. Since I started about 13 years ago
I heard the same discussion about speed optimisation while
in the mean time we have now computers that are about a
40 times faster. Where did that performance go? As far as
I have heard and experienced there is usually only a small
part of code responsible for your performance. I always like
the rules of M.A. Jackson: rule 1 Dont do it. Rule 2, (for 
experts only) Dont do it yet.
----
Ok, the next point some people made was that C++ is
basically such a difficul language because it needs
to be compatible with C.

Is that true? Is C++ really a natural extension to C? What
is the concept of C, I think it is a (almost) device
independent assembler (watch the typecast), definitely not a high level 
language.As an assembler it is a great tool, it allows
you to work closely to the CPU and thereby taking care
of highly efficient code (if you really know what you do).
But what I do not believe is that C++ is the natural
extension to this on the contrary. I think C++ is something
that got stuck between C (the assembler) and the first
floor (the higher level language). Some languages are
already on the fourth floor...

I would be very interested to hear from Bjarne 
Stroustrup. I would be surprised if he really liked what has
become of his dreamchild. I think he started quite nice
with the class construct (though why add that keyword, struct
would have done just nice), but then so many things were
added that were just goodies. Ending up with language
that is neither usuefull as an assembler (ever looked
at the code?) nor a high level language (try to teach it...).

-----

I had one person telling me that he only had the down
casting problem:

>         A few comments: the only siutation where I've gotten
> into lots of typecasting is when I store a bunch of pointers
> to objects as void* out of laziness (I have an array class that
> works on void*, and it's easier to use that than to write a new
> array class.  I understand that templates will fix this, when they
> are availible.).

Funny, how people are willing to fix the shortcomings of
something they have chosen. Why in the world would anybody
want to write an Array class for different types? They will
all use the same algorithm, dont they? So why should you
be forced to spell out on which type you want it to 
operate?

Besides this genericity problem, I experienced many times
that in normal inheritance and especially multiple inheritance
there is no alternative, not laziness, but is is the
only solution without duplicating code. But I could be
wrong about that. But every time I try to do something
intelligent with inheritance I run into this
type problem. Some people agreed with me on this
point, and one added the fact that this is typical
a C++ thing. 

For example, maybe people can show me a solution
to the following problem

	struct Linked { Linked *next(); };
	struct My {};
	struct MyLinked : public Linked, public My {};
	main() { MyLinked *x; x = (MyLinked*) x->next(); }
	(BTW, this compiled with an internal error in Zortech.
	it worked with an intermediate, so I guess it is ok?).

It is a very easy problem, but it forces me to downcast
the next procedure to a MyLinked. And I also understood
that on certain implementations this might not work at
all because of virtual bases etc. Help.... If I am
right in understanding that this is basically the only
way to do it, then I dont understand the type safety
of C++, if you are forced to bypass it many times,
it does not seem very usefull?

--
I also got some questions why I complained about the
const keyword. I tried to explain that though the
concept is stated quite clearly, it seems that once you
start using it, you end up changing a lot of old code
and it propagates fast! If you start afresh I found
it was mostly annoying, just another thing to distract
you from the problem domain.

---
One person made a very good comment about extendability:

>         However this messiness is also a strength. When c users needed
> new features, there were a number of techniques that could be used to
> implement needed constructs. I contrast it with Pascal, an elegant
> minimal language. When pieces were found to be missing from Pascal, such as
> string manipulation, it was very hard to add them in. In this country
> C has become a dominant implementation language, and I attribute it to the
> fact that users were able to do things in the language that the original
> designers had never anticipated, whereas a minimal spanning language lacks
> the redundancy that provides for improvisation.

I completely agree with the fact that a language should
be extendable. But strange enough I found that languages like
C and C++ are definitely not extendable. Both languages have
defined keywords which you definitely cannot change. You
cannot implement your own if or virtual. I found that in
Smalltalk all this is possible because there are no keywords
in the language, just like Prolog. And what I understood from Lisp this
is also the case. So if you talk about extending a language,
then C(++) is definitely not an extendible language. The
usuage is fixed (well as long as Bjarne can keep his
hands of the definition, ehhh.. sorry which definition?).

----

A common remark, to which I agree, is that whatever
I think about it, it will be the dominant language of
the 90's. Somebody wrote:

> programming.  However, I think C++ will become the major language for
> many environments, while alternatives like Eiffel, Objective-C, and
> such will languish in relative obscurity, because of the ease of
> moving to C++ from C and its wide availability.

I do not agree with the fact that Eiffel and Objective-C
will vanish. There will always be an audience which makes
their choices on performance. If not, the Macintosh would
have vanished long ago.

One way or the other the industry seems to chose
non-optimal solutions. We got stuck with MS-DOS, Windows
and C++. I will use it, but I will always have a feeling
that it could have been much easier if choices were made
on performance instead of just marketing.

	Peter Kriens