views:

585

answers:

2

I have declared the following enum type in which I want the first member to have the ordinal value of 1 (one) rather than the usual 0 (zero):

  type
    TMyEnum = (
               meFirstValue = 1,
               meSecondValue,
               meThirdValue
              );

If I call TypeInfo(), e.g. as part of a call to GetEnumName(), I get a compiler error:

  GetEnumName(TypeInfo(TMyEnum), Ord(aValue));

ERROR: "E2134: Type 'TMyEnum' has no typeinfo"

Why is this?

I know that classes only have typeinfo if they are compiled with the $M compiler option enabled or (derive from some class which was, such as TPersistent) but I didn't think there were any special conditions for having typeinfo for enum types.

+7  A: 

Type information is not supported for enums where specific ordinal values are assigned that result in enum members having ordinal values that are different to those that would normally be assigned by the compiler.

If specific values are essential or desirable, "unused" enum members will have to be inserted to "pad" the enum as required. e.g (additional indentation for emphasis only):

  type
    TMyEnum = (
                meNOTUSED1,   {= 0}
               meFirstValue,  {= 1} 
               meSecondValue,
               meThirdValue
              );

A subrange can then be used to "filter" out the unused initial value:

   TValidMyEnum = meFirstValue..meThirdValue;

Although you might then wish to consider renaming the original enum type so that your subrange type may be used throughout your project.

A subrange isn't sufficient if the enum contains "gaps":

  type
    TMyEnum = (
                meNOTUSED1,   {= 0}
               meFirstValue,  {= 1} 
               meSecondValue,
               meThirdValue,
                meNOTUSED2,
               meFinalValue   {= 5}
              );

In this case there is no simply way to extend compile-time range checking to exclude the unused members, but a couple of set types will simplify the business of implementing any necessary runtime checks:

  type
    TMyEnums = set of TMyEnum;

  const
    meNOTUSED      = [meUNUSED1, meUNUSED2]; //  .. etc as required
    meValidValues  = [Low(TMyEnum)..High(TMyEnum)] - meNOTUSED;


  if NOT (aValue in meValidValues) then
     // etc
Deltics
Maybe you can alleviate the pain of doing this by using a subrange type:type TMyEnumWithDummy = ( meNOTUSED, meFirstValue, meSecondValue, meThirdValue ); TMyEnum = Succ(meNOTUSED)..High(TMyEnumWithDummy);
Ulrich Gerhardt
Yes indeed, although if you have "gaps" in the enum then a simple subrange won't be enough. In the case where I came across this I had gaps - Unfortunately I over-simplified for the initial "question".But I shall update the answer with your suggestion too.
Deltics
+11  A: 

Discontiguous enumerations and enumerations which don't start at zero don't have typeinfo. For typeinfo to be implemented, it would need to be in a different format from the existing tkEnumeration, owing to backward compatibility issues.

I considered implementing a tkDiscontiguousEnumeration (or possibly better named member) for Delphi 2010, but the benefit seemed small considering their relative scarcity and the difficulties in enumeration - how do you encode the ranges efficiently? Some encodings are better for some scenarios, worse for others.

Barry Kelly
That's some useful and interesting background info. You might at least have considered updating the documentation for the E2134 error. This provides one example of where typeinfo is not produced but does not give any clues as to these considerations for enum types.Then again, it's taken almost 15 years of solid Delphi'ing for me to stumble over this, so as you say it's not exactly a common problem. :)
Deltics