Re: Elaboration worries

["Randy Brukardt" <randy@rrsoftware.com>]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:4fssh9F1ena5jU1@individual.net...
...
> From past discussions and from reading an old article of Mr. Dewar, my
rule
> of thumb is that you should
>
> a) make your package Pure.
> b) if not possible, make it Preelaborate.
> c) if not possible, put an Elaborate_Body in the spec.

Unfortunately, this rule of thumb is wrong (you probably got it from reading
the old article). Adacore later discovered that having Elaborate_Body in a
spec does not eliminate elaboration problems, and their modern versions of
GNAT don't make any recommendation for this. We were bitten rather badly by
this with Claw (which followed your list of recommendations quite closely).
I forget the exact reason that Elaborate_Body doesn't work, but the effect
is that you can't count on it to eliminate elaboration problems completely.

Effectively, if you do much of anything at elaboration time, you'll need
Elaborate_All in the clients for any packages that aren't at least
Preelaborate. There is nothing whatsoever that can be done for the service
packages that prevents that. (It's really a flaw in Ada, but one that cannot
be fixed without radical surgery and incompatibilities -- not an option
these days).

My personal rule of thumb is:
   (a) make your package Preelaborate if possible (Pure is so limited that
no real packages ever qualify) -- but this is usually impossible because I/O
and Calendar aren't Preelaborate. Which means that you can't trace or log a
Preelaborate package (well, there *is* one way to do it, but it adds runtime
overhead);
   (b) if not (a), try to avoid doing anything at elaboration time other
than use language-defined packages;
   (c) if not (b), then you have to add Elaborate_All for anything used at
elaboration time.

(c) usually happens when you have generic instantiations at the library
level, or you declare controlled objects at the library level. The latter
can be avoided, the former obviously can't.

I've long since given up running code (the 'begin' part of a package body)
at elaboration time; there always seems to be some reason that you have
initialization dependencies that aren't encoded in the elaboration order
(for instance, the need to load parameters from the registry or a
configuration file before starting a subsystem). I use appropriate
initialization routines (and often checks for calls to other routines in the
package that the initialization has been properly called).

Hope this helps.

                         Randy.