From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:ac8:5fcf:0:b0:3b8:2a2:5d2a with SMTP id k15-20020ac85fcf000000b003b802a25d2amr391582qta.465.1674769979326; Thu, 26 Jan 2023 13:52:59 -0800 (PST) X-Received: by 2002:a05:6870:f696:b0:163:1578:4012 with SMTP id el22-20020a056870f69600b0016315784012mr883365oab.291.1674769979070; Thu, 26 Jan 2023 13:52:59 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Jan 2023 13:52:58 -0800 (PST) In-Reply-To: <9d25946b-99ab-433f-99db-14057ca9088fn@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=157.143.56.236; posting-account=Wbe3fAoAAAALa8UT9MWTy6mw2ahlRJms NNTP-Posting-Host: 157.143.56.236 References: <9c7cccd9-733f-49a8-b482-087ccb14b58dn@googlegroups.com> <9d25946b-99ab-433f-99db-14057ca9088fn@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7779be64-573c-4701-bc2b-3b83ee141f64n@googlegroups.com> Subject: Re: Real_Arrays on heap with overloaded operators and clean syntax From: Jim Paloander Injection-Date: Thu, 26 Jan 2023 21:52:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3798 Xref: reader01.eternal-september.org comp.lang.ada:64894 List-Id: > > Dear ADA lovers,=20 > > with stack allocation of Real_Vector ( 1 .. N ) when N >=3D 100,000 I g= et STACK_OVERFLOW ERROR while trying to check how fast operator overloading= is working for an expression > Leo's answer is responsive to the OP but seems to have gotten buried in a= n amazingly long discussion which I haven't read. This answer appeared here= years ago (was it you, Leo?) and I have used it ever since. If there needs= to be a long discussion maybe it could be about why this workaround is nec= essary. I will pull out Leo's answer from his post and put my version here:= =20 >=20 > type Real_Vector_Access is access Real_Vector;=20 > then=20 > x_Ptr : Real_Vector_Access :=3D new Real_Vector(0 .. N - 1);=20 > x : Real_Vector renames x_Ptr.all;=20 >=20 > That's all. All the overloaded operators work as though the vector was de= clared from the stack. If you have code which formerly used stack allocatio= n (of x, in this example), it will work without modification with this tric= k.=20 >=20 > Jerry Thank you Jerry, that's true, this trick does the job indeed. Thanks. But t= o be honest among us, it seems to me that the Real_Arrays library has been = implemented probably (note the probably) by people not targeting real world= engineering / industrial applications. Examples are Finite Volume solution= s of semiconductor device equations, or weather prediction problems. You ca= nnot expect to solve these on the stack and of course ADA containers are im= practical for such computations. Possibly a library as discussed above that= provides Real_Arrays functionality but memory allocation is done internall= y on the heap or even on the stack if the user chooses to do so to take adv= antage of fast stack access. But then the mechanism for changing the stack = allocation size transparently and easily should also be provided as simply = as setting the memory pool in an access type. Do you agree?=20 In the meantime, I am wondering whether or not a hybrid approach (stack/hea= p) would work provided such a mechanism to set the stack size is easy acces= sible as simply as a memory pool. The functionality would be during operato= r overloading we create fast stack allocated arrays to transfer the interme= diate results stored in temporary objects. So all the temporaries described= above would reside in the stack if this would translate to performance imp= rovement until a smarter approach is introduced similar to C++ expression t= emplates.