Prohibiting dynamic allocation for the given type

Prohibiting dynamic allocation for the given type

[Maciej Sobczak]

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. I want to prohibit users from dynamically allocating
instances of this type so that they don't get into troubles.
Preferably at compile-time.

My understanding is that it cannot be done (allocation is not
considered to be a type's operation and there is no way to "hide" it
from users - as is possible in C++), but I would like to have it
confirmed.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[gpriv]

On Mar 18, 5:30 pm, Maciej Sobczak <see.my.homep...@gmail.com> 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.

G.

>
> My understanding is that it cannot be done (allocation is not
> considered to be a type's operation and there is no way to "hide" it
> from users - as is possible in C++), but I would like to have it
> confirmed.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[Maciej Sobczak]

On 19 Mar, 04:06, gp...@axonx.com wrote:

> Ada is high level language

That does not matter.
Ada is a high level language, but still provides two ways to create an
object:

X : Type;
Y : Type_Ptr := new Type;

If these two methods are available, then apparently there is a
difference between them and this difference is not in *where* objects
are created, but *how long* they are allowed to live.

The high-level part of Ada can hide the "where" part, but not "how
long".

For some types I might want to prohibit one of these two ways of
object creation.

Prohibiting the first one is easy with limited types that have unknown
discriminants + factory functions that return pointers.

Prohibiting the second one seems to be impossible.
For me this is a limitation.

> What's wrong with good old comments atop of type declaration.

What's wrong with C with good comments? :-)

> But if you insist you may do run-time check by
> defining custom Storage_Pool pool for your object

Storage_Pool is a property of the pointer, not the type.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[Georg Bauhaus]

Maciej Sobczak schrieb:
> On 19 Mar, 04:06, gp...@axonx.com wrote:
> 
>> Ada is high level language
> 
> That does not matter.
> Ada is a high level language, but still provides two ways to create an
> object:
> 
> X : Type;
> Y : Type_Ptr := new Type;
> 
> If these two methods are available, then apparently there is a
> difference between them and this difference is not in *where* objects
> are created, but *how long* they are allowed to live.
> 
> The high-level part of Ada can hide the "where" part, but not "how
> long".

With Ada 2005, you can try types derived in nested
scopes. No objects of a more deeply nested type can
leave these scopes (pointers to parent'class cannot be
used as an escape).

Re: Prohibiting dynamic allocation for the given type

[gpriv]

On Mar 19, 4:24 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 19 Mar, 04:06, gp...@axonx.com wrote:
>
> > Ada is high level language
>
> That does not matter.
> Ada is a high level language, but still provides two ways to create an
> object:
>
> X : Type;
> Y : Type_Ptr := new Type;
>
> If these two methods are available, then apparently there is a
> difference between them and this difference is not in *where* objects
> are created, but *how long* they are allowed to live.
>
> The high-level part of Ada can hide the "where" part, but not "how
> long".
>
> For some types I might want to prohibit one of these two ways of
> object creation.
>
> Prohibiting the first one is easy with limited types that have unknown
> discriminants + factory functions that return pointers.
>
> Prohibiting the second one seems to be impossible.
> For me this is a limitation.
>
> > What's wrong with good old comments atop of type declaration.
>
> What's wrong with C with good comments? :-)

Nothing..

>
> > But if you insist you may do run-time check by
> > defining custom Storage_Pool pool for your object
>
> Storage_Pool is a property of the pointer, not the type.

Are you asking for solutions or simply trolling?

>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[Maciej Sobczak]

On 19 Mar, 14:13, gp...@axonx.com wrote:

> > Storage_Pool is a property of the pointer, not the type.
>
> Are you asking for solutions or simply trolling?

I'm discussing things in public to ensure that I have a good
understanding of various language features and corners.
This is simply necessary to actually use the language in a responsible
way.

Building technical confidence and trolling are different things.

BTW - After seeing your responses and thinking more about the problem
itself I think that documenting the expected usage patterns gives
better results when compared to required effort - especially if the
solution would complicate the intended usage pattern as well.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[Eric Hughes]

On Mar 19, 2:24 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> X : Type;
> Y : Type_Ptr := new Type;
[...]
> For some types I might want to prohibit one of these two ways of
> object creation.

You can't prohibit the object creation itself, but you can make such
an object useless.

