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,1bad3dcf22d5a071 X-Google-Attributes: gid103376,public From: Martin Dowie Subject: Re: Generics and parameter modes Date: 1999/08/21 Message-ID: <37BE694D.46B883BA@dowie-cs.demon.co.uk>#1/1 X-Deja-AN: 515430589 Content-Transfer-Encoding: 7bit X-NNTP-Posting-Host: dowie-cs.demon.co.uk:193.237.34.207 References: <37B85F88.C87638C4@dowie-cs.demon.co.uk> <37B991F7.79D30959@averstar.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 935225650 nnrp-13:24003 NO-IDENT dowie-cs.demon.co.uk:193.237.34.207 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-08-21T00:00:00+00:00 List-Id: well, if this helps, i've now discovered that the object being passed was a component of a record, but if i do a rename of that component use that in the call, it changes to a by-reference! what do you suspect now?! (thanks for your help & matthew!) Tucker Taft wrote: > Martin Dowie wrote: > > > > i have an instance of a package similar to the generic listed below. > > when calling the 'size' routine the actual parameter is passed by copy > > and not by reference as i had expected. this is really annoying as the > > data object is a few hundred kbytes in size! is there anything in Ada95 > > that allows/requires this? > > Non-limited, non-tagged record types may be passed either by reference > or by copy. On the other hand, I am quite surprised that a compiler > would go out of its way to pass such a large object by copy, since it > requires more work. The only reasons I can imagine for doing this are: > > 1) the compiler is trying to enable more generic code sharing > (but that seems a bit far-fetched, since even in a shared > generic it "knows" a_list is a record type); > 2) there is some kind of alignment problem, where the actual parameter > is not properly aligned for the code inside the generic (again > a bit far-fetched); > 3) the actual parameter is marked volatile or atomic (see RM95 C.6(19)); > 4) convention C_Pass_By_Copy applies to the type (I don't see such > a pragma below); > 5) the compiler has a bug ;-). > > Are you really sure that it is passing the parameter by copy? I would > contact Rational and file a lousy-code-quality-but-not-quite-a-bug report. > > > generic > > type an_item is private; > > maximum_number_of_items : positive; > > package generic_list is > > subtype a_number_of_items is natural range 0 .. > > maximum_number_of_items; > > subtype an_item_index is natural range 1 .. maximum_number_of_items; > > > > type a_list is private; > > -- Lots of other stuff... > > function size (list : in a_list) return a_number_of_items; > > private > > type an_array_of_items is array (an_item_index) of an_item; > > type a_list is record > > current_size, current_item : a_number_of_items; > > items : an_array_of_items; > > end record; > > end generic_list; > > > > the type used in the declaration is a variant record which it self > > contains variant fields within a number of the variant branches (approx. > > 300 bytes storage required). > > > > i'm using Rational Apex v3 and have tried a mini version at home (using > > the above) and ObjectAda seems to pass it by reference (not 100% on this > > as my Intel assembler knowledge is zilch!). > > ObjectAda would pass such an object by reference unless the actual > were misaligned (maladjusted? ;-), marked atomic or volatile, or had > a C_Pass_By_Copy convention. > > -- > -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