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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,669a0df36b2c7d06 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-15 14:21:37 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: coding 'Output Date: Tue, 15 Jul 2003 22:23:24 +0100 Message-ID: References: NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) X-Trace: news.uni-berlin.de 1058304096 10380750 82.43.33.75 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:40305 Date: 2003-07-15T22:23:24+01:00 List-Id: wrote in message news:ZCGQa.54287$sY2.26024@rwcrnsc51.ops.asp.att.net... > > > would require slice assignments to/from Data > > > and Data is typically large, so that's not a good > > > solution. > > Why is this (putting the array and other info into > > a record type) not a good solution? What have > > large slices got to do with it? > Because it's often necessary to pass large slices > and time is important. eg, given > Data : X(1 .. 50_000); > I can call > Process_Middle(Rate, X(15_000 .. 35_000)); > passing nothing just a pointer and bounds. But if > Rate and Data are part of a record, I'd have to > pass > Process_Middle(X_Record'(Rate, X(15_000 .. 35_000))); > which I believe would require building a temporary object > and copying 20K elements of X. Well I see your point now, but by golly there are many possible solutions! ---------- Solution 1 Declare the relevant procedures so that they take the array and other information as separate parameters. E.g.: procedure Process_Middle (Rate: in ...; Data: in Data_Array); This does not prevent the array and other information being otherwise kept in a record. A call using the data in a record named Trial_1, say, might look like: Process_Middle( Trial_1.Rate, Trial_1.Data(15_000..35_000) ); ---------- Solution 2 Keep a pointer to the array in a record which contains the other (small) information. E.g.: type Data_Ref is access all Data_Array; type Sample_Descriptor is record Data: Data_Ref; Rate: ...; end record; procedure Process_Middle (Sample: in Sample_Descriptor); A call to this procedure might then look like: Process_Middle( (Trial_1.Rate, Trial_1.Data(15_000..35_000)'Access) ); Note that in this case the constructed temporary record is small. The array referenced by Trial_1.Data must be aliased (in many cases it will be preferable to create it by an allocator). ---------- Solution 3 Pass the slice bounds into the relevant procedures. E.g.: subtype Sample_Index is Natural; type Data_Array is array (Sample_Index range <>) of Sample_Value; type Sample_Set (Last: Sample_Index) is record Data: Data_Array(0..Last); Rate: ...; end record; procedure Process_Middle (Data: in Sample_Set; First, Last: in Sample_Index); A call to this procedure might look like: Process_Middle(Trial_1,15_000,35_000); ---------- I'm sure there are many other possible approaches, probably some more elegant than these. What you really require will depend on your particular application, and your own preferences. If you are still stumped, and are prepared to give more a detailed outline of your problem, I'd be happy to make more precise suggestions. Best of luck. -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]