Re: Enum or Named Number

["Randy Brukardt" <randy@rrsoftware.com>]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c4uqji$b5h$1@titan.btinternet.com...
> "Jeff" <jeff.huter@bigfoot.com> wrote in message
> news:fe4bb2c2.0404060930.f932668@posting.google.com...
> > Looking for implementation advise.  I'm writing a binding to some C
> > code that has several defined number macros (e.g. #define Viewable 1)
> > for states and flags.  I would like to bitwise-or these numbers in Ada
> > which leads me to believe I should define these as named mod numbers
> > such as below:
> >
> > type State is mod 2**Interfaces.C.Int'Size
> > State1 : constant State := 2#0001#
> > State2 : constant State := 2#0010#
> > State3 : constant State := 2#0100#
> >
> > Any reason to define these as an Enum with a representation clause?
> > Seems like there would be more plumbing code.  For example, I believe
> > that I would need to write my own bitwise-or function for the Enum.
> >
> > Is the named number implementation the way to go, or is there a better
> > way?
>
> Depends on a couple of things:
>
> 1) are you trying to provide a thick or thin binding?
> 2) can the "states" really mutually exclusive or can they be 'set' at the
> same time?
>
> If the answer to 1) is "thick binding" and 2) is "really mutually
exclusive"
> then I would take the hit and declare an Ada enumeration and use a lookup
> table to get the C representation.
>
> Otherwise, I think I'd just stick with the above.

I concur with Martin. We faced this issue in Claw, and we decided to use
constants of a private type with combining operations. That way, the
implementation as numbers isn't exposed, but they still work like the bit
operations.

In some of the later packages, we've used enumerations, but only when the
items really are mutually exclusive. And even then, we've had occassional
problems from later changes to the interfaces. (Just because they're
exclusive in version 4.0 doesn't mean that they'll remain exclusive in
version 5.0.)

                        Randy.