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, 11 Oct 2004 10:46:35 +0200 Message-ID: <1k2m0s9456ba7$.t0euzv9ux97l$.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> <1dzt37oj3dnah.bwalpmfvyxd3$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de d2Ug/xSKpGpXIln/QOnPGA7T5lmur9dRJimK3xM2Lna6nBMbw= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:5033 Date: 2004-10-11T10:46:35+02:00 List-Id: On Mon, 11 Oct 2004 00:21:06 +0200, Robert Kawulak wrote: >> In my view, array is a container and container is an abstract array. >> Iterators should be introduced as index types > > In my view it's not. Not every container has semantics of an array > (random access to every element and efficient insertions at the end of an > array), although every array may have semantics of container. This is a property of the index type, I believe. If your index (iterator) has only the operation 'Succ, and no 'Pred then the array built upon it will become a stream, this in turn will allow an implementation, which does not provide random access. And note that my point regards views and only. A container may have other, non-array, views. Its array view might be strict read-only etc. I want to separate interface and implementation, you know. > I think that > for this reason containers shouldn't be all treated as abstract arrays, > because this could be misleading. After all the reason for diversity of > container types is their certain operations' efficiency difference. > >> Iterators should be introduced as index types, subdivided into ordered and >> unordered ones. > > But aren't all iterators already ordered? Otherwise they couldn't > iterate... Not necessarily. You can have weaker orders. Consider multidimensional arrays, trees and graphs. However, yes, "index" or "pointer" would be a more precise word than "iterator". >> For ordered index types you can have ranges. > > Can't you have them with iterators? Only if the container defines a corresponding helper type. In my view it should be the reverse. If a type is an ordered index then its contract is to have ranges and all operations on them. >>>> 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. > > This comparison seems to me a bit unfair. Don't you think that if C++ > would use polymorphic containers, then its type system would also be > adjusted to cover 90% of all cases? C++ is beyond hope, anyway. C++ OO model is in my view irreparably corrupt. And I do not much care how #defines called templates will evolve. It is not my business! (:-)) >> 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. > > What do you mean by 'inlining' here? C++ templates are also > instantiated, either explicitly or implicitly (in a place you use it). I prefer "inline" because C++ instantiation may fail due to errors in the template body. That is because C++ templates are in fact macros. When and if, C++ will switch to a contract model, then I will call it instantiation. >>> template Foo (A & X, B & Y) >>> { >>> ... >>> Do_Something (X [I], Y [J]); >>> ... >>> } > [...] >> The contract of Foo is: >> >> 1. Foo takes two arrays as parameters. > > As long as we don't come to a common conclusion what an array is, this > is meaningless... But we don't need that, because in a contract model, array is just an interface of a set of types with some operations defined. This eliminates any philosophical question about where all arrays go when you turn the computer off! (:-)) We just define the operations we consider to be useful and call it array. Then anything declared to implement that interface will be an instance of the array. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de