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-Thread: 103376,c9bb37a1fdd0d3e9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.230 with SMTP id sd6mr7959510pbc.8.1333419253080; Mon, 02 Apr 2012 19:14:13 -0700 (PDT) MIME-Version: 1.0 Path: r9ni12087pbh.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!feeds.phibee-telecom.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Passing C-style flags to C subprograms Date: Mon, 2 Apr 2012 21:14:05 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1333419251 26248 69.95.181.76 (3 Apr 2012 02:14:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 3 Apr 2012 02:14:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-04-02T21:14:05-05:00 List-Id: "Natasha Kerensikova" wrote in message news:slrnjnj0gk.1lme.lithiumcat@sigil.instinctive.eu... > Hello, > > On 2012-03-30, Randy Brukardt wrote: >> "Natasha Kerensikova" 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.