Re: C vs Ada code quality

[Valentin Bonnard <bonnardv@pratique.fr>]

Robert Dewar <dewar@merv.cs.nyu.edu> 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.

> <<Any reasons why Ada could be faster (in theory, no real numbers
> 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<b; i++)) aren't aliased and 
stay in register (otherwise we wouldn't be able to transform 
loops (for example loop unrolling)).

> 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<int*> (&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)