www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal new type "flags"

reply Rueschi <rueschi GIquadrat.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	Hi folks,

many functions may be controlled by some flags that are combined
in an uint value. However, this is not type safe. You can unintentionally
provide/combine flags that are not intended for that function.
The solution would be a "flags" data type, similar to enums:

flags BaseFlags
{
  FEATURE1,
  FEATURE2,
  FEATURE3,
  FEATURE4
}

flags PrettyFlags : BaseFlags    // use all flags defined in BaseFlags, plus:
{
  BEHAVE_CORRECT,
  DONT_CRASH
}

void service( PrettyFlags whattodo )
{ /* ... */ }

void main()
{
  service( 0x02 );               // error: this is the usual but unsafe way
  service( PrettyFlags.FEATURE2
           | PrettyFlags.DONT_CRASH );  // ok and type safe
  service( FEATURE2|DONTCRASH );        // maybe also ok?
}


  - the following operations are valid:
    ==, !=   equality tests
    <>, !<>  tests presence of all flags from the right operand:
             FEATURE1|FEATURE2|FEATURE3 <>  FEATURE1|FEATURE3
             FEATURE1|FEATURE2|FEATURE3 !<> FEATURE1|FEATURE4
    |, |=    setting flags
    &, &=    erasing flags
    ^, ^=    toggling flags
    ~        inverting
    !        conversion to bool
    is       including is( i : s ) and is( i == s )

  - properties:
    .init    flags value with no bits set
    .sizeof  8, 16, 32 or 64, depending on the number of flags
    .count   number of flags
    .all     flags value with all flags set (same as ~.init)

  - flags can be inherited by another flags type
    (by the way: why can enums not be inherited?)

  - flags are implicitly converted to theyr base type

  - flags are implicitly converted to bool

  - flags are cool ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFFpF96xpVjSwvEWI4RAnr/AKDEv2xqRYRTuj+BSxwuAGfdMS/h+wCg4fT3
cpT9/QWMcpfJTNHWlRXpCDE=
=N38j
-----END PGP SIGNATURE-----
Jan 09 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Rueschi" <rueschi GIquadrat.de> wrote in message 
news:eo1nft$1831$1 digitaldaemon.com...

 Hi folks,

 many functions may be controlled by some flags that are combined
 in an uint value. However, this is not type safe. You can unintentionally
 provide/combine flags that are not intended for that function.
 The solution would be a "flags" data type, similar to enums:
 ...
  - flags are cool ;-)


I have wanted something like this so, so many times.  Enums make you 
expliitly number the flags and then you have to use a plain uint param to 
accept flags.. it's just a pain.  Something like this would be fantastic.
Jan 09 2007
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 10 Jan 2007 00:39:03 -0500, "Jarrett Billingsley"
<kb3ctd2 yahoo.com> wrote:


"Rueschi" <rueschi GIquadrat.de> wrote in message 
news:eo1nft$1831$1 digitaldaemon.com...



 many functions may be controlled by some flags that are combined
 in an uint value. However, this is not type safe. You can unintentionally
 provide/combine flags that are not intended for that function.
 The solution would be a "flags" data type, similar to enums:


I have wanted something like this so, so many times.  Enums make you 
expliitly number the flags and then you have to use a plain uint param to 
accept flags.. it's just a pain.  Something like this would be fantastic. 


I'm pretty sceptical about this.

The thing is that I tend to want some things that aren't single-bit
flags - some things that use several bits. Or at least the ability to
test several flags in one go. To do that, you need masks to isolate
each group of bits as well as the various values for each group.
Having a flags feature that could cope with generalisations like that
would probably be more complex than its worth, and if it can't handle
these generalisations, to me it's worse than worthless. Yes, worse,
since you'd end up wasting time converting other peoples flag sets to
enumerates with explicit values when the requirements change and you
need those generalisations.

