From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Any research putting c above ada? Date: 1997/04/18 Message-ID: <5j83p0$sp7@bcrkh13.bnr.ca> X-Deja-AN: 235746867 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <335458A4.4C1D@worldnet.att.net> <5j30oa$ia9@bcrkh13.bnr.ca> <3355739E.7B24@pratique.fr> Organization: Prism Systems Inc. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-18T00:00:00+00:00 List-Id: In article <3355739E.7B24@pratique.fr>, Valentin Bonnard wrote: >Kaz Kylheku writes: > >> In article <335458A4.4C1D@worldnet.att.net>, >> James S. Rogers 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.