>>>>> On 20 Nov 90 19:13:21 GMT, jamiller@hpcupt1.cup.hp.com (Jim Miller) said:

David> Previously [I] wrote:
David> programmer learning curve for there to be a significant overlap in
David> ANSI-C and C++, but there is already divergence, so why not attempt to
David> improve things?

Jim> Because C code is being brought into C++ wholesale in some cases.  An
Jim> earlier thread *seemed* to complain about ANY divergence from ANSI C or
Jim> maybe even K&R I C (at least that's what I felt some comments said).

My point was that the wholesale importation of C code into C++ may be a long
term problem that nobody is willing to address (namely converting non-object
oriented code into object oriented).  I feel its better to separate this out
into separate areas -- object oriented code and non-object oriented code.  As
it happens, the link step provides a strong integration point between these
two disparate areas of code development.

Jim> IMO, anything that would give people (managers or programmers) reasons
Jim> NOT to adopt C++ should be avoided.  These reasons, mind you, need not be
Jim> valid, just there.  One big reason is/would be the dreaded
Jim> "incompatability", just there being such things (never mind they might
Jim> not happen) keeps people away.

The reason to adopt C++ (or any object oriented language) is the *supposed*
ease of development and maintenance that it offers.  This should be more than
enough reason to coax people into looking at the language.  As long as their
*old* code is still usable by "linking" it in with their newer, more robust,
object oriented code, then what's the problem?  Eventually, they convert
completely to the new language and, if their C++ compiler avoids supporting
bad or ambiguous code forms, their code is now more solid than it was before.

Jim> The reason I supported the char x[4]="abcd"; incompatability is because
Jim> is is *usally* an error.  If it were not, I'd be against it.  Even so I
Jim> would be willing to support not making the change if it seems that anyone
Jim> is really bothered about it (by "really" I mean code is affected).  I
Jim> would also be forced to back off by anyone pushing the "no
Jim> incompatability" banner in the interest of acceptance.

On the one hand, you seem in favor of adopting code forms that are better than
the current standards.  On the other hand, you seem afraid that your new pet
language will die out unless you accept things that may not be good overall,
but maintain peace in the development of the language.  I submit that you
could have your cake and eat it, too, by going for the linkage standard.

NOTE: I'm not suggesting abandoning the high degree of similarity between C++
code and C code (it makes the learning curve easier).  I just don't think its
necessary that C++ adopt all ANSI-C or K&R C.  This has already happened in
enough areas to cause many people problems (maybe not a lot) and I think the
above "linkage standard" provides the standard by which this can work.  The
point is, though, adopting this "linkage standard" requires some rethinking
about how to advertise C++ in order to gain its acceptance.  Instead of using
C++ as a "super-C", suggest using it as development environment like Fortran
or COBOL, but use it in conjunction with a good C compiler.
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"