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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6c424a2d310d290 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Ada Generic Library (very) preliminary release Date: 1997/07/13 Message-ID: #1/1 X-Deja-AN: 256643740 References: <33C39534.E8DAC63D@elca-matrix.ch> Newsgroups: comp.lang.ada Date: 1997-07-13T00:00:00+00:00 List-Id: On Sun, 13 Jul 1997, Matthew Heaney wrote: > In article , > Brian Rogoff wrote: > >Deliberate choice. STL uses no dynamic dispatch, and strives for the > >efficiency of "hand coded C". While it may not be there, automatic > >finalization of components won't help the Ada version. > > There may be confusion here: in Ada 95, there is no dynamic dispatch unless > it's on a class-wide object. There is only a small space-penalty, to store > the tag. I am aware of the "dispatch at call site" nature of Ada 95 OO. But the STL is an emphatically non-OO library, and I have decided to explore that design space, rather than using an OO approach. > Be very careful about using the STL - written in C++, using all the idioms > of that language - as a model for an Ada 95 component library. Based on a library developed in Ada 83, based on one in Scheme, ... No, that argument doesn't work. What I like about STL is not C++ specific, and though there are some things about C++ that make the expression of this library cleaner (gasp!), for example the ability to interleave public and private parts of a class, there are lots of things that allow the Ada version to be cleaner. STL is based on an analysis of the underlying structure of many algorithms, and is more rooted in algebraic specification than in BS-oriented, er, object-oriented programming. :-) It pretty much pushes the "cursor" type iterator design as far as possible. Yes, there are higher level ways to do iteration (Sather style iters, Icon style goal directed evaluation, ...) but the STL approach makes sense for an Ada 95 collection component library. STL is not just a collection of language dependent idioms. If you want to argue against it, you should at least have an understanding of it! > It would be true, however, that if Root_Stack derived (either publicly or > privately) from Finalization.Controlled, then there would be a small > penalty to call Initialize, Finalize, and Adjust, a penalty that need not > be incured by bounded forms (ie, implemented as an array). How small is this "small penalty"? I guess what you and I should do is measure the overhead of the suggested approaches, if efficiency were the overriding concern (it isn't, but I'm still intrereseted). > To get maximum efficiency (and to not give those programmers with > "optimitis" the excuse not to use the library), the library designer might > very well decide to not inherit from controlled at the root, and to > implement an unbounded form (say) by extending the uncontrolled parent with > a component that is controlled. This localizes the "inefficiency" of > controlled type usage to only those branches where it is strictly required. This is what I am suggesting for all of the AGL components. If you want safe versions "roll your own" from AGL. I'll probably provide safe versions "pre-wrapped", but it isn't a high priority with me now. (The high priority is finding a better way around the interleaving omission I mention above, since it forces too much to be public, as Mats Weber pointed out. I know this, but I am uncertain as to what to do. One solution might be to just break up the iterator child package into two or more, and use with clauses to "order" the elaboration of the children). -- Brian