On Mar 19, 10:38 am, Adam Beneschan <a...@[EMAIL PROTECTED]
> wrote:
> On Mar 18, 8:06 pm, gp...@[EMAIL PROTECTED]
wrote:
>
>
>
> > On Mar 18, 5:30 pm, Maciej Sobczak <see.my.homep...@[EMAIL PROTECTED]
> wrote:
>
> > > Is it possible to "prohibit" dynamic allocation for the given type?
>
> > > Let's suppose that I have a type which instances make sense only on
> > > the stack.
>
> > Ada is high level language and stack is implementation specific
> > entity. ARM does not mention how the local objects are allocated (it
> > simply irrelevant). In fact, GNAT uses two stacks for different type
> > of objects but users don't have to know these details.
>
> > > I want to prohibit users from dynamically allocating
> > > instances of this type so that they don't get into troubles.
> > > Preferably at compile-time.
>
> > What's wrong with good old comments atop of type declaration. Like
> > some beverages have: "for most enjoyment serve chilled" or "for best
> > performance avoid heap allocation".
>
> > Don't know if it's ever possible to do it during compile, nothings
> > comes to my mind. But if you insist you may do run-time check by
> > defining custom Storage_Pool pool for your object and raising
> > exception from Allocate method. See ARM 3.11 for details.
>
> No, you can only specify a Storage_Pool for an *access* type; you
> can't specify that "all allocated instances of an object type will go
> through such-and-such a Storage_Pool".
>
> -- Adam
Agree.
The only thing that I can see it useful is some sort of Lock object
attached to the mutex (or like). Allocating this object dynamically,
will mean that a user has no concept of what this object suppose to do
therefore not knowing what he/she is doing.
George.
|
