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: Fri, 1 Oct 2004 10:58:10 +0200 Message-ID: <15fk5715wm38q.3ie9r3bq8yuz$.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de KXpNKukwXb4F4EPxzpOwiQNqspTGWf8goYugmfqDfgNccSPFk= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:4495 Date: 2004-10-01T10:58:10+02:00 List-Id: On Fri, 1 Oct 2004 00:06:34 +0200, Robert Kawulak wrote: >>>> An ability to index is just one of many array properties. The whole list >>>> is very large. >>> As well as the list of methods and operators and other members of >>> std::vector<>... What particular thing are you missing there? > >> Slices (subarrays), ranges (index subsets), > > std::slice_array<>, std::gslice_array<>, std::indirect_array<>, > std::mask_array<> (all used with std::valarray<>) > > The std::valarray<> class has more limitations on the held type than > std::vector<>, but it is designed to be very efficient for such operations. In Ada slices are ad-hoc anonymous types, it is how that should be. Because if you want to work with array slices in a subprogram, you definitely do not want to pass all necessary helper types down there. In Ada you just write A(10..I) and the job is done. In C++ there is no mechanism to get related types out of objects and other types (except pointers T* and references T&). [Yes you can get this in C++, I believe you, it is all Turing complete after all! (:-))] >> looping (automatic iterators), > > 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! >>> Why you think that it is necessary for the core >>> language to know what is an array and what isn't? In Ada, you can't use >>> anything else than built-in array exactly as an array. In C++ you can. >> You get me wrong. I do not argue in favor of built-in arrays. I argue for >> an ability to have abstract array interfaces either user-defined or >> built-in, no matter. C++ does not have them and its template mechanism >> does >> not help here (*). Ada has them built-in, but does not allow to implement >> an array by, say, a record type. > > 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. 2 is called statically polymorphic, while 1 is just polymorphic. Clearly 2 is a part of 1. Nothing prevents the compiler to remove dispatch if the target is statically known. > This is why C++ has no abstract interface. Instead, counterpart functions in > all the containers are named in a uniform way, and this is their > "interface", but in the terms of template metaprogramming. Right. Their fault is that these interfaces though exist, are anonymous and uncheckable. In Ada they are named and checkable. This is why C++'s template interfaces are untyped. Ada's generic interfaces are typed, but do not have any ADT. It is like FORTRAN-IV against Algol contest in 2004. (:-)) >> Can you use it *as* std::vector? No, they are two different >> *unrelated* types. Same as in Ada, where Unbounded_String can be used >> *like*, but not *as* String. > > But this is where the "template metaprogramming" stuff applies - you can't > use it directly as string, but you can make a template metafunction which in > turn can take vector or string or something else as its metaargument. > And in this metafunction you may use them in the same manner - this is what > I meant. 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? [To continue the analogy, I'am trying to convince a FORTRAN-IV programmer that there could be something beyond REAL*4 and REAL*8. (:-))] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de