"Pascal Obry" <pascal@obry.net> wrote in message
news:47E11F35.5000900@obry.net...
> Maciej Sobczak a �crit :
> > Is it possible to "prohibit" dynamic allocation for the given type?
>
> Just a quick idea... What about using a storage pool which raises a
> program_error when using it. Then apply this storage pool to the type
> where you want to forbid dynamic allocation. Shouldn't something like
> this work?

If this did work (it doesn't, as mentioned by many), it would be easier to
simply specify 'Storage_Pool to be 0, which prohibits allocation.

But the whole idea seems dubious to me. Most types (ADTs) ought to be
constructed so that the client can use them in whatever way they want - that
is, they shouldn't only work in a single way. (Non-ADT types aren't really
interesting, as they usually are hidden in a package body, or are some sort
of discrete type for which nothing very interesting can happen.)

Moreover, for types where lifetime matters (like types with automatically
released locks), *how* the object is created is not really relevant. An
object allocated from a local access type, or even one allocated from a
global access type that is later freed with Unchecked_Deallocation both
would meet the requirement of a limited lifetime.

Which is all to say that Ada doesn't really have a way to express lifetime
of types (at least of ADT types), and thus you have to fall back on usage
rules as part of the documentation of the ADT. As someone else mentioned,
someone who uses a lock in a global context doesn't understand the purpose
of the type very well...

More generally, there are always going to be things that cannot be
statically expressed in a programming language. This seems like one of them
for Ada.

                                   Randy.