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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: class wide iterable (and indexable) Date: Thu, 3 Jan 2019 16:56:04 -0600 Organization: JSA Research & Innovation Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> Injection-Date: Thu, 3 Jan 2019 22:56:07 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29996"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Original Xref: reader01.eternal-september.org comp.lang.ada:55184 Date: 2019-01-03T16:56:04-06:00 List-Id: "George Shapovalov" wrote in message news:2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com... ... >I did see in the Ada.Containers.Vectors code two versions defined, however >I was not >clear on why, especially since both the Ada Gem 10x (I forgot now exact >number) and >Ada Rationale for 2012 seem to only provide one, with a Cursor. Vectors support both indexing by an integer and reference via a cursor. Usually, the List container is a better example for cursor operations because it doesn't have the confusion of (direct) indexing involved. ... >On a related note, I was rather surprised that the related types in >Ada.Containers do not >form such a hierarchy. Say both Ada.Containers.Vectors and >Indefinite_Vectors (and >especially now with addition of Bounded_Vectors too) all could derive from >a common >ancestor that could be used to implement common functionality and let end >user chose >the desired data storage model.. Because that would substantially harm ease-of-use. You'd have to write multiple instantiations to create any container. It's annoying enough (to some, at least) to have to write one. Besides, interfaces are (nearly) useless (and especially so for this sort of usage, where some part has to be generic). They add a lot of runtime overhead that doesn't actually get used in real programs. For example, we did do what you suggest for the queue containers. Irrelevant thought: that's probably why I have yet to hear of anyone actually using one of them. :-) Back to the point: there's virtually no circumstance where you'd use more than one type of queue with any specific data type, so the generality buys essentially nothing. (The only real use is in generic units, but those could have been handled with formal packages just as well.) So you're paying a substantial price in code size and time, but no real gain. Perhaps if Ada allowed multiple controlling parameters of different tagged types, then there might be more use. But with the existing Ada rules, interfaces can only be useful if the profiles are fixed (non-generic) and are still reusable -- that doesn't happen that often. Randy.