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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.100.13 with SMTP id y13mr708018icn.32.1385398437367; Mon, 25 Nov 2013 08:53:57 -0800 (PST) X-Received: by 10.182.78.103 with SMTP id a7mr273083obx.4.1385398437162; Mon, 25 Nov 2013 08:53:57 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i2no5554282qav.0!news-out.google.com!9ni3596qaf.0!nntp.google.com!i2no5554277qav.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 25 Nov 2013 08:53:56 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <299eb9f2-d5be-4fcd-a340-b4c28b28c1b8@googlegroups.com> Subject: Re: How To Pass Large Object Arguments From: adambeneschan@gmail.com Injection-Date: Mon, 25 Nov 2013 16:53:57 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:17784 Date: 2013-11-25T08:53:56-08:00 List-Id: On Saturday, November 23, 2013 11:20:53 PM UTC-8, FritzVonBraun wrote: > Hello all, >=20 >=20 >=20 > I am fairly new to Ada and I am wondering how I should pass large=20 > parameters to subprograms like arrays or records that contain other=20 > components like vectors or lists. >=20 > I did a lot of reading but wasnt able to find a definite answer. the=20 > general consensus I got from Barne's book and various blogs and=20 > whitepapers from Universities was that in theory IN parameters are=20 > copied but the compiler manufacturer is free to implement a reference to= =20 > the original object and so on. So basically what I found out there is no= =20 > concrete rule that says "parameter of that size or greater are passed by= =20 > reference internally" >=20 > So my question is, is there a de facto standard at least? What does Gnat= =20 > do in such cases? (In all honesty, my programs will never run on=20 > anything but Gnat, so other compilers don't really matter to me). I am=20 > considering passing objects that I think are too big for a copy=20 > operation through an access parameter, but that would basically=20 > contradict the principle of problem orientation instead of machine=20 > orientation. I would really rather be able to handle these situations=20 > without having to worry about the underlying mechanism myself. The RM has some rules about how certain types are to be passed. Elementary= types are always passed by copy; those are types that essentially aren't b= roken down into subcomponents, i.e. numbers, enumerations, access types. T= his is true even for IN OUT parameters; the value will be passed by copy, a= nd a new value will be copied back after the procedure or function returns.= Tagged types, tasks, protected types, other limited types, and any record= or array containing one of those, are always passed by reference. This is= true even for IN parameters. If the "vectors" or "lists" you're referring= to are types in one of the Ada.Containers packages, then they will be pass= ed by reference since Ada.Containers.Vectors.Vector is defined to be a tagg= ed type, and I think that's true for all the other containers. But for records and arrays that don't fall into one of those categories, it= 's up to the compiler. And the compiler's decision may depend on the targe= t processor. One of our compilers (for a particular RISC-ish target) would= pass any record up to four 32-bit words by copy, in registers. However, f= or a Pentium, which has very few registers, an implementation like this wou= ldn't make sense, and there's no point in copying a record to the stack if = it isn't required by the language. So for record and array types that aren't specified by the RM, you shouldn'= t worry about the parameter passing mechanism, and let the compiler decide = what it thinks the best way is. You should also write code in a way that a= ssumes either one or the other mechanism could be used. That is, if you ca= ll Foo(Param =3D> X) where X's type is some record type, and somewhere whil= e Foo is running, something happens that causes a field in X to be modified= , Foo itself may or may not notice that that field has changed if it access= es Param.Field. (And that's true even if X is passed by reference, since t= he compiler could generate code that "knows" Param.Field won't change, sinc= e it can't tell whether the actual record will change behind its back.) =20 -- Adam