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!news3.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: Wed, 23 Mar 2005 13:52:52 +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: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <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> In-Reply-To: <1111568404.687226@athnrd02> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42416659$0$11476$9b4e6d93@newsread2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 23 Mar 2005 13:51:38 MET NNTP-Posting-Host: eed1de97.newsread2.arcor-online.net X-Trace: DXC=eU;m3gFf>TQC3N6I?YBjS[Q5U85hF6f;TjW\KbG]kaMX]kI_X=5KeaV<[nmYnX2?PZhP3YJKgE\j\jJA_D=]VKB[ X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:9792 comp.lang.c++:46804 comp.realtime:1613 comp.software-eng:5213 Date: 2005-03-23T13:51:38+01:00 List-Id: Ioannis Vranos wrote: > Georg Bauhaus wrote: > > > We want a vector type indexed by values between M and N only *and* we > > want the compiler + tools to help us make data structures in accord > > with these ranges. We want it to take advantage of what it can learn > > from the type system which allows index range checking _at compile > time_. > > > At first, it is easy to write Not the point. > a container in C++ that accepts a > specified range for indexes. A vector has an index range built into the language C++. It was stated that type based indexing together with attributes helps both the writer and the compiler. No programmer effort needed. > The only reason that there is not one, is > because it does not make sense in C++ Interesting claim. I Don't buy it. It is just not available in the language. > The [0, +] style maps closely what is > happening in the machine. Another Off Topic. > Also it is possible to define range-checked at run-time, operations. > vector::at() is an example. Why are you repeating this? Not the point. > vector is also a dynamic-type array, so placing compile-time bounds > checking isn't possible/doesn't make sense. Elsewhere you say that it is possible and does make sense to work around this lack using compile time assertions, carfully placing them close to the object to which they are somehow related. (Effectively creating an ad-hoc meta-language written in templates. Only shows that the thing is indeed missing in C++.) It makes sense to know the bounds of a container, possibly in advance. Are you declaring that std::vector and not knowing the bounds is the only reasonable thing to do in programming? Type attributes are a mode of expression, available with types in Ada. You can build algorithms around language provided attributes, for example bounds, without having to resort to mere conventions and the hope that the compiler will do something useful with the conventional items. > For fixed size arrays and containers it is true, the compiler does not > catch at compile time any out of boundaries access. However we can do > this explicitly, by using compile-time checked assertions. In other words, C++ array like types don't have these properties. I'm not saying this is catastrophic. It's just not available unless you roll your own. This has consequences for how you write your software. It has consequences for what your compiler can do. Some of them are interesing, because of template computing. > > No. I mean a double subtype whose values range from N.M to N'.M'. > > > May you give an example for a container along with such a subtype? It was given, starting this "sub"thread. > > Here you can see one point that you might want to demonstrate: > > The compiler won't tell you that there is something wrong > > with > > > > doors[10].SetOpen().SetNoVan(); > > > > Worse, the program won't tell you either. This shows the missing > > link between vector indexing and the base type system in your > > approach. You could use > > > > doors.at(10).SetOpen().SetNoVan(); > > > > and handle the exception _at run time_. > > In Ada, the compiler will tell you: "index value 10 is no good!" > > because the array "doors" can only be indexed by values effectively > > between 0 .. 9. These and only these are the values of the type > > enumerating the ten doors, and only these are allowed as index > > values x in expressios doors(x). > > No exception handling, no .at() needed when you listen to your > > compiler and fix the indexing error before you deliver a program. > > You get this for free as a result of the language's type handling > > at compile time. > > > Will the Ada compiler tell you this, for user-defined types too? An enum is a user defined type. Any unconstrained type (including more than array types) entails constrained objects, and the compiler may have a word in this. Maybe, if one gets used to template programming, the basis of the language is deliberately ignored? Ada just doesn't need templates for many things that are tried using templates in C++, because the things are already in the language. > Or is > this restricted to built-in arrays? If the latest is true, then its > value isn't that much. Every bug that is found at compile time is worth a lot to me. Try telling someone that useful array attributes, and type attributes and object attributes in general, aren't of much value. What else are .begin() and .end() other than roll-my-own replacements for something that C style arrays lack, *language-wise*? Those working for an insurance company, in a stocks related business, in math related computing, statistics, etc. use *Array Programming Languages*. Why would they be doing this if good array support isn't worth something? What is the value of good array support in all those valuable Fortran computing libraries? Are you saying that a robust base type system isn't worth it because of the STL? Consider the effort is takes to get a useful STL made of basically, at-least-so-many-bits integers, pointers, and malloc(). Please answer this question: Why is vector not implemented using vector? (I'm serious.) > I think that the value of defined subranges in the style > -1000, -400 has not any practical use. Any evidence? > > - Given an enum, and > > - given a language that allows the enum as a basis for the construction > > of an array type in the type system ... > > (a) useful names for objects in your problem domain, checked at > > compile-time > > > What do you mean by names? I mean object names (enumerated identifiers), not strings. Like in typedef std::map Slow_Array; This is not the same as typedef std::vector Faster_Array: > > (b) a conceptual link between the enum (naming the single items) and > > a container _type_ (containing these items); you cannot use anything > > but these named numbers for indexing > > > Which has no value in the world of C++, but I guess many things in Ada > depend on this. You just gave an example of an assertion working around the indexing issue... So apparently proper indexing has a value in the world of C++, contradicting your claim. > > (c) the fastest possible access, for both reading and writing, possibly > > checked at compile time > > > Fastest possible access in C++. The fastest possible element access in C++ is dereferencing a pointer. The fastest possible element access in STL/C++ is varying with container and method. Compare type Floor_Number is -2 .. 52; -- sky scraper type Door_Count is array(Floor_Number) of Natural; versus typedef char Floor_Number; typedef std::map Door_Count; We are discussing fastest access, and type based indexing. So my question again, what does it take, in C++, to replace Floor_Number as typedefed above with something that matches the given building's floors exactly? What is the price to pay? > is the Ada compile-time boundaries checking available > to user-defined containers? We are discussing the value of a container that doesn't *need* to be defined because it is built into the language's type system, with all bells and whistles and compiler help. No user definition is *needed*, it's already there. If you insist on leading us astray and on constructing your own containers: The presence of bounds checking in programmer defined ADTs depends on how they are defined. > can compile-time assertions be used? The compiler will warn you when it can evaluate the expression in a pragma assert at compile time. More importantly, the compiler will use the compile-time checking required by Ada array types. No need for programmer assertions expressed using add-on templates. > Of course > one can always program improperly. :-) I did say that this is not the point, didn't I? The point is, how does a language help you writing correct and efficient programs. C++ the language doesn't have fixed size built in arrays. In some problem domains, fixed size arrays are very useful, if not essential. This is why many programming languages have them. Georg