> If these two methods are available, then apparently there is a
> difference between them and this difference is not in *where* objects
> are created, but *how long* they are allowed to live.

If you want to control lifetime, you can control either the allocation
lifetime or the functional lifetime; the second is a subset of the
first.  As you've pointed out, you don't get a lot of control over
allocation lifetime.  But functional lifetime you can control.  Here's
how I would approach it.

First, make the utility of your type depend for its function on the
existence of some other object.  This likely goes into a constructor
function, but need not.  Your type would contain some kind of a weak
accessor, one that doesn't enforce the existence of its referent.
Gate all utility upon the existence of this referent.  If the referent
is absent, do nothing or throw an exception, whatever.  This check is
cheap; it's that some access value is not null.  Use finalization in
the referent to update the accessor value in your type.  This gives
you a dependency between objects, regardless of how the referent
object is allocated.

Second, when instantiating the object, make it refer to a sentry
object with block scope.  When the sentry object goes out of scope,
your original object will stop working.  I frequently use nested
declare/begin/end blocks within subprogram definitions to trigger
sentry finalization.

You'll still have to document that if you want scope lifetime for your
object's utility, you'll have to make it dependent upon a scoped
variable.  But at that point the code explicitly captures an intention
for scope lifetime.

Eric

Re: Prohibiting dynamic allocation for the given type

[Robert A Duff]

Eric Hughes <eric.eh9@gmail.com> writes:

> If you want to control lifetime, you can control either the allocation
> lifetime or the functional lifetime; the second is a subset of the
> first.  As you've pointed out, you don't get a lot of control over
> allocation lifetime.  But functional lifetime you can control.  Here's
> how I would approach it.
>
> First, make the utility of your type depend for its function on the
> existence of some other object.  This likely goes into a constructor
> function, but need not.  Your type would contain some kind of a weak
> accessor, one that doesn't enforce the existence of its referent.
> Gate all utility upon the existence of this referent.  If the referent
> is absent, do nothing or throw an exception, whatever.  This check is
> cheap; it's that some access value is not null.  Use finalization in
> the referent to update the accessor value in your type.  This gives
> you a dependency between objects, regardless of how the referent
> object is allocated.
>
> Second, when instantiating the object, make it refer to a sentry
> object with block scope.  When the sentry object goes out of scope,
> your original object will stop working.  I frequently use nested
> declare/begin/end blocks within subprogram definitions to trigger
> sentry finalization.
>
> You'll still have to document that if you want scope lifetime for your
> object's utility, you'll have to make it dependent upon a scoped
> variable.  But at that point the code explicitly captures an intention
> for scope lifetime.

I don't understand this method.  Maybe you could give an outline of the
code.  In particular, how do you ensure that the "sentry" is not
heap-allocated?  If you trust the client on that, then why not trust
the client to avoid heap allocation for the "real" object in the
first place?  I must be missing something...

- Bob

Re: Prohibiting dynamic allocation for the given type

[Eric Hughes]

On Mar 19, 6:48 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Maybe you could give an outline of the code.

I'll presume the as-yet-unpublished Strong_Access and Weak_Access
(that's what I'm working on now) (think: like Boost shared_ptr and
weak_ptr).  Here's a bare outline.

type X is null record ;  -- nonce type
package Smart_Access_to_X is new Smart_Access( X ) ;
use Smart_Access_to_X ;
-- type Object is contingent upon one of its components for some or
all of its functionality
type Object is record
   Lifetime : Weak_Access ;
   -- ...
end record ;
...
procedure Operation( Obj : in out Object )
is begin
   if ( Is_Null( Obj.Lifetime ) ) then return ; end if ;
   -- Assert Lifetime referent continues to exist
   -- ...
end ;
...
procedure Foo
is
   Bar : Object_Access := new Object'( Lifetime =>
Null_Weak_Access ) ;
   -- Bar does not work, can't make it do anything.
begin
   declare
      Sentry : Strong_Access := Construct_Strong_Access( Access_Value
=> new X ) ;
   begin
      Bar.all := Object'( Lifetime =>
Copy_As_Weak_Access( Strong_Accessor => Sentry ) ) ;
      -- Bar now works
   end
   -- Sentry is now out of scope; referent implicitly deallocated;
weak reference to it is null; Bar has stopped working
end

