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!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder4.news.weretis.net!feeder2.ecngs.de!ecngs!feeder.ecngs.de!81.171.118.63.MISMATCH!peer03.fr7!news.highwinds-media.com!not-for-mail
X-Trace: 
 DXC=mcRO_CBWb7NXhJNS8bZ=_GKkhVEZZCM;HUR1mKPXm[BJ^klT<Ho]glCkQTj;55J6@NiXFGkOO@VcMfZEAdbJ2;hE^Y4U3B7ITnMT?GFdX_VfmM
X-Complaints-To: abuse@usenet.se
Date: Tue, 25 Aug 2015 07:32:12 +0200
From: Per Sandberg <per.s.sandberg@bahnhof.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: How do typical Ada calling conventions work ?
References: <2a592336-034f-4483-9aed-b5a1d997f902@googlegroups.com>
 <mr6v7s$ouc$1@speranza.aioe.org> <d3oku8Fj86tU1@mid.individual.net>
 <2541f7b7-b728-421b-96cf-e0d656e984a2@googlegroups.com>
 <mrg4cb$qnh$1@loke.gir.dk>
In-Reply-To: <mrg4cb$qnh$1@loke.gir.dk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <55dbfddd$0$20676$862e30e2@ngroups.net>
NNTP-Posting-Host: e996a110.ngroups.net
X-Received-Bytes: 2779
X-Received-Body-CRC: 2854457179
Xref: news.eternal-september.org comp.lang.ada:27601
Date: 2015-08-25T07:32:12+02:00
List-Id: <comp.lang.ada>



Den 2015-08-25 00:03, Randy Brukardt skrev:
> "Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message
> news:2541f7b7-b728-421b-96cf-e0d656e984a2@googlegroups.com...
> ...
>> Thanks for your answers ! These are some pretty nice ways to do it instead
>> indeed.
>>
>> I'm glad the secondary stack approach won in the end for GNAT, it sounds
>> more
>> efficient, clean and scalable than what they were attempting in the
>> beginning.
>
> I doubt that. The scheme Janus/Ada uses is much simpler: the memory is
> allocated off of a special storage pool and it is then freed using the same
> mechanism that does other finalization (indeed, the memory management [which
> we used in Ada 83] was repurposed to do finalization, rather than the other
> way around).
>
> This is probably not as efficient as the secondary stack approach, but I
> find that irrelevant in 99.9% of programs. All functions that return
> non-elementary types are somewhat more expensive than the similar parameter
> passing, so if efficiency is a primary concern, one must use procedures
> rather than functions. The cases where function return by secondary stack
> would be efficient enough but function return by heap is not efficient
> enough are going to be quite rare [in the vast majority of cases either both
> are good enough or neither are] -- thus there are better things to spend
> effort on.
>
>                                                      Randy.
>
>
If you want to use a function "returning" large or limited objects you 
could always use the "extended return" where the returned object will be 
created in place.

type large_or_limited is ....;
function my_function return large_or_limited is
begin
    return ret : large_or_limited do
       do_what_you_need;
    end return;
end my_function;

/Per