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-Thread: 103376,243dc2fb696a49cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Date: Mon, 4 Oct 2004 12:15:06 +0200 Message-ID: <1ob4dexep087b$.ul8fb1ebgeok.dlg@40tude.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de UiJWWDwV14AqLVyBD+14wQHcblB5zqugIrDInT/JkcSS7otCk= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:4650 Date: 2004-10-04T12:15:06+02:00 List-Id: On Sun, 3 Oct 2004 21:53:32 +0200, Robert Kawulak wrote: >>> std::for_each algorithm and the like... (especially useful with >>> boost::lambda) >> >> In Ada: >> >> for Index in A'Range loop >> ... >> end loop; >> >> Here the iterator type and its constraint are constructed out of the >> object. Feel the difference! > > The only case where Ada is less verbose than C++ ;-) But on the other > hand you cannot do this with a list, a map, a deque, It is because they are not arrays. But why an ordered list should not implement an array interface? In my view it should, making the above legal for lists. > 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; > For instance (using boost::lambda) print those elements: > > // Print elements [4, 9] in reverse order: > std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1); > > Feel the difference! ;-) I do! I hate implicit iterators, I prefer loops where possible. Especially, because exit conditions, nested iterations, exception handling become visible. [ Ranting: 40 years spent in developing readable, safe, well-structured language constructs, only to replace them with nested function calls a la Lisp? ] >>> I see your point. When designing containers in std library, its creators >>> had >>> two possibilities to choose from: >>> 1. Make all the containers polymorphic, >>> 2. Make all the containers use consequent naming of members and make all >>> the >>> algorithms templated. >>> They have choosen 2, because it's far more efficient (no virtual calls, >>> many >>> bindings resolved at compile time and even inlined) and far more >>> flexible. >> >> 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. 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. > So in this case runtime polymorphism doesn't seem to > me to be more flexible than the template solution... Formally it is more flexible and powerful. The problem is that OO languages like C++ and Ada are much too much concentrated on generics, which are a dead end IMO, instead of investing more efforts in better ADT. >> No you cannot, when you have to mix them. If your program needs both >> vector and string (to copy a part of one into another) then you have >> to parametrize it twice with two types. Now consider what happens if there >> are 100 different, yet related types? > > Nothing happens. ;-) 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". > 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]); ... } Technically, you have to factor vector<> out of vector, vector, etc. When you do, that will be the ARRAY. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de