> In particular, how do you ensure that the "sentry" is not heap-allocated?

As I said in my original post, if you want scope lifetime, you need to
instantiate a scope dependency.  This technique does not enforce any
particular lifetime policy.

> If you trust the client on that, then why not trust
> the client to avoid heap allocation for the "real" object in the
> first place?

The distinction here is that the original object still exists.  Access
values to it will remain valid.  Depending on how the object is used,
it might be necessary to have that.  Personally, I can't imagine how
this might be useful unless two or more tasks are at issue, say,
passing a 'not null access all' parameter to a subprogram that assumes
continued existence of the referent of its parameter.  Since the
dependency mechanism is generic, it would be just as possible to make
the functional lifetime of a variable have the scope of some task.

The original question was somewhat theoretical, as is this answer.

Eric

Re: Prohibiting dynamic allocation for the given type

[Georg Bauhaus]

Maciej Sobczak wrote:
> On 19 Mar, 04:06, gp...@axonx.com wrote:
> 
>> Ada is high level language
> 
> That does not matter.
> Ada is a high level language, but still provides two ways to create an
> object:
> 
> X : Type;
> Y : Type_Ptr := new Type;
> 
> If these two methods are available, then apparently there is a
> difference between them and this difference is not in *where* objects
> are created, but *how long* they are allowed to live.
> 
> The high-level part of Ada can hide the "where" part, but not "how
> long".

(Somehow a posting of today is only visible through Google,
but not via the news server, apologies if this a repeated
remark.)

Using Ada 2005, you can have some of the "how long" control.
Deriving in nested scopes will limit the objects to that
scope. This includes heap objects. For example, you cannot
use pointers to Parent'Class to refer to objects of inner
scope types.

package body News10 is

   use Ada;

   procedure Scope is
      type T is new Finalization.Controlled with null record;
      type T_Ptr is access all T;

      overriding
      procedure Finalize(Object: in out T) is
         -- just show what is going on
      begin
         Text_IO.Put_Line("Finalized");
      end Finalize;

      X: T_Ptr;
   begin
      Text_IO.Put_Line("Enter");
      X := new T;
      pragma Inspection_Point(X);
      Text_IO.Put_Line("Exit");
   end Scope;

end News10;

with News10;
procedure Test_News10 is
begin
   loop
      News10.Scope;
      delay 2.0;
   end loop;
end;

Re: Prohibiting dynamic allocation for the given type

[gpriv]

On Mar 19, 6:17 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> Maciej Sobczak wrote:
> > On 19 Mar, 04:06, gp...@axonx.com wrote:
>
> >> Ada is high level language
>
> > That does not matter.
> > Ada is a high level language, but still provides two ways to create an
> > object:
>
> > X : Type;
> > Y : Type_Ptr := new Type;
>
> > If these two methods are available, then apparently there is a
> > difference between them and this difference is not in *where* objects
> > are created, but *how long* they are allowed to live.
>
> > The high-level part of Ada can hide the "where" part, but not "how
> > long".
>
> (Somehow a posting of today is only visible through Google,
> but not via the news server, apologies if this a repeated
> remark.)
>
> Using Ada 2005, you can have some of the "how long" control.
> Deriving in nested scopes will limit the objects to that
> scope. This includes heap objects. For example, you cannot
> use pointers to Parent'Class to refer to objects of inner
> scope types.
>
> package body News10 is
>
>    use Ada;
>
>    procedure Scope is
>       type T is new Finalization.Controlled with null record;
>       type T_Ptr is access all T;
>
>       overriding
>       procedure Finalize(Object: in out T) is
>          -- just show what is going on
>       begin
>          Text_IO.Put_Line("Finalized");
>       end Finalize;
>
>       X: T_Ptr;
>    begin
>       Text_IO.Put_Line("Enter");
>       X := new T;
>       pragma Inspection_Point(X);
>       Text_IO.Put_Line("Exit");
>    end Scope;
>
> end News10;
>
> with News10;
> procedure Test_News10 is
> begin
>    loop
>       News10.Scope;
>       delay 2.0;
>    end loop;
> end;

