Re: Prohibiting dynamic allocation for the given type

[gpriv@axonx.com]

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.