NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/19728

Internet Message Format | 1993-01-24 | 5.0 KB

Xref: sparky comp.lang.c++:19728 comp.object:4987
Newsgroups: comp.lang.c++,comp.object
Path: sparky!uunet!usc!rpi!uwm.edu!linac!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1993 23:16:18 GMT
Lines: 95

In article <[e-mail]> [e-mail] (Philip Santas) writes:
>
>In article <[e-mail]> [e-mail] (Dave Griffith) writes:
>> [e-mail] (Philip Santas) writes:
>>
>>Argggh, you force me to come back.  The reason it complicates the formal
>>is not that finding the correct bindings is difficult.  The reason that the
>>formal semantics gets complicated is that previously primitive operations
>>may now exhibit non-termination, abnormal return (setjmp or exceptions),
>>modification of global state or stack, implementation-defined behavior,
>>and ghod knows what else.
>
>Since in C++ you _cannot_ redefine primitive operations with means
>other than macros (and we were not talking about macros), nothing of the
>problems you mention occur. Notice that equalty on integers, for instance,
>cannot be redefined. The reason it cannot, is that int is not a class;
>you can redefine operators only in classes.
>

You have asserted that this is not a problem in languages in which primitives
are classes (Smalltalk, Axiom/Scratchpad).  The problems I discussed are
still present in those systems.  C++'s (IMHO) inconsistent design decision to
treat primitives as non-class types is hardly a point in it's favor.

>I understand that you want to substitute a symbol, say "=", with one value
>all over your formalism, but the fact that you cannot do it, does not mean
>that the language is complex, it means that you have to find another way
>to deal with it. Furthermore, people feel comfortable with operators
>like "+" and "*" which have been primitevely overloaded for reals, integers,
>etc. There is no reason why not to treat "=" in the same way.
>

If you've still got the archive, the value/object discussion of a month
ago makes my position pretty clear on this subject, in probably overly
deep detail.

>Notice also that we deal with a non-trivial type system (I do not discuss
>how it is implemented, this is another story)
>Denotational semantics have elegant approaches on simple type systems,
>but for more complicated ones they are confusing. Notice that by
>assuming _traditional_ subclassing, you have a form of overloading "=",
>since the objects have (od do not have) to coerce to the superclasses
>in many cases. This overloading occurs with every link you add.
>

Nonsense.  In traditional subclassing, there is no concept of coercing to
the superclass at all.  Coercions, if they occur, are utterly orthogonal to
the subclassing heirarchy.  C++ implements this _very_ poorly (truncating
objects if passed by value!) but calling this traditional inheritance is
just wrong.

>> If you don't think that these complicate
>>formal semantics then you've never had to write one.
>
>As I said, they do not complicate it more, than normal, standard inheritance
>does. If you think that the DSD of C++ is more complex that ST-80,
>or Eiffel, then make the comparison, and show us the results.
>Then you have to show that the increased complexity derives from
>overloading operators like +, =, etc. BY HAND.

As much as I would love to spend the next decade (a conservative estimate)
working on a formal definition of C++, I'm forced to pass.  Even suggesting
that someone might need to put in that huge amount of work to prove this
utterly trivial point weakens your case.

>
>> Not only does the formal
>>semantics need to worry about these new possibilities, so does every
>>programmer (neophyte and expert).  In this case, adding functions is different
>>than overriding primitives, because primitives come with garauntees of
>>behaviour which are not there with user defined functions.
>
>Yes. Primitives on _primitive types_ come with garantees.
>Do not forget this.

Only because C++ is inconsistent in it's treatment of primitive types!

>
>I do not see _what_ you can garantee on user defined data types,
>Have you ever tried to garantee equality on sets, by means of
>primitive definition of equality? Or equality on functions?
>

For sets, certainly.  With Eiffel class invariants. Admittedly it isn't compile
time checkable (that would require a solution to the halting problem), but
the garauntee is nonetheless expressible.

What I would really want to know is why we're both wasting this much time
on such a trivial point.

--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
When buying and selling are controlled by legislation, the first things bought
and sold are legislators.