comp.lang.ada
 help / color / mirror / Atom feed
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: generic package dilemma
Date: 1999/11/22
Date: 1999-11-22T00:00:00+00:00	[thread overview]
Message-ID: <81bt4v$7cr$1@nnrp1.deja.com> (raw)
In-Reply-To: 3835CF7A.5604C6A3@mail.com

In article <3835CF7A.5604C6A3@mail.com>,
  Mats Weber <matsw@mail.com> wrote:

> Actually, I have used pragma Elaborate(_All) maybe three times
> since 1983. I have always let the compiler figure out an
> elaboration order, which turned out to be just fine in almost
> all cases with DEC Ada, Verdix and GNAT. I know this approach
> is not striclty portable, but I don't care.

Well this is a bit like people not caring about seat belts in
a car till they have a crash.

We have lots of cases of legacy code, particularly Verdix code,
where the programmers were, quite unknowingly relying on
non-portable behavior. It is very bad programming practice
to omit the pragmas (*). In one hard, we had one customer
with a large code who spent quite a bit of time running the
program and finding out one bug after another of omitted pragma
Elaborate's causing Program_Error.

The problem is not that VADS is better at finding an elaboration
order than GNAT or vice versa, just that they guess differently
in situations where there is no one right way of doing things.
You can construct cases where GNAT (**) will succeed where
Verdix will fail and vice versa.

So Mats may have been lucky programming without an Elaborate
seat belt so far, but I do not recommend this risky behavior
for others! I have seen far too much grief caused by this
viewpoint.

> and I still think that some minimal automatic elaboration
> order generation should be in the language standard (see my
> thesis).

The story here is that basically we all agreed, but we also
agreed that trying to do this in a reasonably upwards compatible
manner was far from easy, and there simply was not enough time
available in the course of the Ada 95 design.

I definitely agree with Mats in general terms, though I do NOT
agree with approaches which require building a call tree and
tracing actual execution paths through package bodies.

Our experience is that the static elaboration approach in GNAT
(which was a very large development effort, which is ongoing as
we find new aspects, most recently the issue of task bodies for
tasks started at elaboration time) works remarkably well, and it
is basically simply an automation of the rules about using
pragma Elaborate_All. If you ever had to port a GNAT program to
another compiler which provided only the old style dynamic
elaboration checks, then you could use -gnatwl to tell you where
to put the missing pragma Elaborate_All statements.

So generally the GNAT implementation attempts precisely to let
people program in the way Mats recomends (don't bother about
elaboration), and be sure of not running into trouble.
Basically, it is a collision avoidance strategy that makes
sure you don't need seatbelts :-)

(*) It is actually safe to omit the pragmas when using GNAT in
its static default elaboration mode, as noted above.

(**) This is referring to GNAT running in -gnatE mode which
replicates the traditional dynamic elaboration mode. We have
to use the -gnatE mode for validation to get through one test
whose comments make it clear that it was written (in some sense
in horrible style) precisely to undermine any attempts to find
an order of elaboration statically :-)


Sent via Deja.com http://www.deja.com/
Before you buy.




  reply	other threads:[~1999-11-22  0:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-17  0:00 generic package dilemma Riyaz Mansoor
1999-11-17  0:00 ` Matthew Heaney
1999-11-17  0:00   ` Mats Weber
1999-11-17  0:00     ` Matthew Heaney
1999-11-18  0:00       ` Mats Weber
1999-11-18  0:00         ` Matthew Heaney
1999-11-19  0:00           ` Mats Weber
1999-11-19  0:00             ` Vladimir Olensky
1999-11-19  0:00             ` Matthew Heaney
1999-11-19  0:00               ` Robert Dewar
1999-11-19  0:00                 ` Matthew Heaney
1999-11-20  0:00                   ` Mats Weber
1999-11-19  0:00                 ` Robert I. Eachus
1999-11-22  0:00                   ` Robert Dewar
1999-11-22  0:00                     ` Matthew Heaney
1999-11-19  0:00               ` Mats Weber
1999-11-22  0:00                 ` Robert Dewar [this message]
1999-11-22  0:00                   ` Robert A Duff
1999-11-23  0:00                     ` Robert Dewar
1999-11-29  0:00                       ` Robert A Duff
1999-12-01  0:00                         ` Robert Dewar
1999-12-01  0:00                       ` Robert A Duff
1999-12-02  0:00                         ` Mats Weber
1999-12-03  0:00                           ` Robert Dewar
1999-12-03  0:00                             ` Robert A Duff
1999-12-06  0:00                               ` Robert Dewar
1999-12-03  0:00                             ` Ted Dennison
1999-12-04  0:00                               ` Robert Dewar
1999-11-22  0:00                   ` Mats Weber
1999-11-22  0:00                     ` Robert A Duff
1999-11-23  0:00                       ` Robert Dewar
1999-12-01  0:00                       ` Robert I. Eachus
1999-12-01  0:00                         ` Robert I. Eachus
1999-11-22  0:00                   ` Mats Weber
1999-11-22  0:00                     ` Bryce Bardin
1999-11-23  0:00                     ` Robert Dewar
1999-11-22  0:00                   ` Larry Kilgallen
1999-11-23  0:00                     ` Robert Dewar
1999-11-18  0:00       ` Robert A Duff
1999-11-18  0:00         ` Matthew Heaney
1999-11-19  0:00       ` Robert Dewar
1999-11-18  0:00   ` Riyaz Mansoor
1999-11-19  0:00     ` Robert Dewar
1999-11-19  0:00   ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox