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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,243dc2fb696a49cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.pionier.net.pl!news.nask.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mail From: "Robert Kawulak" Newsgroups: comp.lang.ada Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Date: Wed, 6 Oct 2004 19:20:29 +0200 Organization: tp.internet - http://www.tpi.pl/ Message-ID: References: <41547dae$0$91007$39cecf19@news.twtelecom.net> <1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net> <1hl2mizeb27ku$.1f0asrbmb05mi.dlg@40tude.net> <7siml3c62lev$.usczt2y2l19c$.dlg@40tude.net> <15fk5715wm38q.3ie9r3bq8yuz$.dlg@40tude.net> <1ob4dexep087b$.ul8fb1ebgeok.dlg@40tude.net> NNTP-Posting-Host: pt155.krakow.cvx.ppp.tpnet.pl X-Trace: atlantis.news.tpi.pl 1097083852 12124 217.99.216.155 (6 Oct 2004 17:30:52 GMT) X-Complaints-To: usenet@tpi.pl NNTP-Posting-Date: Wed, 6 Oct 2004 17:30:52 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:4813 Date: 2004-10-06T19:20:29+02:00 List-Id: Hi, > But why an ordered list should not > implement an array interface? In my view it should, making the above legal > for lists. I think this is a wrong way - list is not a kind of array to implement its interface. But both list and vector are *containers*, and they both have the common container interface - and that's why std::for_each and other std lib algorithms work on any conatiner (be it std::list, std::vector, C-style array or a user-defined type). >> nor you can do the following so concisely: >> >> std::vector V(10); >> >> // Apply SomeFunction to elements [4, 9] in reverse order: >> std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction); > > for Index in reverse V'First + 4..V'Last loop > SomeFunction (V (Index)); -- Better to place its body here, if short > end loop; Sorry, my mistake. :-P I didn't know about this... > [ Ranting: 40 years spent in developing readable, safe, well-structured > language constructs, only to replace them with nested function calls a la > Lisp? ] ;-) >>> Far less flexible you mean. >> >> C++ doesn't have a single-rooted object hierarchy. So if containers >> weren't templates, they'd have to contain elements of some abstract >> class, >> call it CElement. Now, if you want to have a container of elements of >> some >> class not derived from CElement or even a container of int, then you'd >> have >> to make some wrapper classes - this would cost you a lot of time to make >> it >> work with the library. > > Yes, unless: > > 1. (for new types) language supports multiple interface inheritance. C++ > does, Ada 2005 will. 'elements of some class -=#not#=- derived from CElement' - I meant if you can derive, then there's no problem. > 2. (for existing types) language supports supertyping. If it does, then > creating a wrapper will be a matter of one or two code lines. You create a > helper type which is both a subtype of CElement and a supertype of int. And you see, that's the point. I wrote: 'to make it work', and it's not as easy as it seems. In order to work with container algorithms and cooperate with other containers, your wrapper should also implement wrappers for wrapped type's iterators with wrappers for wrapped type's iterators' functions... Doesn't look to me like 'a matter of one or two code lines' ;-) >> If you have a function template copying elements of >> one container into another, then it'll work fine even for 100 container >> types, as long as they use the same interface. > > Which interface you mean? string is an instance of another template. It is > not vector<>, and there is no way to make it conform to vector<>, because > there is no such thing as "vector interface". *container* interface. String is not exactly a vector, but might be treated similarily to one because of it's container-like interface. >> Can you specify what do you mean when saying 'mix them'? > > All cases were: > > template Foo (vector & X, vector & Y) > { > ... > Do_Something (X [I], Y [J]); > ... > } > > cannot be replaced with: > > template Foo (vector & X, vector & Y) > { > ... > Do_Something (X [I], Y [J]); > ... > } Wouldn't this do? template Foo (A & X, B & Y) { ... Do_Something (X [I], Y [J]); ... } Regards, Robert