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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:8e83:: with SMTP id q125mr13950177iod.9.1548540698796; Sat, 26 Jan 2019 14:11:38 -0800 (PST) X-Received: by 2002:a9d:2c22:: with SMTP id f31mr247695otb.4.1548540698494; Sat, 26 Jan 2019 14:11:38 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!k10no446906itk.0!news-out.google.com!v141ni512ita.0!nntp.google.com!q69no447769itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 26 Jan 2019 14:11:38 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.168.19.89; posting-account=O_NgcgoAAABs6pgCjroQBmOBL5ZZGPUc NNTP-Posting-Host: 85.168.19.89 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3283b915-72db-4a80-bda5-71ace3d80765@googlegroups.com> Subject: Re: class wide iterable (and indexable) From: George Shapovalov Injection-Date: Sat, 26 Jan 2019 22:11:38 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55384 Date: 2019-01-26T14:11:38-08:00 List-Id: Original poster here. I think I did it again - that is broke gnat again.=20 But first a small update: I have cleaned up and systematized the original c= ode somewhat and added the description. Plus I added the complete "demo" co= de of the basic mix-in situations. No proper description yet though. The ge= neral idea is to create a small depository of common composition situations= , to have some base tested code that can be expanded upon.. Two sample comp= ositions are implemented in the code already: the basic mix-ins and the "li= st interface" over which Ada.Containers.Vectors.Vector can be directly over= layed (among other implementations). The link to the project is here: https://github.com/gerr135/ada_composition (renamed from original ada_gems to avoid name clash with existing Ada Gems = by AdaCore). In trying to expand on that last example - the indexable/iterable and overl= ayable by existing type interface, I have stumbled upon a rather weird beha= vior of compiled code. The expansion deals with trying to tie a type hierar= chy to the hierarchy of list implementations - not to have a single generic= type at the top and children units using the same. Instead this code has a= generic interface at the top, and children take specific types implementin= g interface at the top. This works fine (with minimal code changes in the "= library" itself from the previous case) for the basic composition types (re= cord encapsulating wither array of ACV.Vector). But when I try to pass ACV.= Vector overlais directly over interface as a generic parameter, it seems th= e compiler gets confused. While passing the constructed Vector into the Lis= t object it raises run-time exception: raised PROGRAM_ERROR : adjust/finalize raised STORAGE_ERROR: System.Memory.= Alloc: heap exhausted which is rather weird in itself. What's more, a simple whitespace change - = splitting the line of code directly above into two (inserting line break be= tween two trivial TEXT_IO ops that are in the same line in the code) change= s that error into: raised PROGRAM_ERROR : adjust/finalize raised STORAGE_ERROR: stack overflow= or erroneous memory access The line of code in question is this: ld(i) :=3D Base_Interface'Class(set_idx_vector(i)); the setter runs fine (and identical setter for a differently composed versi= on of the base type completes fine *and* allows the constructed object to b= e passed), but attempt to assign the constructed object to the List contain= er blows up with that STORAGE_ERROR. Please note: only the last variant is = affected, that is List composition directly overlaying ACV.Vector over List= _Interface, *but not* a more common encapsulation having ACV.Vector a recor= d entry. Unfortunately. as before, I cannot post just a line or two of code that wou= ld reproduce the entire situation. Providing indexing and iteration for the= entire type hierarchy takes some code. Please see this specific link for t= he appropriate part: https://github.com/gerr135/ada_composition/tree/master/list_combo This *is* the minimal code that reproduces the situation as far as I can te= ll.. I cannot see why this specific variant would be "wrong" in some way - the o= veral interface is the same for all 3 variants. Plus that weird behavior (s= ensitivity to whitespace) makes me suspect some problem with gnat here. But= maybe I overlooked something. Any ideas are appreciated.=20 Thank you!