In that case one has to derive the type from parent within the scope
of interest.  Does it really improve clarity? And what will prevent
others from using instances of parent class (unless it's abstract).
For the sake of argument let's consider example where data
transmission should be uninterrupted by competing threads:

         declare
            Lock : Lock_T (Io.Frame_Mutex);
         begin
            Io.Put_Line
              (':' &
               Trim (Device_Count'Image (Idx - 1), Both) &
               " frame bin " &
               Image_Size_T'Image (Frame (Frm).Size));
            Io.Write (Frame (Frm).Image);
            Io.Put_Line ("");
         end;

Lock is referenced only once and intent is pretty obvious. If one
would want to lock mutex for longer time the solution would be:

        Cmd.Frame_Mutex.Enter;
        ...
        Cmd.Frame_Mutex.Leave;


In  C++ one can privatize new/delete overrides to prevent object from
heap allocation.  However, it won't prevent some ignorant user from
statically allocating the object deadlocking for the lifetime of the
entire application.

It's all false sense of security IMHO.

George.

Re: Prohibiting dynamic allocation for the given type

[Maciej Sobczak]

On 19 Mar, 23:17, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:

> Using Ada 2005, you can have some of the "how long" control.
> Deriving in nested scopes will limit the objects to that
> scope.

Yes, but this assumes that the user of the type is also implementing
it - in the same scope.

I was considering the type implemented in the library and the
possibility to enforce some given lifetime pattern at the use site.
Deriving in nested scope requires to mix the responsibilities of
"provider" and "user" and this is not possible when "provider" is a
library.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Prohibiting dynamic allocation for the given type

[Adam Beneschan]

On Mar 18, 8:06 pm, gp...@axonx.com wrote:
> On Mar 18, 5:30 pm, Maciej Sobczak <see.my.homep...@gmail.com> 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

Re: Prohibiting dynamic allocation for the given type

[gpriv]

On Mar 19, 10:38 am, Adam Beneschan <a...@irvine.com> wrote:
> On Mar 18, 8:06 pm, gp...@axonx.com wrote:
>
>
>
> > On Mar 18, 5:30 pm, Maciej Sobczak <see.my.homep...@gmail.com> 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.

Re: Prohibiting dynamic allocation for the given type

[Pascal Obry]

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?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Prohibiting dynamic allocation for the given type

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

"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.

Re: Prohibiting dynamic allocation for the given type

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> 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.


  type P is access T;
  for P'Storage_Size use 0;
                ----

I think ..

Re: Prohibiting dynamic allocation for the given type

[Eric Hughes]

On Mar 20, 2:26 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
>   type P is access T;
>   for P'Storage_Size use 0;
>                 ----

ARM 13.11/18
> If Storage_Size is specified for an access type, then the Storage_Size of this pool is at least that requested [...]

Apparently the value of 0 is a minimum, not a maximum nor an exact
size.

Eric

Re: Prohibiting dynamic allocation for the given type

[Randy Brukardt]

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:5cd0d5f9-07b7-46ce-8aca-1d7273f0e164@i12g2000prf.googlegroups.com...
> On Mar 20, 2:26 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
> >   type P is access T;
> >   for P'Storage_Size use 0;
> >                 ----
>
> ARM 13.11/18
> > If Storage_Size is specified for an access type, then the Storage_Size
of this pool is at least that requested [...]
>
> Apparently the value of 0 is a minimum, not a maximum nor an exact
> size.

Zero is sort of special; allocators are illegal in that case, see
4.8(5.3/2). That was added by the Amendment so that Pure packages could have
access types but would be guaranteed not to have any allocators. (But it is
more generally useful than that.)

                  Randy.

Re: Prohibiting dynamic allocation for the given type

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Is it possible to "prohibit" dynamic allocation for the given type?

I don't know of any simple way to do that.

> Let's suppose that I have a type which instances make sense only on
> the stack.

Could you please give some examples of such a type?

Somebody mentioned a lock, which I find only half convincing.
Any others?

>... I want to prohibit users from dynamically allocating
> instances of this type so that they don't get into troubles.
> Preferably at compile-time.
>
> My understanding is that it cannot be done (allocation is not
> considered to be a type's operation and there is no way to "hide" it
> from users - as is possible in C++), but I would like to have it
> confirmed.

Well, you can prohibit clients from creating any objects at all
(heap or stack) by using (<>) discrims, and not exporting any
constructor functions.  But that's not what you asked for.

- Bob