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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Tell whether a primitive subprogram was overridden Date: Tue, 19 Aug 2014 09:31:43 +0200 Organization: cbb software GmbH Message-ID: <1nlld44wut4kf.1l1mtjf7durro.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: yj8+JIQUMOEawvIM7K49kA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:21822 Date: 2014-08-19T09:31:43+02:00 List-Id: On Tue, 19 Aug 2014 02:41:24 +0300, Victor Porton wrote: > Is it possible to determine whether for a given object of type T'Class a > primitive subprogram F was overridden (not the same as for type T)? It is always overridden even if inherited. Purely formally, since the type is different, e.g. S derived from T, then it cannot be the same subprogram. [Technically it can have some additional trampoline code as well.] > I would like this check for efficiency reasons, not to pass it to a callback > if the default "null" operation was not overridden. You mean that a check would be more efficient than a dispatching call? I don't think there would be much difference, except the case when the subprogram has a long list of additional arguments or computed arguments. That is usually the case when doing tracing stuff. In that case you could think of some lazy parameter evaluation schema or upfront checks as Adam suggested. You could also split the base type into two or more types adding the primitive operations up the derivation tree. At the call point you could check if the descendant is in the subclass that has the operation and call only if it is. But I think this, apart from being extremely ugly, might be in fact slower than a honest dispatching call. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de