Re: Passing C-style flags to C subprograms

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

"Natasha Kerensikova" <lithiumcat@gmail.com> wrote in message 
news:slrnjnj0gk.1lme.lithiumcat@sigil.instinctive.eu...
> Hello,
>
> On 2012-03-30, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Natasha Kerensikova" <lithiumcat@gmail.com> wrote in message
>> news:slrnjnbu7o.1lme.lithiumcat@sigil.instinctive.eu...
>>> I have been trying to write an Ada binding to libevent2. There are all
>>> sorts of issues and I have only started, so I'm not sure it will ever
>>> lead to anything interesting, except for my own personal enlightenment.
>>> One of these issues is passing and retrieving "C-style" flags, and I
>>> would love to see sharing of insights on this topic.
>> ...
>>> I found a solution in Florist. I don't whether it's specific to Florist
>>> or standard (I haven't been able to find a reference for POSIX for Ada).
>>> It defines a private Option_Set type, which is actually a modular
>>> integer, and operations on it implemented as bitwise arithmetic.
>> ...
>> This is essentilly what Claw does for (most) Windows flags.
>
> Thanks a lot for sharing your experience. I was about to go for the
> other solution, so you saved me the time to switch away from it when I
> would have realized by myself that it had been a mistake.
>
> One thing I still don't completely understand though is the choice of
> ">=" operator for testing output flags. Could you explain the rationale
> behind it?

The comments in Claw explain this: this defines "inclusion":

        function ">=" (Left, Right : in Window_Style_Type) return Boolean;
            -- Read  A >= B   as   A includes B
            -- That is, each style set in B is also set in A.

I also should note that we made these type private (so no predefined 
operators are inherited visibly). Instead, we defined a batch of constants 
and a pair of conversion operators (so that values that we didn't anticipate 
could be handled).

> The only idea I have found it to consider flag type as representing
> subsets of flags, and then consider ">=" as the equivalent of inclusion,
> which is an order in the set of subsets. But in that case, wouldn't it
> make more sense to use set-ish operators like "or" and "and" instead of
> "+" and "-"?  Also "+" and "-" feel like operators on numbers, so having
> a ">=" besides feels like an total order, while inclusion is only a
> partial order.

I think the idea was that "+" is "adding" a style to the set, and "-" is 
removing a style from the set. We definitely did not want anyone to think of 
any of the these operators as numeric.

The problem with "or" is that it doesn't have an obvious relationship to a 
set operator. It's (at best) an operator on bits, and we did not want to 
talk about bits. We wanted to talk solely about operations on the set of 
styles (adding or removing styles, etc.). [Admittedly, the "escape hatch" of 
using numbers via the conversion functions somewhat dilutes that approach, 
but we thought that most users would never need to worry about those "escape 
hatches".] We could have tried to use functions like "Union" or "Add" 
instead, but those would have gotten wordy: the "+" notation is shorter.

(Note that I don't remember this clearly and I may have misremembered why we 
did some of the things we did.)

Of course, YMMV; every problem is different.

                       Randy.