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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f70e7a457bf23e69 X-Google-Attributes: gid103376,public From: edward@igate1.hac.com (Ed Bruce) Subject: Re: Optimizing and Constraint Checks Date: 1995/03/29 Message-ID: #1/1 X-Deja-AN: 100540700 references: <3kv990$o7d@butch.lmsc.lockheed.com> <3l3l2v$ria@gnat.cs.nyu.edu> organization: Hughes Aircraft newsgroups: comp.lang.ada Date: 1995-03-29T00:00:00+00:00 List-Id: In article <3l3l2v$ria@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote: > > Wait a moment! In the absence of an numeration rep clause, this whole > discussion is irrelevant. If you don't have a rep clause, you just use > Pos and Val to go backwards andd forwards and the whole apparatus of > the generic is junk! I realize now I should have provided more background and also debugged my code before posting. I rushed this one out. The underlining problem is how to represent enumeration types in an external database(that is one not implemented directly in Ada). The current solution is to use 'POS and 'VAL. The problem is our code is in a very dynamic state and our enumerated types have and will continue to change. Since 'POS and 'VAL for any given enumeration_literal for an enumeration_type_definition may change as enumeration_literal's are added or deleted from the enumeration_type_definition our database maintainer has to modify the database to reflect these changes manually. Which leads to an increased risk of making a mistake that won't be caught easily if at all. That is if the an enumerated_value'POS is currently 5 in the database and should be changed to 4 (a literal was deleted), but is changed to 3. Well enumeration_type'VAL(3) is this case is legal but invalid. So I have suggested to the principal engineers on our project that we use enumeration representation clauses and unchecked type conversion. This way we are not dependant on the ordering of the enumeration_literal's. The problem is ARM 13.10.2(3): "...it is the programmer's responsibility to ensure that these conversions maintain the properties that are guaranteed by the language for objects of the target type." My question was, is there a portable way to do this and the answer I am getting is no for Ada, and yes/maybe for Ada-95. Haing received these answers I have also proposed we look at using 'IMAGE and 'VALUE instead and as expected I am receiving grumblings about sizing and performance issues. Luckily all I have to do is propose solutions and trade offs. The higher ups must balance cost, performance, and maintainability and decide which solution is best. -- Ed Bruce edward@igate1.hac.com