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,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!solnet.ch!solnet.ch!newsfeed.freenet.de!151.189.20.20.MISMATCH!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Fri, 25 Mar 2005 20:37:42 +0100 From: Georg Bauhaus User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) References: <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1110329098.642196@athnrd02> <1110361741.551255@athnrd02> <422edaec$0$26554$9b4e6d93@newsread4.arcor-online.net> <1111464133.508323@athnrd02> <423fe9df$0$11476$9b4e6d93@newsread2.arcor-online.net> <1111521825.653841@athnrd02> <424094b0$0$11481$9b4e6d93@newsread2.arcor-online.net> <1111568404.687226@athnrd02> <42416659$0$11476$9b4e6d93@newsread2.arcor-online.net> <1111611226.253249@athnrd02> <4241f47a$0$24073$9b4e6d93@newsread4.arcor-online.net> <1111627358.387482@athnrd02> <424222df$0$24057$9b4e6d93@newsread4.arcor-online.net> <1111632436.374702@athnrd02> <1111698643.735412.144620@l41g2000cwc.googlegroups.com> <424362cc$0$11478$9b4e6d93@newsread2.arcor-online.net> <1111717144.891831@athnrd02> In-Reply-To: <1111717144.891831@athnrd02> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42446836$0$11463$9b4e6d93@newsread2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 25 Mar 2005 20:36:22 MET NNTP-Posting-Host: 22d47dc5.newsread2.arcor-online.net X-Trace: DXC=AB:QZ=_hc]TD__2dTlB=E[Q5U85hF6f;TjW\KbG]kaMX]kI_X=5KeaVE_l^ Ioannis Vranos wrote: > Georg Bauhaus wrote: > >> One difference is a 1:1 correspondence of index values and >> indexed items. This suggests not using p[-1] or somearray[1] >> interchangeably: >> >> There is one named index type. >> There is one named array type. >> The index type is used in the declaration of the array type, >> stating the set of permissible array index values. > > > > Again, one can easily define an array container that accepts user > defined indexes. I have not seen one so far, only some handcoded range checking, which is not the point. Handcoded range checking does not replace the definition of a type in terms of two other types. Note carefully: types. Range checking is not the same thing as a type. Neither in source text read by a human, nor in source text read by a compiler. Whatever the language is. In C++ terms: namespace Adalike { template class vector { ... }; } Can you see the essential and important difference? Just like std::map, Adalike::vector has two (!) non-default parameters: one for the item type, the other for the index type. This is the essential difference between std::vector and Adalike::vector. The compiler will use the information present in Index to establish properties of the Adalike::vector type such that Adalike::vector indexing (an operation) is based on properties of Index (Index is a type! It is not an algorithm base on min and max int parameters). This has something to do with making the base types int, long, etc. class types. When they are class types, you can invoke their methods, derive other number types, and then you can use their interface to build an array that is using the information provided by int or provided by a type derived from int. Ada: type Year_of_Interest is new Integer range 1815 .. 1914; type History is array (Year_of_Interest) of String; It is not possible to express this using types in C++: class Year_of_Interest : int { // Not C++ ... }; typedef array History; (Because there is no such thing as array in STL afaik. Association is characteristic of map, not of vector etc. This is different in Ada, where association is readily availably by associating an index type with an array in an array type declaration.) > The philosophical question that arises is *why no one > has done it to this day*. It has been done for associative containers only. It could be done for array-like containers if C++ had introduced the base types as base classes. > However I am going to make such one in some weekend (perhaps this!) to > see if I can find any real use of it. Doing it sounds really simple: > > > template A solution will have this parameterization and checks: template > class Array: public vector > { > // Only provide definitions for operator at() and operator[] that > // really *only* explicitly call the base ones with the proper index. > // And the few constructors doing the same, *only* explicitly passing > // the *same* arguments to the base constructors. // Check indexing precondition Index::contains(v) in at(v) and // operator[](v). > }; > I think it is *that* simple. O.K., I'll wait. > For more diverse things, maps are suitable (I guess in Ada too). Maps are not needed here, in Ada and other languages supporting different kinds of arrays. For example, why should I use std::map, when I can use something much more efficient to express the same concept, and still the thing is an array, technically? In pseudo-C++ terms, Ada *does* provide std::valarray (Yes, 2 parameters here!) >> (Ada-like arrays have STL's key_type so to speak.) > key_type is used only in maps! In Ada, key_type *is* used in arrays, because that's a feature provided by the language. This is what I'm trying to explain. Georg