Another common requirement is to pack a couple of flags into the most
significant bits of an integer that doesn't need all its bits. This
means having flag values that start high and count downward, and
having a mask to extract the integer itself as well. For example, in a
multiway tree data structure (such as a B+ tree database index) I
might pack leaf-node and root-node flags into the high two bits of a
node-size field.

A simple one-bit-per-flag counting upwards from bit zero is, for me, a
very rare exceptional case. The only cases where I remember it
happening are in artificial teaching examples back in college. The
nearest real-world programming match I have is a C++
set-of-unsigned-integers class that I use a lot which packs bitsets
into an underlying vector of integers, but the flags are associated
with integer values (normally some kind of UID), not identifier names.


Also, packing bits into an integer tends to be slower than just using
a boolean type, and since the saving in memory is usually small
(saving a couple of bytes here and there is pointless on machines with
megabytes, let alone gigabytes, of memory) there's no gain to pay for
the extra complexity. You should only do it if you have a specific
good reason.

The main use of packed bit flags is in file formats and communications
protocols, and in that case you probably want to specify explicit flag
values anyway - either because you are working to someone elses file
format, or because you don't want flag values to change accidentally
between versions just because someone added a new flag in the wrong
place.


There's a 'set' feature in Pascal that essentially does this, but one
thing I remember quite clearly from back when I used Turbo Pascal is
that I always handled my flag sets explicitly by packing them into
integers myself. Using sets was simply not practical for real-world
programs.

That said, I quite regularly use lists of strings as flag sets in
Python. It's easy, so if I don't care about efficiency, why not? The
point being that different issues affect different projects, and
perhaps this flags feature really is the right tool for certain jobs.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 10 2007
parent reply Rueschi <rueschi GIquadrat.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At first: I found 2 errors in my proposal - where I wrote

     .sizeof  8, 16, 32 or 64, depending on the number of flags
     .all     flags value with all flags set (same as ~.init)


I actually meant
    .sizeof  1, 2, 4 or 8, depending on the number of flags
    .all     flags value with all flags set
             (with ~x.all==x.init and ~x.init==x.all)

Steve Horne schrieb:

 On Wed, 10 Jan 2007 00:39:03 -0500, "Jarrett Billingsley"
 <kb3ctd2 yahoo.com> wrote:
 

 "Rueschi" <rueschi GIquadrat.de> wrote in message 
 news:eo1nft$1831$1 digitaldaemon.com...


 

 many functions may be controlled by some flags that are combined
 in an uint value. However, this is not type safe. You can unintentionally
 provide/combine flags that are not intended for that function.
 The solution would be a "flags" data type, similar to enums:


 I have wanted something like this so, so many times.  Enums make you 
 expliitly number the flags and then you have to use a plain uint param to 
 accept flags.. it's just a pain.  Something like this would be fantastic. 


 
 I'm pretty sceptical about this.
 
 The thing is that I tend to want some things that aren't single-bit
 flags - some things that use several bits. Or at least the ability to
 test several flags in one go. To do that, you need masks to isolate
 each group of bits as well as the various values for each group.
 Having a flags feature that could cope with generalisations like that
 would probably be more complex than its worth, and if it can't handle
 these generalisations, to me it's worse than worthless. Yes, worse,
 since you'd end up wasting time converting other peoples flag sets to
 enumerates with explicit values when the requirements change and you
 need those generalisations.


Doesn't D allow you to write
  alias FEATURE1|FEARURE2 FEATURE_SET;
or similar? When testing, use
  if ( FEATURE_SET==given_flags ) { /* all and only FEATURE_SET given */ }
or
  if ( FEATURE_SET<>given_flags ) { /* at least all FEATURE_SET given */ }



 Another common requirement is to pack a couple of flags into the most
 significant bits of an integer that doesn't need all its bits. This
 means having flag values that start high and count downward, and
 having a mask to extract the integer itself as well. For example, in a
 multiway tree data structure (such as a B+ tree database index) I
 might pack leaf-node and root-node flags into the high two bits of a
 node-size field.


This is contrary to the statement of yours, on modern
multi-megabyte-machines the additional space of one byte would
not be worth the effort. Anyway you can write something like:

  alias uint NodeData;

  flags NodeFlags
  {
    ROOT        = 1 << (NodeData.sizeof*8 - 1),
    LEAF        = 1 << (NodeData.sizeof*8 - 2)
  };
  static_assert( NodeFlags.sizeof == NodeData.sizeof, "size conflict" );
  static_assert( !(cast(NodeData)NodeFlags.all<<NodeFlags.count),
                 "unused MSBs" );

  struct Node
  {
  private:
    union
    {
      NodeData     nodedata;   /* I really miss int(0..0x3FFFFFFF) */
      NodeFlags    nodeflags;
    } = { nodeintval : 0 };

  public:
    NodeFlags flags()
      { return cast(NodeFlags)(nodata & cast(NodeData) NodeFlags.all); }
    NodeData data()
      { return nodedata & ~(cast(NodeData) nodeflags.all); }

    NodeFlags flags( NodeFlags f )
    {
      nodedata = data | cast(NodeData) f;
      return f;
    }
    NodeData data( NodeData i )
    {
      assert( (i<<NodeFlags.count)>>NodeFlags.count == i, "overflow" );
      nodedata = i | cast(NodeData) flags;
      return i;
    }
  };

/* The casts of flags to integral types are quite ugly. The language
 * should provide such casts via property, e.g. ".integral". This leaves
 * the implementation free to gamble with unused bits and mask them out
 * only when this property is used.
 */

Alternatively, if you are the master of the data layout, you could keep the
flags in the LSBs and shift the integral value.


 A simple one-bit-per-flag counting upwards from bit zero is, for me, a
 very rare exceptional case. The only cases where I remember it
 happening are in artificial teaching examples back in college. The
 nearest real-world programming match I have is a C++
 set-of-unsigned-integers class that I use a lot which packs bitsets
 into an underlying vector of integers, but the flags are associated
 with integer values (normally some kind of UID), not identifier names.


My approach makes no assumption to which bits are used. A compiler writer
may even choose to use one byte per flag, as long as I get my type safety
and operations (although he should seriously think about changing his
field of activity *g*). In my business environment, flags are used very
heavily. So much that I even dare to suggest multiple inheritance for flags:

  flags Permissions
  {
     READ,
     WRITE,
     EXECUTE,
     ALL = READ|WRITE|EXECUTE,
     NONE = Permissions.init
  };
  flags FilePermissions : (Permission:Owner),
                          (Permission:Group),
                          (Permission:Others)
  { STICKY };


  with ( FilePermissions )
    file.setPermissions( Owner.ALL | Group.READ | Others.NONE | STICKY );


Even more valuable would be the construction from enums:

  enum Unknown { UNKNOWN };
  enum Genre : Unknown { CLASSIC, HEAVYMETAL, LULLABY };
  enum Format : Unknown { VORBIS, MP3, WAV };

  flags FGenre : Genre {};
  flags FFormat : Format {};
  flags FSearch : FGenre, FFormat {};

  void search( string name, FSearch f, ... );

  with( FSearch )
    search( "happy birthday", HEAVYMETAL | FFormat.UNKNOWN, ... );

(virtual inheritance is not needed, at least I can't imagine such a scenario)


 Also, packing bits into an integer tends to be slower than just using
 a boolean type, and since the saving in memory is usually small
 (saving a couple of bytes here and there is pointless on machines with
 megabytes, let alone gigabytes, of memory) there's no gain to pay for
 the extra complexity. You should only do it if you have a specific
 good reason.


That is simply not true. When you have to pass flags as parameters, it
is faster to combine them in one integral value instead of pushing and
popping multiple bytes on and from the stack. It is waste of memory and
cache pollution to represent a logical bit by a physical byte.

But the main speedup comes when you want to compare more than one
(logical related) conditions in one operation. It is easier and faster
to compare against multiple flags if they are combined in one integral
value than doing byte-wise comparisions. Even in some situations where
integer operations on separated flags produce optimized code, the
single-word variant doesn't drag behind:

  flags AnsiColor { RED, GREEN, BLUE, BLINK };

The comparing part of the function

  void draw( string text, bool red, bool green, bool blue, bool blink )
  {
    if ( !blink && (red+green+blue)==1 ) { /* use only one plane */ }
  }

may compile to:

    mov    eax, [esp+blink]   ; arguments are passed as 32bit
    sub    eax, 1
    jnc    label1
    mov    edx, [esp+blue]
    mov    eax, [esp+green]
    lea    edx, [eax+edx-1]
    add    edx, [esp+red]
    jnz    label1
    jmp    use_only_one_plane
  label1:

while the alternative using flags

  void draw( string text, AnsiColor color )
  if (  !blink && (color==AnsiColor.red
                   || color==AnsiColor.green
                   || color==AnsiColor.blue) ) { /* draw only one plane */ }

may, if bit flags are used, compile to:

    mov    eax, [esp+color]
    test   eax, 0x08
    jnz    label1
    and    eax, 0x07
    mov    edx, eax
    shr    edx, 2
    and    eax, 0x03
    dec    edx
    shr    eax, 1
    adc    eax, edx
    jnz    label1
    jmp    use_only_one_plane
  label1:

These instructions use the same number of registers, take approximately
2 non-parallel instruction more but save 3 dwords on the stack.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFFx4VJxpVjSwvEWI4RApFQAJ0cu06Fxs9mlgtAGtA4nsnbPF2Z5wCePV3P
cPmbceN2TZSLohtKcn1HJ8M=
=Hzm5
-----END PGP SIGNATURE-----
Feb 05 2007
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
Sorry for the delay - I haven't been following the group for a while.

Your reply shifted my perspective on the problem a bit, but I still
disagree with your proposed approach to flags.

I think basically that you are trying to do with this flags type
something that should be done using structs with bitfields, or a
similar type specification that allows each bit or group of bits to be
accessed directly using a simple field name (without bitwise
operators).

The point here is that, while the specification of the fields is more
complex than a simple struct, there is a payoff for the investment.
The compiler can check things automatically that your examples check
explicity using asserts, and there is no need for all the
bit-twiddling.

I don't actually know what D's support for bit-fields or packed
records is like, but here is a bit of syntax-fantasy...

  bitfield NodeSpec : INT16
  {
    at 0:14 unsigned Size;  //  half-open bit range
    at 14   bool     Is_Leaf;
    at 15   bool     Is_Branch;

    mask  All_Flags = Is_Leaf | Is_Branch;
      //  Each field defines an implicit mask as a property of the
      //  type, to allow bit-fiddling in any strange cases. The 'mask'
      //  clause allows a few special cases to be explicitly added.
  };

  NodeSpec x;

  x.all = 0;
    //  Clear the whole bitfield at once.

  x.all &= ~NodeSpec.All_Flags;
    //  an operation that may be easier as bit-twiddling rather than
    //  adding explicit support, though having appropriate masks
    //  available as type properties seems is useful.
  
  x.Is_Branch = true;
    //  The easy way to access any individual flag.

The permissions example raises an important question - why are *you*
defining those flags rather than using predefined library definitions.
Nevertheless...


  bitfield Permissions : INT8
  {
    lsb 1  bool READ, WRITE, EXECUTE;
      //  'lsb n' means 'use least significant n remaining bits'
      //  'msb n' and 'rest' clauses could also be used.
  };

  bitfield FilePermissions : INT32
  {
    //  Build a compound bitfield type

    //  Each field defaults to 'lsb' with the size being the
    //  size of the specified field type.

    //  This could have been a struct, but allowing bitfields
    //  to be composed from other bitfields may allow more
    //  useful mask properties to be defined.
    Permissions Owner;
    Permissions Group;
    Permissions Others;
  };

Composition from enum types would be the same as composition from
signed/unsigned. An advantage to this approach is that the compiler
should be able to tell whether sufficient space is available in the
bitfield.

  enum Genre  : { UNKNOWN, CLASSIC, HEAVYMETAL, LULLABY };
  enum Format : { UNKNOWN, VORBIS, MP3, WAV };

  bitfield MusicInfo  //  default to int
  {
    Genre  m_Genre  = UNKNOWN;
    Format m_Format = UNKNOWN;
      //  use default position and sizing, and specify default
      //  values
  };

  search ("blah", MusicInfo (HEAVYMETAL, UNKNOWN));
  search ("blah", MusicInfo (m_Format=MP3));

The key point of all of this is simply that defining the bitfield type
saves work when accessing the bitfield, primarily by avoiding the need
for bit-twiddling. Adding properties to the type and values of that
type, along with implicit definition of a constructor, are just
obvious ways that a whole bunch of things normally done with
bit-twiddling can still be supported in a convenient and safe way, and
how bit-twiddling can still be supported as a last resort without
needing any casting or unions or other changes to the code structure.


The key issue with this bitfield approach is that it is really just a
tweak of what C structs with bitfields already do. Maybe what's really
needed is better support for bitfields in structs.


Other than that...

On Mon, 05 Feb 2007 20:28:09 +0100, Rueschi <rueschi GIquadrat.de>
wrote:


Steve Horne schrieb:




Doesn't D allow you to write
  alias FEATURE1|FEARURE2 FEATURE_SET;
or similar? When testing, use
  if ( FEATURE_SET==given_flags ) { /* all and only FEATURE_SET given */ }
or
  if ( FEATURE_SET<>given_flags ) { /* at least all FEATURE_SET given */ }


Maybe (not in D mode ATM) but I still don't see any real gain.

As soon as you need to define special masks outside the flags
definition, you may as well have simply defined explicit enum values
anyway. In fact, the enum would be clearer - all the values are
defined in one place.


 Another common requirement is to pack a couple of flags into the most
 significant bits of an integer that doesn't need all its bits.




<snip>


This is contrary to the statement of yours, on modern
multi-megabyte-machines the additional space of one byte would
not be worth the effort.


No - "common" is a relative term. Doing bit-twiddling is generally a
bad idea, and you should only do it when you have a good reason.
Within that set of occasions, cases such as the flags in the most
significant bits and other special cases are very common whereas a
simple set of flags counting up from bit zero is in my experience
quite rare.


 Anyway you can write something like:


Unnecessarily complex. Explicit setting of mask values in an enum
would be much simpler, and the compile-time checking is almost
certainly unnecessary. If compile-time checking is needed, the way
these checks are written is itself verbose and error-prone.

The compile-time-checking ideal would be a bitfield system similar to
the one I describe above, where the compiler understands the
specification of the bitfield as a whole and can report errors without
the need for asserts.


My approach makes no assumption to which bits are used. A compiler writer
may even choose to use one byte per flag, as long as I get my type safety
and operations


Type-safety isn't always the best way to avoid errors. Your approach
doesn't make access to the flags any simpler, especially since you
suggest using unions to overcome some of the limitations.

Don't get me wrong. Your own common usage examples seem nice and
simple both for specification and access. But your approach to
handling my tree node example shows that even slightly more complex
requirements can cause problems.

Fields are accessed many times more often than they are defined, so if
a flags/bitfield type is going to be considered, IMO your approach is
a missed opportunity. Taking more time to specify the type is most
beneficial if it results in assert-free compile-time error checks and
accesses that are simpler as well as safer.


 Also, packing bits into an integer tends to be slower than just using
 a boolean type, and since the saving in memory is usually small
 (saving a couple of bytes here and there is pointless on machines with
 megabytes, let alone gigabytes, of memory) there's no gain to pay for
 the extra complexity. You should only do it if you have a specific
 good reason.


That is simply not true. When you have to pass flags as parameters, it
is faster to combine them in one integral value instead of pushing and
popping multiple bytes on and from the stack. It is waste of memory and
cache pollution to represent a logical bit by a physical byte.


First, when putting the flags onto the stack, you first need to pack
them together into a single integer. If this can be done at compile
time, then you gain maybe a billionth of a second if you are very
lucky.

Then, we come to accessing the parameters.

Checking several separate booleans is really no problem - they will
still be in the processor cache from being pushed onto the stack, for
a start, and remember that the processor is shifting data in chunks
much larger than a few bytes anyway.

So any gains are not going to be huge.

On a non-intel architecture, the separate bools approach may have
gained a bit by not needing masking instructions to check single
flags, but this doesn't work so well on an intel chip - a mov
instruction doesn't set processor flags, so some kind of flag-setting
instruction will be needed in place of the masking.

So no huge gains, but it's all either good or, at least, no cost for
the bitset approach, eh?

Well, no. The bitset approach can limit the opportunities for
out-of-order execution (and maybe make branch prediction less
reliable).

Why?

To write a single flag (and any number of flags other than all of
them) requires a read-modify-write cycle. All the flags must be known
before the and/or flag-setting instruction can be performed.

Reading a single flag also requires all flags to be known (so the
masking instruction can be done).

This doesn't apply when using individual booleans.

Also, considering the 'mov' thing, masking is more specific than
testing for any non-zero value, so masking may still work out less
efficient. This...

  mov eax, [esp+blah]
  and eax, eax
  jnz label1

... will run slightly faster than this...

  mov  eax,  [esp+blah]
  test eax, MASK
  jnz  label1

... simply because 'and eax, eax' is a shorter instruction, whereas
the test instruction has a load of immediate data to worry about.
Furthermore, IIRC, modern processors tend to combine certain pairs of
instructions. A mov-then-test-for-nonzero is the kind of common pair
of instructions I'd expect a processor to handle efficiently,
effectively creating a single mov-with-flag-setting instruction.

mov-then-mask with every possibly mask accounted for? - doubt it.


So I stand by my original claim - dealing with packed bitfields tends
to be slower than dealing with separate booleans. There can be
performance benefits, but these tend to be at least matched by
performance penalties.

It's a tendency rather than an absolute, and there's not a lot in it
either way. I doubt that the difference would even register when
profiling most real-world software. And even if using booleans was
significantly faster, I wouldn't suggest switching just for
performance reasons - but the fact is that separate booleans are
easier to use, so it's the use of bitsets that needs to be justified.



These instructions use the same number of registers, take approximately
2 non-parallel instruction more but save 3 dwords on the stack.


So your code DOES take more instructions. AND it is more complex
(requiring three lines of condition-testing code rather than one).
Even in an example that you selected yourself, the only advantage to
counter two downsides is a few bytes less stack usage.

But you could have made a much stronger case, if only you'd noticed
that in the bitset example, testing the blink flag is actually
redundant - the RGB tests already cover it...

  if (   (color==AnsiColor.red  )
      || (color==AnsiColor.green)
      || (color==AnsiColor.blue ) ) { /* blah */ }

That would have saved you three assembler instructions. Three
instructions which look suspiciously as if they've been added by a
human programmer, to otherwise compiler-generated code. Not to mention
that your use of the blink flag was broken in the source (no mask, and
used as if it were a separate parameter).

So let's take a critical at the assembler for the bitset variant...

Here's those three blink-testing instructions.

    mov    eax, [esp+color]
    test   eax, 0x08
    jnz    label1

Contrasted with the remainder - a rather sophisticated calculation to
determine if precisely one of the interesting three bits is set. This
code is nothing like the source code, and not what the average human
programmer would write - it suggests a pretty intelligent
optimisation.

    and    eax, 0x07
    mov    edx, eax
    shr    edx, 2
    and    eax, 0x03
    dec    edx
    shr    eax, 1
    adc    eax, edx
    jnz    label1
    jmp    use_only_one_plane
  label1:

Unfortunately, it is an intelligent optimisation of different source
code - similar to, but different from, that you gave.

Look at the 'and eax, 0x07' masking at the top of that...

  1.  We already know that the blink flag is clear, so no need to
      mask it out.

  2.  The value checks in the source are whole-value comparisons, not
      restricted to only checking the first three bits, so the
      assembler doesn't match the source - it will miss cases where
      other bits are set that shouldn't be, and act differently to
      what the source code describes.

My suspicion - you have derived this example from real code, but have
modified it - and messed it up a bit. Your original source code
(ignoring the blink or other flags) probably looked something like
this...

  if (   (color&MASK == AnsiColor.red  )
      || (color&MASK == AnsiColor.green)
      || (color&MASK == AnsiColor.blue ) ) { /* blah */ }

As a result, you are arguing that twelve assembler instructions are at
least as fast as nine, where (if you'd got it right) you could have
been arguing that nine instructions are at least as fast as nine. I
know which one I'd prefer to be arguing ;-)

So with a bit of work, your bitset version can be made to appear a lot
more compelling. Even so, IMO you're still wrong.

Four flags as independent flag parameters is unusual. Even implemented
as booleans, the red, green and blue flags at least would be packed
into an AnsiColor struct (the 'blink' parameter looks like a misfit in
that collection).

Specify byte alignment for that struct, and suddenly the whole package
is one DWORD. Both versions use the same amount of stack - one or two
DWORDs depending on whether the blink flag is included along with the
RGB flags or not. When multiple flags are tested at once, that will be
optimised for both cases. But with the separate booleans (in a
byte-aligned struct) version, single flags can still be tested
individually without masking, and modified individually without
needing a read-modify-write cycle.


BTW - interesting question - Why didn't the compiler generate
something equivalent to...

  static byte Lookup [8] = { false, true,  true,  false,
                             true,  false, false, false };

  if (Lookup [color & MASK])
  {
    /*  blah  */
  }

I assume your example assembler is a symptom of supercompilation -
someone has done an exhaustive search to find the best possible
assembler for some common source code fragments, and built the results
into the compilers back end. But the lookup table approach looks at
least as efficient to me.

That should give something like...

  mov  eax, [esp+color]
  and  eax, 0x07
  mov  eax, [Lookup+eax]
  and  eax, eax
  jz   label1

This ignores the blink flag again - it's easily handled by either
doubling the lookup table size, or by adding those three instructions
again.

Since the lookup table can be embedded in the code (as switch lookup
tables usually are), it may even be addressed relative to the
instruction pointer, saving a few bytes more.

Presumably I'm missing something. No surprise there - my assembler is
extremely rusty.

-- 
Remove 'wants' and 'nospam' from e-mail.
Feb 07 2007
prev sibling parent Jason House <jason.james.house gmail.com> writes:
I think this is a start, but I think that a complete discussion of how 
enums are used in C/C++ is required.

I think that enums are used in one of two methods:
* As bit-based masks
* As a (complete) set of values that a variable can take

I'd be ok with calling the first flags and the 2nd enums.  This would 
clean up the issues with printing enums (my personal pet peeve with D).

I think that this'll need to be expanded to include multi-bit masks and 
the option to explicitly specify the values for particular masks.


Rueschi wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 	Hi folks,
 
 many functions may be controlled by some flags that are combined
 in an uint value. However, this is not type safe. You can unintentionally
 provide/combine flags that are not intended for that function.
 The solution would be a "flags" data type, similar to enums:
Jan 10 2007