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, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Calling inherited primitive operations in Ada Date: Fri, 2 Sep 2022 19:01:28 -0500 Organization: A noiseless patient Spider Message-ID: References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> <12cc33b1-2c39-4057-8a03-623064b06e8en@googlegroups.com> <672e9bc6-1e53-42cb-a339-9230ab949de9n@googlegroups.com> Injection-Date: Sat, 3 Sep 2022 00:01:29 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="540bec0664a3fed56c5bc4112da1ca1f"; logging-data="2818864"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FNcVR2jDaAhSrZghh1xBBdcLcHbqwAag=" Cancel-Lock: sha1:r7mg7xlJkTrVBGysy7tnfjwcQsA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-MSMail-Priority: Normal X-RFC2646: Format=Flowed; Original X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Xref: reader01.eternal-september.org comp.lang.ada:64278 List-Id: "amo...@unizar.es" wrote in message news:672e9bc6-1e53-42cb-a339-9230ab949de9n@googlegroups.com... On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote: > On 2022-09-01 20:54, Emmanuel Briot wrote: >> As presented, this seems very over complicated. Elements and >> Definite_Elements >> add no value, and this is just a complex way of writing >Going in a tangent, and I guess you know perfectly well, but this is caused >by the >painful duplication of code that Ada pushes you to by not having a native >way to >abstract storage of definite vs indefinite types. This is premature optimization at it's worst. > So the provider of a generic library very soon faces this conundrum about > duplicating most interfaces, if not implementations, or resort to > non-trivial > generics, or accept an unnecessary penalty for definite types, or push to > the client the definite storage matter. There is no penalty in a code sharing implementation like Janus/Ada: the implementation of definite types is essentially the same as you would write by hand for an indefinite type. In most cases, all one needs is an indefinite generic. (The plan for Janus/Ada was always to use post-compilation optimization to reduce the overhead of generics, but admittedly, that part never got built. If I had infinite time...) Assuming otherwise is certainly premature optimization. > There's simply no satisfying solution here [that I know of]. The > duplication of > every standard container to have both [in]definite variants is a strong > indictment. The original expectation for the containers was that there would be many variants of each container, because the needs for memory management, task management, and persistence differ between applications: there is no one-size fits all solution. But I agree on one point: the "basic" container is unncessary; one should either use the indefinite or bounded container (depending on your memory management needs, either fully fixed or fully heap-based) -- stopping in the middle makes little sense. Randy.