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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-08 11:08:04 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: adam@irvine.com (Adam Beneschan) Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding Date: 8 Mar 2004 11:08:04 -0800 Organization: http://groups.google.com Message-ID: References: <5f59677c.0403021101.4ac263d0@posting.google.com> <5f59677c.0403060718.3d6aa909@posting.google.com> NNTP-Posting-Host: 66.126.103.122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1078772884 24180 127.0.0.1 (8 Mar 2004 19:08:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 8 Mar 2004 19:08:04 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:6162 Date: 2004-03-08T11:08:04-08:00 List-Id: Simon Wright wrote in message news:... > Marius Amado Alves writes: > > > It's very simple, really: you can only call concrete, and of course > > available, operations. > > > > In your program you had an abstract (not concrete) Generate (for a > > 'root' type), and a concrete, but not available Generate (for a > > derived type). The concrete Generate was not available (at the point > > of the call) because it was declared in the private part of a > > separate unit. So the first was available but was not concrete, the > > second was not available, GNAT went for the only available one, and > > naturally failed, mumbling whatever GNAT mumbles when it tries to > > call an abstract operation. > > I'm sure this explanation isn't right. The pointer concerned is to a > classwide type, and the contract says that any actual Element_Record > has a concrete (callable) Generate operation. > > It would be easy to construct a program where Main had access to an > Element (the classwide pointer) but not to Generator.Declarations > (where the concrete type is defined). > > I agree that putting it in the private part is perhaps misleading, but > that doesn't mean it's wrong -- we need a lawyer! Putting it in the private part doesn't matter, since a dispatching call can still reach it (3.9.2(20), 7.6.1(3)). In this case, the abstract Generate that Type_Decl_Record inherits is overridden with a nonabstract version (in the private part of Generator.Declarations); this nonabstract version is then inherited by Discrete_Type_Decl_Record, and later by Enumerate_Type_Decl_Record. This last inherited subprogram is the one that should be called when a dispatching call is made to Generate on an object of type Enumerate_Type_Decl_Record. In fact, I think the whole discussion about abstract vs. concrete subprograms is barking up the wrong tree. As far as I know, there should never be a runtime error for an attempt to call an abstract subprogram. The language rules ensure that this can never happen, i.e. that whenever you call a subprogram (either directly or via dispatching), that subprogram will be concrete (as opposed to C++, which I believe does not guarantee this). This is accomplished by disallowing objects of an abstract type and direct calls to an abstract subprogram, and, most importantly, by disallowing primitive abstract subprograms of a nonabstract tagged type, and by requiring that abstract subprograms be overridden when a derived type is nonabstract. I would expect the "access check" error to refer to an accessibility level problem (although I can't speak to what other errors might cause GNAT to say "access check"). Since all the access types in this code are library level (none is declared inside a subprogram), it does seem quite weird that this error would be showing up. -- Adam