comp.lang.ada
 help / color / mirror / Atom feed
From: Maciej Sobczak <see.my.homepage@gmail.com>
Subject: Re: Task components, the rationale
Date: Thu, 14 Jul 2011 11:15:53 -0700 (PDT)
Date: 2011-07-14T11:15:53-07:00	[thread overview]
Message-ID: <a30f4a5d-baee-40b5-b30d-2a15042868e7@r9g2000yql.googlegroups.com> (raw)
In-Reply-To: 4e1eae6c$0$6570$9b4e6d93@newsspool3.arcor-online.net

On Jul 14, 10:52 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:

> > You have to just, you know, simply, introduce constructors to the
> > language. This is my pet feature for Ada 2020. :-)
>
> Out of curiosity, would this be enough?

It would not be sufficient, but it would be necessary.

The point is, in order to solve these kind of puzzles you have to
recognize initialization as a special operation (ie. stop pretending
that it can be a regular primitive operation of a type) and use that
notion to impose special rules.

In the case of access discriminants the circular relationship is
possible to discover statically. After all, the whole T'Access
"expression" is special, and allowed only in this particular case.
Once you statically know you have a problem, you can work from there -
but no matter what kind of restrictions or provisions you impose in
the constructor, you have to recognize that it is a special operation,
not a regular primitive one.

If you ask me from the top of my head how *exactly* this can be
solved, I will not attempt to give a full solution (hey, the committee
has a full decade for it ;-) ), but one of the possible ideas might
involve adding a lifetime information to the access discriminant, just
as it is done for tracking scopes of types and objects with anonymous
access parameters today. That is, raise Program_Error when you
discover that within the constructor of T its access discriminant
(pointer to outer) is dereferenced while the outer was not yet
initialized.

Most cases (like the two examples we have shown) can be fully analyzed
statically for this.

> Assuming, naively, not knowing C++, that constructors of C++
> could lead the way,

They will not lead the way in solving the problem of dangling
pointers, because this is not the problem that C++ was designed to
solve in general. But recognizing that the constructor is a special
place is an important contribution.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com



  reply	other threads:[~2011-07-14 18:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13 18:52 Task components, the rationale Dmitry A. Kazakov
2011-07-13 20:58 ` Maciej Sobczak
2011-07-14  8:52   ` Georg Bauhaus
2011-07-14 18:15     ` Maciej Sobczak [this message]
2011-07-22 23:28       ` Randy Brukardt
2011-07-14  9:23   ` 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