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-Google-Thread: a07f3367d7,f428ff2031155951 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!g19g2000yqi.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Equivalent of dynamic_cast (downcast) for tagged types Date: Fri, 28 Jan 2011 07:13:03 -0800 (PST) Organization: http://groups.google.com Message-ID: <0dec16be-da2b-4b9e-afb8-285e8e6d8acb@g19g2000yqi.googlegroups.com> References: <375fb596-ab12-4cb0-a190-53d62b94b2e4@e9g2000vbi.googlegroups.com> <510d779c-d15b-4fc1-b831-bfc578ecdb4b@z3g2000prz.googlegroups.com> NNTP-Posting-Host: 137.138.182.236 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1296227583 14242 127.0.0.1 (28 Jan 2011 15:13:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 28 Jan 2011 15:13:03 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g19g2000yqi.googlegroups.com; posting-host=137.138.182.236; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:16770 Date: 2011-01-28T07:13:03-08:00 List-Id: On Jan 27, 11:35=A0pm, Maciej Sobczak wrote: > > Adjust is not called on limited objects. > > Yeah, sure. :-D [...] I have some more news on this. Previously my observations were that: > So, to summarise: yes, Adjust is randomly called on Controlled_Limited > types and it even dispatches properly (wow!), and no, my own > operations do not dispatch and instead something dummy gives me > equally dummy results. Interesting observation #2: my operation is the *third* primitive operation of Some_Interface. Interesting observation #3: Adjust is also the *third* primitive operation of System.Finalization_Root. Hm... I have changed the order of declarations in my spec file, so that the operation in question is now the *second* one. Guess what? :-) Now Finalize is called instead of Adjust. Yes, Finalize is the second primitive operation in System.Finalization_Root. It looks like the compiler has overwritten one virtual function table with another one and since the operations have very similar signatures, what happened is that the wrong operation was executed. If anybody from AdaCore is reading this, please take the above as a hint, I believe these observations are enough to show the proper direction. > But in addition to downcasting, there is an alternative solution which > I have discovered later on, although have not yet tested. > The idea is if I know the actual type (T) in the procedure that > accepts base interface, then apparently I'm working with a closed set > of types, which is actually true. So instead of relying on class-wide > types and dispatching in this particular place I will add another > version of the same operation that accepts T and operates on it. It works. I will stick to this solution instead of "if X in T then ..." as it is fully static instead of dynamic and it offers a better granularity for later editing - I will just remove that additional operation without touching the original one when the GNAT bug is fixed. Thanks to everybody who offered solution to my original problem. -- Maciej Sobczak * http://www.inspirel.com