Re: What's wrong with C++?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 11-10-08 03:36 , Randy Brukardt wrote:
> "Yannick Duch�ne (Hibou57)"<yannick_duchene@yahoo.fr>  wrote in message
> news:op.v2u8hzeyule2fv@index.ici...
>> e Wed, 05 Oct 2011 07:13:16 +0200, Niklas Holsti
>> <niklas.holsti@tidorum.invalid>  a �crit:
>>> Doesn't Ada have a similar theoretical problem with the elaboration
>>> order? I seem to remember that finding a valid elaboration order for an
>>> arbitrary Ada program is rather difficult, in general, and compilers are
>>> allowed to give up on it.
>> I am not aware enough of the techniques used there, and not a compiler
>> implementor, but I guess this is a divide-and-conquer strategy. I suppose
>> this end to be solving a graph route problem, not a Turing complete
>> language interpretation.
>>
>> You raised a good question anyway, I'm curious to know (may be an answer
>> in some GNAT design papers, or some answers from Randy).
>
> I implemented that a long, long time ago, and haven't had to fix anything in
> it in a long time,...
   [snip]
> I don't know of any real problem with elaboration given the Ada rules; the
> usual problem comes when someone tries to change those rules from dynamic to
> static rules (as GNAT does). Janus/Ada doesn't attempt that.

Thanks for your explanation, Randy.

I think the problem I remembered was to find an elaboration order such 
that the program would be certain not to call a non-elaborated 
subprogram, that is, that it would not raise Program_Error because of a 
failed Elaboration_Check (LRM 3.11). So it requires more than finding an 
order that is valid according to the LRM dependency rules.

Having now re-read some of the GNAT User Guide chapter on elaboration, 
my understanding is that in general such an elaboration order may not 
exist, and it is unsolvable to decide if it exist, and unsolvable to 
find it, if it does exist. But if you follow the static rules suggested 
in the GNAT UG, the compiler either finds a such an order, or tells you 
why it can't.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .