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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7f1e0b399cd01cb0
X-Google-Attributes: gid103376,public
From: Tucker Taft <stt@averstar.com>
Subject: Re: Unreferenced lock variables
Date: 1999/04/16
Message-ID: <37179A21.82A1AF7@averstar.com>#1/1
X-Deja-AN: 467266221
Content-Transfer-Encoding: 7bit
Sender: news@inmet.camb.inmet.com (USENET news)
X-Nntp-Posting-Host: houdini.burl.averstar.com
References: <x7v4smnszvu.fsf@pogner.moho> <7ero31$n46$1@nnrp1.dejanews.com>
 <x7vk8viqsla.fsf@pogner.moho> <7esrmv$k1n$1@nnrp1.dejanews.com>
 <3713b417.22324981@news.pacbell.net> <7f57g5$rpq$1@nnrp1.dejanews.com>
 <371658a7.19974365@news.pacbell.net> <7f6ei7$tvl$1@nnrp1.dejanews.com>
 <3717869e.7448255@news.pacbell.net>
Content-Type: text/plain; charset=us-ascii
Organization: AverStar (formerly Intermetrics)  Burlington, MA  USA
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-04-16T00:00:00+00:00
List-Id: <comp.lang.ada>

Tom Moran wrote:
> 
> I found AI-00147, which as far as I can see gives no significant
> arguments *for* eliminating in the non-limited case, except "doing
> Initialization/Finalization is expensive".  It seems to that either
> the programmer intended the object to be declared, even though he
> doesn't use it, or it was a mistake on his part and a warning should
> be generated (as for unused Integer, Boolean, and other non-controlled
> types).  So possibly such a warning in the non-limited case would be
> reasonable, but simply assuming the programmer did not really intend
> to declare the controlled object, is hubris.
>   Or is there another AI that I missed?

Here is a motivating example:

    X : My_Controlled_Type;
  begin
    ...
    X := Y;
    ...
  end;

Presuming My_Controlled_Type has a user-defined Initialize,
Finalize, and Adjust, the sequence of implicit calls currently 
required is:
    Initialize(X);
     ...
    Finalize(X)
    <copy Y to X>
    Adjust(X)
    ...
    Finalize(X)

The goal is to eliminate the first Initialize/Finalize pair.
Doing this requires some care, because if an exception is raised
before the assignment of Y to X, you don't want X to be finalized
if it has never been initialized.

Perhaps one way to resolve the concern is to give the permission
to remove an Initialize/Finalize pair only if there is an assignment
(presumably with Adjust) to the object, essentially allowing
the creation of the object to be deferred until the first assignment,
thereby bypassing the need for any default initialization.

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA