From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 588FEBC69 for ; Sat, 24 Feb 2007 22:33:12 +0100 (CET) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1OLXAqV004460 for ; Sat, 24 Feb 2007 22:33:11 +0100 Received: by nz-out-0506.google.com with SMTP id l8so832661nzf for ; Sat, 24 Feb 2007 13:33:10 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XfQvwMF8hgf3dljwA3yRtZ5mhj9Dd9xPWmK+DD2A8BaI1eZDeL2+wf0lAldVA7Z2eL6WCqlOIEoiMwXy/dh34lgS3b3uX7VqstMpOulblMhik2JbdCOMKzXTAO5hPth3HZZa3XXhpAnm554OpHpp52T5aYAJTcRUzwxk3sLS1XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J8dePHR33itiuDCo9jvtpCzDbIYWOEPUFdXlkTpPBMPABBeCGvB3B0cOcAbJHRLVoKV3PbAy3JyFcz3wXMka3j26tPmUL6RtEhVlLwNJ6VV96aJm7Ylp76f46QODQbYLVihS3qRT9c3n3NvK3aGH0i8KYAr2IbFGBY+XfV09G64= Received: by 10.64.242.5 with SMTP id p5mr5625910qbh.1172352790443; Sat, 24 Feb 2007 13:33:10 -0800 (PST) Received: by 10.65.211.17 with HTTP; Sat, 24 Feb 2007 13:33:10 -0800 (PST) Message-ID: Date: Sat, 24 Feb 2007 13:33:10 -0800 From: "Nathaniel Gray" To: micha Subject: Re: [Caml-list] coding c++ enum type Cc: caml-list@inria.fr In-Reply-To: <45E00103.9020809@fantasymail.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45E00103.9020809@fantasymail.de> X-j-chkmail-Score: MSGID : 45E0AF17.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 45E0AF17.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; enum:01 interfacing:01 flags:01 variants:01 flags:01 initialized:01 bitfields:01 constructors:01 variants:01 cheers:01 unix:01 wrote:01 caml-list:01 int:01 int:01 On 2/24/07, micha wrote: > > when interfacing to c, what is the preferred method to represent enums > which are used as flags in c? > I can choose between: > 1. using a variant type and a list of those variants to represent the > or-ed flags. Then I have to iterate over the list to calculate the > combined flag value. > > 2. I can export global variables initialized with the real value of the > flags and a function which combines (with "or") them together, > > Is one method better than the other? The Unix library uses both techniques -- using a single int for file permissions but a list of flags in various other cases. Personally, I think that as long as the bitfield fits in 31 bits then it's better to keep it as a simple int. Bitfields allow you to do some things very simply that would be more painful with a list of constructors. For example, testing if flags a, b, and c are set can be done very quickly and easily with a bitfield, but becomes somewhat laborious and/or slow with lists. You can easily provide an additional "list of variants" interface on the ML side if you think some users would prefer that. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->