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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c04a86d57d8e19c4 X-Google-Attributes: gid103376,public From: Valentin Bonnard Subject: Re: C vs Ada code quality Date: 1997/04/26 Message-ID: <336163A0.7B56@pratique.fr>#1/1 X-Deja-AN: 237411550 References: To: Robert Dewar Organization: Internet Way Reply-To: bonnardv@pratique.fr Newsgroups: comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: Robert Dewar writes: > Someone asked me, but I lost the email address, because it bounced, the > following (so I am not sure who asked) Me, Valentin Bonnard, bonnardv@pratique.fr, and it shouldn't bounce (I have checked the from field was ok in the message I sent). > Ok this is a pretty small problem, but this is an example which > can be part of 'distributed fat' (many small overheads which > end-up slowing the program). [...] > Also, I understand that it may be difficult to compare different > compilers using different optimising methods. > > Any reasons why Ada could be faster (in theory, no real numbers > required) then C or C++ when all checks are off ? ;-) > >> > > > > A couple of important points here > > C IS NOT THE SAME LANGUAGE AS C++ ! > > This confusion is an amazingly common one. I made a statement about C, > but the response assumes I was talking about C++, false! I know that ! In fact this is about Ada vs The Rest of the Universe, that is, C and C++ ;-) If you want, I can even tell you a list of incompatibillity betwen C to C++ (all from memory). > However, the example here is bogus. The contstructor/destructor mechanism > in C++ is entirely analogous to the controlled type facility in Ada 95. I'm not a specialist of Ada, but it seem to me that the analogy is imcomplete since C++ rely on overloading (compile time) and Ada on overiding (run time). > There is nothing in Ada 95 that says that the tag is stored as part of > the value -- note that in formal RM terms, the tag is NOT part of the > value, and if you start thinking of it, even informally, as part of > the value, you will find the RM confusing (for example, an assignment > copies the value, but it does not copy the tag). Ok, ok, like the dynamic type of an object in C++ (ie the vtable pointer - no, this word, vtable, is only there to annoy you). > An implementation of destructors and constructors in C++ may or may not > add overhead to stored objects. An implementation of controlled types > in Ada 95 may or may not add overhead to stored objects. In any case > you are in the business of comparing implementations, not languages. No no no, I am *not* comparing a particular implementation, nor purely a std (the C and C++ std don't say anything about performance, I assume the Ada std doesn't either). We are talking about performance in general; for example in C, malloced data is slower than auto variable because free-store is slow and the stack goes fast; of course, there isn't anything in the C std about the fact that there will be a stack at run-time. You could even design a C interpretor where stack is not faster than malloc (if your interpretor still check the entire program for erroneous constructs at compile-time it can be conformant). _Seriously_ destructors and constructors won't add any overhead in C++ whereas virtual functions will; and in my understanding of Ada 95 ctor and dtor (the 'controled' functions) are virtual (= dynamic dispatch) thus the overhead. > < required) then C or C++ when all checks are off ? ;-)>> > > Absolutely, consider the aliasing problem, in C, we write > > *q = 1; Real arguments ! That's exacly what I asked for. > and if q is a *int, then without very hard analysis 'very hard' is correct (one would say impossible) > that in any case can > never be entirely complete, we have to assume that any int values that > are temporarily in registers may be destroyed. Typically i counter (in for (i=a; i There are many other cases > in which the "excessive" freedom of C pointers degrade the generated code. Any example ? if (sizeof (int) == sizeof (long)) { long l = 2; int *p = reinterpret_cast (&l); *p = 1; cout << l; is this what you mean by 'excessive freedom' ? A compiler doesn't have to handle that and can put l in register and happily print 2 (rule to C++ programmers: remember that reinterpret_cast is nearly always unportable). > Now this does not mean that an Ada compiler *will* do a better job, but > it means it could. Ok But is it different in Ada ? Does the 'aliased' keyword really help ? Does this keyword serve any purpose (the compiler can look at the source to see if you are taking accesses to a variable directly) ? Is it like the register keyword in C (ie the semantic of a register variable is the same but you can't take its address) ? Thank you for your reply. -- Valentin Bonnard mailto:bonnardv@pratique.fr http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)