From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Proposal: Auto-allocation of Indefinite Objects
Date: Sat, 4 Apr 2020 10:31:35 +0200
Organization: Aioe.org NNTP Server
Message-ID: <r69gl7$1ntr$1@gioia.aioe.org>
References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com>
NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader01.eternal-september.org comp.lang.ada:58312
Date: 2020-04-04T10:31:35+02:00
List-Id: <comp.lang.ada>

On 2020-04-04 00:48, Stephen Davies wrote:

> It is the 3rd reason that initially got me thinking about this.
> It seems excessive to have two versions of packages just because
> one version can say "Node.Item := New_Item;" but the other has to say
> "Node.Item_Ptr := new Element_Type'(New_Item);".

This is another issue, IMO. The language should support interface 
inheritance:

    type Node_Item_Inteface is ...;

    type Static_Node_Item is
       new Node_Item_Inteface with record ...

    type Dynamic_Node_Item is
       new Node_Item_Inteface with access Some_Implementation;

Implementation of an interface per access type.

> It's probably not a good idea for auto-allocation to be the default
> behaviour, so I suggest something like:
> 
>     type Node_Type is record
>        Item : new Element_Type;
>        Prev : Node_Ptr_Type;
>        Next : Node_Ptr_Type;
>     end record;
> 
> If Element_Type is a definite type in the instantiation then
> Node.Item will be a normal object of that type. Otherwise, it is
> implemented as a pointer but the code still treats it as an object.
> The target of the pointer is allocated on assignment of the object.
> The pointer cannot be copied to any other object. Assignments of the
> whole record will perform a deep-copy of the auto-allocated component.
> The target of the Node.Item pointer can be auto-deallocated when Node
> goes out of scope or is deallocated.
> 
> Ok, I've probably missed something obvious and have been wasting my
> time, but at least I've got plenty of time to waste at the moment.

This looks interesting to me. There is a huge number of cases I am using 
this schema, especially when Item is initialized once.

The major advantage is of course in having a plain String instead of 
Unbounded_String. No conversions, no space/time penalties. I refrain 
using Unbounded_String as much as possible.

Also there must be a possibility to specify the pool of Item. I 
frequently place things like Node_Type into an arena pool, soI want the 
string going there as well. Another case is marshaling such objects, so 
that the body of Item would not be left behind.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de