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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,147f221051e5a63d
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!news.glorb.com!feeder.erje.net!news.osn.de!diablo1.news.osn.de!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 24 May 2008 21:39:32 +0200
From: Georg Bauhaus <see.reply.to@maps.futureapps.de>
Reply-To: rm.tsho+bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: memory management in Ada: tedious without GC?
References: 
 <4ddef8bf-b5b1-4d7e-b75b-386cd6c8402c@l17g2000pri.googlegroups.com>
 <9f2c2db4-d6c1-4cdf-884c-5cbc26ac7701@d1g2000hsg.googlegroups.com>
 <d94612cf-d2f1-49ce-a327-46653487dd99@l42g2000hsc.googlegroups.com>
 <1qxcw3pphdlek.1jgsfwb7atdmo.dlg@40tude.net>
 <wccskw8d332.fsf@shell01.TheWorld.com>
 <10j4zhb9ge8ea.156spz1dkc4vb$.dlg@40tude.net>
 <wccskw7isqn.fsf@shell01.TheWorld.com>
In-Reply-To: <wccskw7isqn.fsf@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <48386ef4$0$6611$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 24 May 2008 21:39:32 CEST
NNTP-Posting-Host: b81bd301.newsspool2.arcor-online.net
X-Trace: 
 DXC=InSMj>io1G6^8FBo0_81f>A9EHlD;3Yc24Fo<]lROoR18kF<OcfhCO;F8Vh=JL_3>;PCY\c7>ejV8Lg5Ug[ai9482=a3Xm2JYc7
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:332
Date: 2008-05-24T21:39:32+02:00
List-Id: <comp.lang.ada>

Robert A Duff wrote:
> I see zero advantage to allowing arbitrary order for
> the calls to Initialize and Finalize.  And one huge disadvantage -- if
> you depend on the order, either on purpose or by accident, you might get
> a bug introduced years later, when you switch compilers (or even
> compiler versions).  It will be very hard to detect and to fix that
> bug!

OTOH, defining finalization order just by referring to
the order of components in the source text seem the weakest
mode of expression.  It is also in the way of ordering
components in source text by grouping criteria unrelated
to finalization.

When finalization order is important, couldn't the language
enable the programmer to just state the order?

  for T'Finalization_Order use
    record
      Component_1;
      Component_3;
      select
         Component_4 or Component_5;
      end select;
      Component_6;
    end record;


The "or" would mean any order is fine.
Omitting a component would mean the compiler is free to choose
when to finalize.