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=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:ac8:44b7:0:b0:3b6:2bb2:216c with SMTP id a23-20020ac844b7000000b003b62bb2216cmr863457qto.616.1674427370790; Sun, 22 Jan 2023 14:42:50 -0800 (PST) X-Received: by 2002:a9d:6f09:0:b0:672:6b44:379c with SMTP id n9-20020a9d6f09000000b006726b44379cmr1322365otq.169.1674427370529; Sun, 22 Jan 2023 14:42:50 -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: Sun, 22 Jan 2023 14:42:50 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=188.150.24.77; posting-account=HFCrOQoAAABZD_f-UUbYHm3lJDIrh-UX NNTP-Posting-Host: 188.150.24.77 References: <9c7cccd9-733f-49a8-b482-087ccb14b58dn@googlegroups.com> <3db6b678-5a45-4b4d-9f6c-e4933b04d6c2n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Real_Arrays on heap with overloaded operators and clean syntax From: Joakim Strandberg Injection-Date: Sun, 22 Jan 2023 22:42:50 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4581 Xref: reader01.eternal-september.org comp.lang.ada:64852 List-Id: s=C3=B6ndag 22 januari 2023 kl. 23:07:53 UTC+1 skrev dhmos.a...@gmail.com: > > > Dear ADA lovers,=20 > > > with stack allocation of Real_Vector ( 1 .. N ) when N >=3D 100,000 I= get STACK_OVERFLOW ERROR while trying to check how fast operator overloadi= ng is working for an expression=20 > > >=20 > > > X :=3D A + B + C + C + A + B, where=20 > > > A,B,C,X are all Real_Vector ( 1 .. N ).=20 > > >=20 > > > So my only option was to allocate on the heap using new. But then I l= ost the clean syntax=20 > > >=20 > > > X :=3D A + B + C + C + A + B=20 > > >=20 > > > and I had to write instead:=20 > > >=20 > > > X.all :=3D A.all + B.all + C.all + C.all + A.all + B.all.=20 > > >=20 > > > This is really ugly and annoying because when you are using Real_Arra= ys for implementing some linear algebra method who relies heavilly on matri= x vector products and vector updates, you do need to allocate on the heap (= sizes are determined in runtime) and you do need a clean syntax. So, is the= re any way to simplify my life without using the .all or even without decla= ring A,B,C,X as access Real_Vector?=20 > > > Thanks for your time!=20 > > Easiest solution is probably to declare a new task and specify the stac= k size using the Storage_Size aspect. Allocate as much stack space as you n= eed to be able to do the calculations and do all the allocations on the dec= lared task, not on the environment task. You will avoid the unnecessary hea= p allocations and have nice clean syntax.=20 > >=20 > > Best regards,=20 > > Joakim > Thank you for your reply,=20 > since I am a newbie I was under the impression that tasks are used only w= hen you want to write a parallel code that takes advantage of multicore arc= hitectures. You suggest I have a single task and single thread something li= ke this? I see, but there should be a way to do this also for the main prog= ram. But thanks anyway. Are you aware of any libraries similar to Real_Arra= ys, but who allocated memory internally using heap? This is the natural way= to do such things. Similarly to the Containers.Vector. But Vector has such= an awful syntax. There should be something like an indexer [i] similarly t= o the C++ std::vector to make things simpler and overloaded operators simil= arly to Real_Arrays. It is a no brainer. Most programs need to allocate on = the heap, why did they restrict Real_Arrays on the stack? It my impression that in the Ada community the preferred way of working is = in general stack only. Heap allocations are avoided for a number of reasons= for example performance, the application needs to ask the operating system= for memory which one doesn't know how much time that will take nor if it a= lways will succeed. In addition, applications that use the heap may be susc= eptible to heap memory fragmentation. In Ada, it is easy to specify stack s= izes when declaring tasks. It is not part of the Ada standard to specify st= ack size of the environment task. The Ada way is to declare new tasks and d= o work on them. Prefer the bounded containers over the unbounded containers= . If you really need to allocate objects I recommend using storage pools wi= th pre-allocated memory also known as arena pools.