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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	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.125.233 with SMTP id mt9mr7877767pbb.5.1333417499044;
        Mon, 02 Apr 2012 18:44:59 -0700 (PDT)
Path: 
 r9ni12007pbh.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: BrianG <me@null.email>
Newsgroups: comp.lang.ada
Subject: Re: Passing C-style flags to C subprograms
Date: Mon, 02 Apr 2012 21:44:56 -0400
Organization: A noiseless patient Spider
Message-ID: <jldkmq$sot$1@dont-email.me>
References: <slrnjnbu7o.1lme.lithiumcat@sigil.instinctive.eu>
 <jl537p$tv8$1@munin.nbi.dk>
Mime-Version: 1.0
Injection-Date: Tue, 3 Apr 2012 01:44:58 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="yUWvtVAdKbJE6Qj4FbjOQw";
	logging-data="29469"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+zlk3mwoVnjPd1mrw4LPRq"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
In-Reply-To: <jl537p$tv8$1@munin.nbi.dk>
Cancel-Lock: sha1:AwGsO6hyxoPUsFrvdm+t1sySDZs=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-04-02T21:44:56-04:00
List-Id: <comp.lang.ada>

On 03/30/2012 03:57 PM, Randy Brukardt wrote:
> "Natasha Kerensikova"<lithiumcat@gmail.com>  wrote in message
> news:slrnjnbu7o.1lme.lithiumcat@sigil.instinctive.eu...
> ...
>
> We considered this and used it for a few sets of flags in Claw, but didn't
> do this in general for a number of reasons:
>
> (1) We needed the flag sets to be extensible without reprogramming. That is,
> if Microsoft adds a new flag value, we want people to be able to use it even
> before Claw is modified to add the flag. That works well with a numeric
> solution (just add a new constant); it doesn't work at all with a bit
> solution (unused bits stay unused).
> (2) Not all of the flag sets are pure bit-maps. Some include combinations so
> that one bit doesn't necessarily represent one flag.
> (3) Ada doesn't have defaults for aggregates; every component has to be
> mentioned (or an others clause used). That means that the aggregates
> representing flags are wordy; and the use of an others clause makes them
> less safe against modification than typical Ada code. (It's about the same
> safety as the original bit-flags; it's not a detrement to using records, but
> it means that there is no advantage in this way, either.)
>
You could also add
(4) Some users may be used to using the "Option_A + Option_B" type 
format.  While I consider this trivial, in building a library or 
binding, you need to worry about your users' priorities, not your own. 
It can also make porting existing apps easier.  (Of course, you could 
always define your own "+" or whatever - and I have done this.)


-- 
---
BrianG
000
@[Gee, Mail!]
.com