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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ce0900b60ca3f616
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-11-09 09:53:36 PST
Newsgroups: comp.lang.ada
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.64.68.27!newsgate.cistron.nl!news-feed.nld.sonera.net!cleanfeed.casema.net!leda.casema.net!news2.euro.net!uunet!ash.uu.net!xyzzy!nntp
From: Jeffrey Carter <jeffrey.carter@boeing.com>
Subject: Re: Better control of assignment
X-Nntp-Posting-Host: e246420.msc.az.boeing.com
Content-Type: text/plain; charset=us-ascii
Message-ID: <3BEC12BA.E72A81EC@boeing.com>
Sender: nntp@news.boeing.com (Boeing NNTP News Access)
Content-Transfer-Encoding: 7bit
Organization: The Boeing Company
X-Accept-Language: en
References: <kPoE7.9567$xS6.13287@www.newsranger.com>
 <9rti6v$hcu$1@news.huji.ac.il> <WOzE7.10186$xS6.14012@www.newsranger.com>
 <9sdnb2$dd4$1@news.huji.ac.il> <9seup3$12h0ar$2@ID-25716.news.dfncis.de>
Mime-Version: 1.0
Date: Fri, 9 Nov 2001 17:30:34 GMT
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD Boeing Kit  (WinNT; U)
Xref: archiver1.google.com comp.lang.ada:16149
Date: 2001-11-09T17:30:34+00:00
List-Id: <comp.lang.ada>

Nick Roberts wrote:
> 
> However, it seems feasible to me to introduce a new finalisation mechanism
> in the next revision. All we really need (am I wrong?) is three attributes,
> applying to any type T, which are the procedures carried out whenever an
> object of the type is created, copied, and destroyed:
> 
>    procedure T'Construct (Object: in out T);
>    procedure T'Destroy (Object: in out T);
>    procedure T'Assign (Source, Target: in out T);

Assignment should not be able to modify the RHS, especially as it may be
an expression, not a variable.

> 
> These attributes would, naturally, have implementation-supplied defaults,
> but could be overidden by attribute definition clauses, as normal.

I was thinking recently of how to provide a different implementation of
Ada.Strings.Unbounded, and came to the conclusion that the current
controlled-type handling of user-defined assignment is not able to
handle the concept I had in mind. Of course, I might be wrong about
this, and would be happy if I am.

The basic idea is to define an Unbounded_String as

Initial_Max_Length : constant := ...;

type Unbounded_String is [new Ada.Finalization.Controlled with] record
   Length : Natural := 0;
   Value  : String_Access := new String (1 .. Initial_Max_Length);
end record;

Finalization would free Value.

Then, given

LHS : Unbounded_String;
...
LHS := RHS;

where RHS is an expression of type Unbounded_String, would operate along
the lines of

LHS.Length := RHS.Length;

if LHS.Value'Length < RHS.Length then
   Free (LHS.Value);
   LHS.Value := new String (1 .. RHS.Value'Length);
end if;

LHS.Value (1 .. RHS.Length) := RHS.Value (1 .. RHS.Length);

The general idea is to exchange some space for the ability to avoid
deallocation and reallocation with every assignment, doing so only when
it is necessary.

Although I have used Unbounded_String as an example, this basic idea
would be useful for many user-defined types. It appears that controlled
types are unable to implement this, while the proposal above could. Of
course, such things are easy to propose but difficult to specify
completely, and the implementation burden may be unacceptable. The
implications of redefining assignment in C++ are extremely complex, and
we should avoid such complexity in Ada. On the other hand, this is a
very useful capability that we should consider including in Ada 0X.

One can implement this capability with a limited type and an Assign
procedure, but Unbounded_String may not be implemented that way.

-- 
Jeffrey Carter