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-Thread: 103376,147f221051e5a63d
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!panix!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: memory management in Ada: tedious without GC?
Date: Sat, 24 May 2008 16:45:43 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wccwslja0so.fsf@shell01.TheWorld.com>
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>
 <48386ef4$0$6611$9b4e6d93@newsspool2.arcor-online.net>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls6.std.com 1211661943 24047 192.74.137.71 (24 May 2008 20:45:43
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Sat, 24 May 2008 20:45:43 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:E71HcnIGUNrkzVP8tINLBc1MXfk=
Xref: g2news1.google.com comp.lang.ada:333
Date: 2008-05-24T16:45:43-04:00
List-Id: <comp.lang.ada>

Georg Bauhaus <see.reply.to@maps.futureapps.de> writes:

> 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.

Well, when I write:

    procedure P (...) is
        This : ...;
        That : ...;
    begin
        ...
    end P;

This and That are initialized in order, and finalized in reverse order.
I don't find that strange.  So why shouldn't record components
be the same?

> 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;

It could, but it seems like a lot of mechanism.

Part of my point is that you might write a program that depends on
finalization order by accident.  You write the program, test it, and it
does what you want.  You don't want the order to change in the future,
but since it's by accident, you can't be expected to write
"for T'Fin_Order...".

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

I can't think of any advantage to allowing the compiler to choose the
order.

- Bob