Re: Any research putting c above ada?

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <3355739E.7B24@pratique.fr>,
Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>Kaz Kylheku <kaz@vision.crest.nt.com> writes:
>
>> In article <335458A4.4C1D@worldnet.att.net>,
>> James S. Rogers <JimMaureenRogers@worldnet.att.net> wrote:
>> >Tom White wrote:
>> >> 
>> >> I remember a Turing Award Lecture by C.A.R. Hoare from the early
>> >> eighties (dig through some Journals of the ACM).  Hoare was not
>> >> an Ada booster; he was concerned about the complexity of Ada from
>> >> both the application programmer's and compiler implementor's
>> >> perspectives.
>
>I'd say that both are complex (comparing C++ to Ada 95) because they 
>are general purpose and support both structured and OO programming 
>with many neat things like genericity and exceptions.
>
>I'd think complexity is a problem (as long as the languge is 
>resonably orthogonal).
>
>> C++ is lame. 
>
>Let me disagree.

Okay. :)

>> This goes without saying. What's funny is that C++ is actually
>> _worse_ than C in many ways.
>
>C++ is more type safe (convertion void* -> T* is disallowed, and 
>each enumeration define a distinct type).

I suppose that the C++ designers want an award for this trivial change?

Pointers to void play an important role in C programming. It buys you nothing
to prevent an implicit conversion from void * to another pointer type.  All it
does is force you to put in a cast. Funny, the treatment void * seems to be the
example that C++ zealots always come up with when asked how C++ is more type
safe than C.

The enumerations are nice, though.

>> In some places it opens up holes.
>
>You mean something which is well-behaved in C and not in C++ ?
>
>Except the NULL pointer constant do you know any ?
>[int i = NULL is valid C++, not C.]
>
>> For example, consider that in C++, it is _undefined behavior_ to fail
>> to return a value from a function that returns some non-void type.
>> This could easily have been turned into a _constraint violation_.
>
>It's nearly the same from std point of view:
>
>- in Ada, the std say raise in case of such error; compilers give 
>  way to disable the test and you get undefined behaviour

??? Is that so?

>- in C/C++, thestd say the behaviour is undefined in case of such 

There is no such language as C/C++. And what the C++ draft says and
what the C standard says about this matter are two different things.

>  error; the compiler is free to optimise the code by guessing this 
>  won't appen or generate a runtime check and show a nice error 
>  message in case of exception

I'm sorry, I don't see how the omission of a return expression in a non-void
function can lead to better optimization. If you don't intend to return
a value, you should declare the function as not returning anything.

>So it's a quality of implementation problem more than a std problem.

No, it's a standard problem. I reiterate: in C, you can fail to return a value,
or you can ``fall of the end'' of a function that returns a value (two
semantically equivalent variants). The behavior is well defined so long as the
_caller_ ignores the return value of the function. I'm not saying that this is
a good thing.  Note that this could be treated as a simple constraint violation
easily diagnosable at _compile time_.  You parse the return statement, note
the lack of an expression, note the return type of the function you are in by
consulting a symbol table and complain!  It should be a constraint
violation---the only reason it is not in C is for historic reasons. Once upon a
time, C programmers simulated procedures by doing things like this:

    foo()		/* this is really an int returning function */
    {
			/* do something		*/
			/* now fall of the end	*/
    }

Bad stuff, but understandable. However, C++ takes the opportunity to make it
worse. Instead of properly constraining the semantics of return statements,
they opened up a bigger hole.  It is now _undefined behavior_ in C++ to do:

    int foo()
    {
	return;
    }

As I said, this is trivial to diagnose. But no, C++ has to make demons fly out
of your nose instead. :) That's language design for you.  The committe has been
at it for years now, and have produced a 780 page document that stacks three
inches high when printed double-sided.  Yet they can't get simple details right
like function calls and returns. What a failure.

>You don't understand the spirit of C++. The same goes for every runtime 
>error (for example dereferencing null pointer); it's undefined
>behaviour: 
>the implementation is free to check it or not.

From the looks of it, the ``spirit'' of C++ seems to be inspired by the
ingestion of spirits.

Here is another goodie: In C++, an assignment expression is itself an lvalue.
The main purpose of this seems to be to allow new ways of invoking undefined
behavior:

    int c;
    (c = 3) = 4;	/* oops, c modified twice between the prior and next
    			   sequence point */

In C, this sort of rubbish is not allowed. An assignment expression does
not inherit the lvalue-ness of its left constituent, hence the above
would be caught by a conforming C compiler. The committee should have
added sequencing properties to the assignment operator to protect against
undefined behavior.

The idea is that the above can be exploited in situations involving functions
that return references (situations in which the function call conveniently
provides a sequence point, making everything legal). You can bet that
it is used incorrectly more often than not.