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!news1.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: Thu, 7 Oct 2004 12:08:28 +0200 Message-ID: <1dzt37oj3dnah.bwalpmfvyxd3$.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> <1ob4dexep087b$.ul8fb1ebgeok.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de RMRsaM2kH/J1oQOk1Bnf9w6NM7F6j5bWXyoz18Ye/37zmR12k= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:4860 Date: 2004-10-07T12:08:28+02:00 List-Id: On Wed, 6 Oct 2004 19:20:29 +0200, Robert Kawulak wrote: >> 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). In my view, array is a container and container is an abstract array. Iterators should be introduced as index types, subdivided into ordered and unordered ones. For ordered index types you can have ranges. From index types you can build tuples, which depending on whether indices are ordered or not, should allow subranges, projections (diagonals etc). Upon tuples and element types one can build arrays. Subtyping of array types should allow constraining/deriving of both index and element types. >>>> 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. Yes, but differently to C++ in Ada that would cover almost 90% of all cases. The reason is that in Ada we routinely clone/derive predefined types: type Velocity is new Float; -- Clone type Velocity_Array is array ... of Velocity; If we do it anyway, then it costs nothing to add a clause requiring Velocity to implement, say, Comparable. Moreover, the predefined Float type should be Comparable anyway! >> 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' ;-) It is not different from the generic way. Your element should have some operations. In C++ it is checked upon inlining. In Ada it is checked upon instantiation. With my proposal it will be checked when you create a wrapper. The only difference is in the place and time. >>> 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. 1. Who and how guaranties that? 2. You cannot have a conform to the interface object without specifying its concrete type. The rest follows from that. >>> 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]); > ... > } Where is any difference? You still have to specify both class A and class B in the template parameter profile. Whereas the elements types are of little interest for Foo. The contract of Foo is: 1. Foo takes two arrays as parameters. 2.a Nothing is said whether indices or elements types are related. 2.c They are members of some type set 2.c.1 They have a common ancestor = the set is dynamically polymorphic 2.c.1.a One is a subtype of another 2.c.2 The set is generic = statically polymorphic ---- [ 2.c is equivalent, in my view, to requiring arrays to be from some set of types narrower than just ARRAY. If the language allows to specify ARRAY, then it will be also no problem to define its constrained subsets. ] 2.d They are same types With templates you can reasonable implement only 2.d. Of course, one could extend templates to support some sophisticated type pattern matching mechanism, add constraints on formal types etc. IMO, that would be wasting of time. I believe that inheritance is a much more clearer and safer way of defining type sets than loose parametrization. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de