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,FREEMAIL_FROM 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!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail From: "fabio de francesco" Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 24 Mar 2005 06:55:46 -0800 Organization: http://groups.google.com Message-ID: <1111676146.182139.284080@z14g2000cwz.googlegroups.com> References: <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> <1111572591.296439@athnrd02> <1111574207.72969@athnrd02> <42414f88$0$9217$9b4e6d93@newsread4.arcor-online.net> <1111576802.823362@athnrd02> <1111577078.934620@athnrd02> <1111586334.958702.249050@o13g2000cwo.googlegroups.com> <1111608867.922129@athnrd02> NNTP-Posting-Host: 80.181.52.193 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1111676150 20439 127.0.0.1 (24 Mar 2005 14:55:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Mar 2005 14:55:50 +0000 (UTC) In-Reply-To: <1111608867.922129@athnrd02> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: z14g2000cwz.googlegroups.com; posting-host=80.181.52.193; posting-account=Lp02jQ0AAABMd3TAghNf0TM2YBZqD_JE Xref: g2news1.google.com comp.lang.ada:9912 comp.lang.c++:47083 comp.realtime:1687 comp.software-eng:5294 Date: 2005-03-24T06:55:46-08:00 List-Id: Ioannis Vranos wrote: > fabio de francesco wrote: [skip some lines] > > What's more in Ada is that you can, in a standardised way, directly > > create low-level representation of user defined types with a lot of > > attributes that C++ doesn't provide. Ada programmers prefer to build > > their own types rather than using built-in Integer, Float, Long_Float > > (int, float, double) and so on in order to gain a much finer control. > > > > In Ada you can decide representation attributes like range, digit, > > delta, mod, address, alignment, size, byte-order (little or big endian) > > in record component, and many other things like these. As an example > > you can write: > > > > type Counter is new Integer; > > for Counter'Size use 48; > > for Counter'Alignment use 16; > > > > What's more, you get a compiler error if your machine can't use some > > sort of representation you need in order to free you from knowing how > > much space a type can provide. > > > > You said that real C++ code hardly need to specify ranges, because you > > should be careful not to assign a value that can't be held by a > > variable of some specific type. Imagine you have know a variable is to > > hold numbers not larger than 99_999 and you choose to store them in an > > "int" knowing that you have enough space. When later you port your > > program to a machine where "int" is 16 bits you don't have any warning > > from a C++ compiler and program run for years until for some reason > > that variable is assigned with say 86_000. I think you know what > > happens.. > > > The standard guarantees the minimum ranges, for int can hold at least > 16-bit values and long at least 32-bit values. Sorry, maybe I was unable to explain the concept because of my poor English. Try please to re-read the latest paragraph, because you're missing the point. I know that standard guarantees minimum number of bits per types. I was reasoning upon porting a C++ code from a machine providing C++ "int"(s) with 32 bits capacity to another machine where "int"(s) are only 16 bits. In that situation if you forget to substitute every "int" with "long" you don't get any error from the compiler. That ported program can execute for years without any problem. When that variable is assigned a value like 32768 you get -32768 and then negative numbers increasing towards zero for each "++var;". Remember that this assignment was considered allowable, since the programmer chose an "int" type for that variable knowing that it is stored in 32 bits in his development machine. Maybe that won't crash your program yet it is worse, because a bug has been inserted and it may pass unnoticed for years. What I want to say is that in C++ (1) you must know how many bits are reserved for every type you use and (2) you must carefully change types when compiling to different targets. Instead in Ada a programmer can just write code that is portable across different platforms without worrying of bits of storage for types. Just ask the compiler "I need to store values between -80_000 and 80_000, so please choose yourself how many bits I need", and you can be sure that it won't raise any bug porting code from a machine with 32 bits "int" to a 16 bits "int". The interesting thing in Ada is that either you can let your compiler to choose how to internally reserve storage, or you can force a lot of attributes for representation like the example that I provided: type Counter is new Integer; for Counter'Size use 48; for Counter'Alignment use 16; The above mentioned type declaration is something can't be done with C++, as far as I know. In order to do same kind of things you must use some no-standard compiler extension. Ada is simultaneously lower-level and higher-level than C++. Ciao, fabio de francesco > > If you had that type declared as "type Var_T is range 0 .. 99_999;", at > > the very moment you port your program to this new machine the compiler > > would choose the correct size to hold values of that type so program is > > no more restricted to this 16 bits C++ "int" and consequently won't > > raise this bug. > > > > Do you still think you don't need ranges? > > > Ranges are a nice thing to have, however if you are provided with > minimum range guarantees, this also does the job. > > > I would prefer compiler error messages for out of range assignments > though. And I wonder what backwards compatibility (apart from -1 > assignment to unsigned integral types) this would break. > > > > -- > Ioannis Vranos > > http://www23.brinkster.com/noicys