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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c459ff0adb576bc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-19 08:49:28 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Matthew Heaney" Newsgroups: comp.lang.ada Subject: Re: Refactoring and Ada Date: Tue, 19 Feb 2002 11:54:38 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3C5AB0B7.9D75D49A@grammatech.com> <3c639940@pull.gecm.com> <4519e058.0202080714.1bf916bb@posting.google.com> <3C65BFF4.F15A07D0@earthlink.net> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:20126 Date: 2002-02-19T11:54:38-05:00 List-Id: "Larry Kilgallen" wrote in message news:DRxVLK5K93Eq@eisner.encompasserve.org... > In article , "Matthew Heaney" writes: > > I don't recommend you use representation clauses for enumeration types. You > > should forget this language feature even exists. Just use integer constants > > explicitly. > > Why ? > > The inability to store an arbitrary numeric value into a location > whose type is enumerated is one of Ada's greatest strengths. Here's why: type ET is (A, B); for ET use (A => 0, B => 1000000); A : array (ET) of Integer; How much storage does array A consume? Here's another reason: E : aliased ET; for E'Size use 8; read (fd, E'Address, 1); case E is ...; What happens when you read junk off the interface? Below is a post from Tucker on this very subject (courtesy of google): From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/09 Message-ID: #1/1 Sender: news@inmet.camb.inmet.com (USENET news) References: X-Nntp-Posting-Host: houdini.camb.inmet.com Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Joe Gwinn (gwinn@res.ray.com) wrote: : In article , : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : ... : > As far as enumeration types, as others have pointed out, the Ada 95 : > standard requires that the internal codes for enumeration types are : > contiguous and start at zero, so you are not in any danger if you leave : > out your "confirming" representation clauses. It would be nice if : > our front end recognized "confirming" enumeration representation : > clauses, but as usual, there are many possible "optimizations" : > and this one never made it to the top of the list. : > One might argue that this is not really an optimization, but : > it does require special code to recognize, and so represents : > yet another "special case" that you have to decide the priority : > of recognizing. : The key issue was that we had no way of knowing the dire consequences of : this innocent looking bit of standard Ada, until we had gone a fair : distance down that wrong road. If you ask anyone who knows me well, you will know that I consider the enumeration representation clause anything but "innocent looking" ;-). For what it is worth, we will soon be releasing a new front end that recognizes the special case of a confirming enumeration representation clause. [ASIDE: Although the ability to specify the representation of an enumeration type initially sounds perfectly reasonable, the fundamental problem is that Ada also allows such "holey" enumeration types to be used as the type for a for-loop index, an array index, an entry family index, or the 'Succ/'Pred attributes. This results in surprising implicit inefficiencies, something that violates one of the general Ada language design principles. Your enumeration rep clause simply reconfirmed the default representation, but suppose it didn't? You would be stuck with the overhead you managed to eliminate by simply commenting out the rep clause. Of course, the compiler could recognize various other specials cases, such as contiguous representation starting at something other than zero, or evenly distributed "holey" representation (e.g., even numbers only), or simply not "too" sparse, or ... Pretty soon handling these enumeration representation clauses the way the "innocent" user would "expect" becomes a major artificial intelligence challenge. During the Ada 9X design process, when we found one of our new language ideas evoving into this kind of complex AI pattern matching problem for the compiler, we knew we were on the wrong track. The user should be designing the algorithms, using the basic primitives of the language. The primitives shouldn't themselves be at such a level that the compiler is effectively trying to take over part of the programming problem. Note that in C and C++, allowing the user to specify the values for enumeration literals creates no similar problem, because there is no operation that depends on the logical "position" of an enumeration literal. All semantics of enumeration values in C/C++ depends on the underlying "code," not the position. So in retrospect, I believe enumeration representation clauses in Ada are a mistake. If a user wants to name particular values, they should simply use named integer constants, or perhaps better, named private-type constants. They can build up various maps of their own if they want to translate to/from some kind of "holey" representation from/to a contiguous representation. END OF ASIDE] : ... One wonders what other surprises lay in : wait. In general, the Ada language design philosophy eschewed "innocent" looking features that were in fact expensive at run-time. However, in the specific case of enumeration representation clauses, this useful language design philosophy was not completely followed. Other cases I know of are interactions between finalization, exception handling, and abort, where the combination of features forces some or all of these three to incur more run-time overhead than you might expect. One "innocent" looking construct I once found was: (others => Default_Value(Segment)) used to initialize a segment of a load module to some default value. This called the function Default_Value once for each byte of the segment, and the segment was often 100K bytes or more. : ... : Joe Gwinn -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA