comp.lang.ada
 help / color / mirror / Atom feed
From: Ludovic Brenta <ludovic@ludovic-brenta.org>
Subject: Re: Run-time accessibility checks (was: Construction initialization problem)
Date: Sat, 6 Dec 2008 09:10:49 -0800 (PST)
Date: 2008-12-06T09:10:49-08:00	[thread overview]
Message-ID: <68719e0e-af31-488a-b45c-f8db93fb70d2@v13g2000yqm.googlegroups.com> (raw)
In-Reply-To: txbc0ucekvix.ntpy85qsan7h$.dlg@40tude.net

Dmitry A. Kazakov wrote:
> It would be interesting to make a poll, how many programmers
>
> 1. start straight with Unchecked_Access
>
> 2. write Access first and then switch to Unchecked_Access after the first
> compiler message without analyzing the message
>
> 3. try to understand the message and change the design

Put me in category 3. However, changing the design isn't always
desirable because alternative designs may have unacceptable drawbacks.

> My guess is 65-30-5. Yours?

I don't know but I don't remember seeing any Unchecked_Access that
wasn't thoroughly explained in the comments near it; this would
indicate the person who wrote it was at least in category 2.

> > I've been trying to work on this problem, but the obvious solutions would
> > require full dynamic accessibility checks, including passing the
> > accessibility of all by-reference parameters -- and that is way too
> > expensive to consider. Plus dynamic checks provide a new failure mechanism
> > for code; it's not clear that is an advantage.
>
> Ooch, this is the major contributor to the group 1. If I had any danger
> that X'Access might fail at run-time, I would immediately switch to
> X'Unchecked_Access.

Actually, the presence of run-time accessibility checks are the reason
that puts me in category 3. If the run-time overhead or, worse, the
possibility of failure at run-time are unacceptable, then I prefer not
to use access types at all.

> It is absolutely unacceptable to me that a correct
> program might fail at run-time because of accessibility checks.

I differ here; to me, a program that fails an accessibility check at
run time is incorrect.

> The only
> case I could buy it, if exceptions where contracted, so that I would get an
> compile-time error at some other place. Like "Constraint_Error may be
> propagated, but the contract states otherwise."

In my understanding, there is an implicit contract stating that all
subprograms may raise at least Program_Error, Storage_Error or
Constraint_Error. I accept that as a fact and keep it in mind when
designing.

--
Ludovic Brenta.



  reply	other threads:[~2008-12-06 17:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-06 10:15 Run-time accessibility checks (was: Construction initialization problem) Dmitry A. Kazakov
2008-12-06 17:10 ` Ludovic Brenta [this message]
2008-12-07  8:44   ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-07 14:56     ` Ludovic Brenta
2008-12-07 19:22       ` Dmitry A. Kazakov
2008-12-11  1:03     ` Randy Brukardt
2008-12-11  9:08       ` Dmitry A. Kazakov
2008-12-11  0:55 ` Run-time accessibility checks (was: Construction initialization problem) Randy Brukardt
2008-12-11  9:48   ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-11 11:21     ` Georg Bauhaus
2008-12-11 11:40       ` Dmitry A. Kazakov
2008-12-11 22:15   ` Run-time accessibility checks (was: Construction initialization problem) Randy Brukardt
2008-12-11 22:31     ` Randy Brukardt
2008-12-13  0:49       ` Randy Brukardt
2008-12-13  9:06         ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-16  1:53           ` Randy Brukardt
2008-12-16  9:28             ` Dmitry A. Kazakov
2008-12-16 22:21               ` Randy Brukardt
2008-12-17  8:54                 ` Dmitry A. Kazakov
2008-12-12  9:21     ` Dmitry A. Kazakov
replies disabled

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