Xref: utzoo comp.object:3584 comp.lang.c++:13650
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!bu.edu!m2c!risky.ecs.umass.edu!dime!connolly
From: connolly@livy.cs.umass.edu (Christopher Connolly)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: C++ and waitresses (long)
Keywords: C++, software reuse
Message-ID: <31061@dime.cs.umass.edu>
Date: 24 May 91 20:54:44 GMT
References: <2325@media03.UUCP> <1991May24.015856.9979@csusac.csus.edu>
Sender: news@dime.cs.umass.edu
Reply-To: connolly@livy.cs.umass.edu (Christopher Connolly)
Followup-To: comp.object
Organization: University of Massachusetts, Amherst
Lines: 47

In article <1991May24.015856.9979@csusac.csus.edu> brian@babbage.csus.edu (Brian Witt) writes:
>In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
>> You can do it
>>virtual, but you can also do it not virtual, but then you have problems
>>there. You can make it static, but static in that context means something
>>different in that context, you can use references or copying of values. It
>>keeps forcing you to make decisions which hardly have anything to do with the
>>problem domain, but are just a kind of goodies giving you certain
>>optimisations in certain cases.

I agree wholeheartedly.  The language is probably too big for its own
good, and its bigness results from an obsession with backward
compatibility and efficiency.

>IMHO, C++ promotes building a typesafe object-based *application*.

We've been through this before - I don't see what's "safe" about being
able to cast pointers back and forth at will.  As has been pointed out
previously, the programmer who lies to the compiler is asking for
trouble, but this fact doesn't make C++ "typesafe".

>for each kind of list contents we want to store.  We really want
>parameterized types!!!  Does GNU G++ suuport this???

Irrelevant -- Kriens is talking about language issues, not
implementation issues.

>Even Ada has its place.  Many firms will fall in bed with C++.  Many
>will succesfully produce products.

My experience so far suggests that a more accurate statement might be
"Many will successfully produce `.H' files.".  Certainly, there will
be successful products implemented in C++, but in a major industrial
site that I work at, there is an alarming trend: People who have been
charged with writing C++ code have, by and large, been producing
specs, class declarations and function prototypes in #include files.
So far, even after several months, precious little actual code has
been written.  The problem appears to be not knowing where to start
and how to implement.  I think Kriens' points apply directly to this
situation.  They are faced with too many choices and are afraid to
commit themselves.  I am fairly convinced that this would not have
happened if the project's language had been C.

I am not saying that this is going to be a universal phenomenon, but I
think it will be frequent.

				-C. Connolly