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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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.202.168 with SMTP id kj8mr6037538pbc.1.1333363243569; Mon, 02 Apr 2012 03:40:43 -0700 (PDT) Path: r9ni9698pbh.0!nntp.google.com!news1.google.com!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Passing C-style flags to C subprograms Date: Mon, 2 Apr 2012 10:40:42 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Injection-Date: Mon, 2 Apr 2012 10:40:42 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="29979"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/KqNCAZur1K5/j7WRSNPtE" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:mBO9gYjBSGKhrKK61EfZ7MQ/n6s= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2012-04-02T10:40:42+00:00 List-Id: 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 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. Unless I'm missing something, that's the rational behind operators on Ada.Strings.Maps.Character_Set. So I would have expected a Bit_Set or Flag_Set (to include multi-bit flags) to have a similar interface. Why isn't it so? And as a side question, for situations when time efficiency is critical, what are the ways to help a compiler use intrinsic operators for setting and testing flags? I guess publicly deriving specific flag types from Interfaces.C.unsigned is a way to inherit implicit operators that are intrinsic, but then I also allow operators that make no sense for a flag type, like "**" or "/". However, wouldn't hiding derivation in private part also turn public operators into non-intrinsic operations? And is there a way to allow "+" to be implemented with intrinsic "or" on C.unsigned? If I understand 8.5.4.5 (from Ada 2005 RM) correctly, renaming cannot do that. Or would a pragma Inline be enough to insert the expression (with its private intrinsic "or") into the caller code and end up with the same (assembly) result? Or should all the above be just dismissed as premature optimization? (I don't think so, because I believe it is never wrong to question, and premature optimization is a wrong answer rather than a wrong question; but I might be wrong). Thanks again for your insights, Natasha