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!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed.news.tiscali.de!newsfeed.freenet.de!80.239.136.22.MISMATCH!tsicnews.teliasonera.com!news.otenet.gr!news.grnet.gr!newsfd02.forthnet.gr!not-for-mail From: Ioannis Vranos Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Wed, 23 Mar 2005 22:53:46 +0200 Organization: FORTHnet S.A., Atthidon 4, GR-17671 Kalithea, Greece, Tel: +30 2109559000, Fax: +30 2109559333, url: http://www.forthnet.gr Message-ID: <1111611226.253249@athnrd02> 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> <42416659$0$11476$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Host: athnrd02.forthnet.gr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: athprx02.forthnet.gr 1111611226 30287 193.92.150.73 (23 Mar 2005 20:53:46 GMT) X-Complaints-To: abuse@forthnet.gr NNTP-Posting-Date: Wed, 23 Mar 2005 20:53:46 +0000 (UTC) User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en In-Reply-To: <42416659$0$11476$9b4e6d93@newsread2.arcor-online.net> Cache-Post-Path: newsfd02!unknown@ppp14-adsl-7.ath.forthnet.gr Xref: g2news1.google.com comp.lang.ada:9829 comp.lang.c++:46906 comp.realtime:1630 comp.software-eng:5232 Date: 2005-03-23T22:53:46+02:00 List-Id: Georg Bauhaus wrote: > 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. > > 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. OK, I think you are right. C++ lacks these, and I wonder why additional keywords enabling this are not added in language proposals for future standard revision (C++0x). > >> 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.) OK I get your point, and you are right. These things would be nice to have in C++, and I think it is possible to have them just by introducing new keywords in the language, without breaking backwards compatibility. I do not know why there is no proposal for these. > 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; char does not feel well, one could use short but probably will use int. > We are discussing fastest access, and type based indexing. I can't understand why your code has faster access (I assume you mean run-time efficiency). > 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? I assume a vector that permits defining negative indices, and this is easy to be defined. However I may assume that since no such vector container is provided (even third-party), I may assume that either it is not considered as needed, or it is believed that maps and hash_maps can do the job. To give another example, .NET does not provide such an array container either, in its own containers collection. So why such a mainstream framework does not provide an array type with negative indexing either? This is not some kind of general proof, but for me it is an indication. Again, I agree that boundary checking etc are useful and should be added in C++ perhaps with additional keywords. > 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. Just to be technically accurate. C++ has fixed size built in arrays. It doesn't provide range checking for them though. int array[4]; is a fixed size, stack based, built in array. Fixed size in the heap: int *parray= new int[4]; Also, standard library containers with fixed size are valarray and bitset. -- Ioannis Vranos http://www23.brinkster.com/noicys