Use single bool and bit flags for other bools.
-
PIEBALDconsult wrote:
Regardless of concerns of "performance", grouping a bunch of related flags into an enumeration is a good design choice.
The question implies unrelated booleans, as a compression technique.
Bastard Programmer from Hell :suss:
Does it?
-
As stated above, use an
enumfor yourbools. Something like:[Flags]
public enum MyBools : int
{
MyBool1 = 1,
MyBool2 = 2,
MyBool3 = 4,
MyBool4 = 8,
...
MyBool10 = 512,
}
public bool HasBool(int sumOfBools, MyBools specificBool)
{
return ((sumOfBools & specificBool) > 0);
}Bernhard Hiller wrote:
return ((sumOfBools & specificBool) > 0);
As a general test I prefer to test against the provided value (specificBool) rather than 0, because the specificBool may have multiple bits set. Plus, in .net 4 (if you use that), there is the built-in Enum.HasFlag Method.
-
Well... I'd have to say you do not provide us enough information. If your bools are related and used internally, yeah, I would group them into a [Flags] type enum. I wouldn't expose an enum from object though. That just doesn't seem like good practice to me. I would have 10 public properties that wrap a [Flags] type enum though. Thats about the same thing as packing them with the binary operators. If you are calling native C++ code, you have to use the binary operators, so there is no choice there, but I'd still have the class expose 10 public properties and wrap all that internally. If its all managed code, well... again it depends on your situation. If you have 10 bools vs. a [Flags] type enum, then the enum is going to be more efficient in transfering on the WIRE... who cares about memory usage... not important at this level. Maybe if you are working on a CE device with limited resources, it may be, but on a PC? you are wasting your time thinking about things like this.
SledgeHammer01 wrote:
I wouldn't expose an enum from object though ... I would have 10 public properties
I have either one public property or use a parameter (for a method or the constructor as appropriate) to pass in an Options enumerated value, as with passing options to a Regex.
-
PIEBALDconsult wrote:
Regardless of concerns of "performance", grouping a bunch of related flags into an enumeration is a good design choice.
The question implies unrelated booleans, as a compression technique.
Bastard Programmer from Hell :suss:
-
Hi, I have 10 bool variables in a class. Instead of creating 10 bools, how to create a single bool and bit flags for remaining 9 bool variables inorder to efficiently use memory. Can I have a code snippet in C# for this.. Thanks in Advance.
If you want this to cover a flag uint from interop or something else where you don't want an enum, you can do something like
public struct Flags {
public uint Value;public bool this[int i] {
get { return 1 & (Value >> i); }
set { uint mask = 1 << i; Value = (Value & ~mask) | (value ? 1 : 0) << i; }
}
}... to provide indexed access to a set of flags.
-
Does it?
-
SledgeHammer01 wrote:
I wouldn't expose an enum from object though ... I would have 10 public properties
I have either one public property or use a parameter (for a method or the constructor as appropriate) to pass in an Options enumerated value, as with passing options to a Regex.
Bad idea (sometimes). Property grids (i.e. in designers) don't play nicely with flag enums. Also, flag enums don't play nicely with data binding if you are using WPF or even Winforms.
-
OP wrote:
I have 10 bool variables in a class. Instead of creating 10 bools, how to create a single bool and bit flags for remaining 9 bool variables inorder to efficiently use memory.
It does.
Bastard Programmer from Hell :suss:
Does not -- they may very wel be related.
-
If you want this to cover a flag uint from interop or something else where you don't want an enum, you can do something like
public struct Flags {
public uint Value;public bool this[int i] {
get { return 1 & (Value >> i); }
set { uint mask = 1 << i; Value = (Value & ~mask) | (value ? 1 : 0) << i; }
}
}... to provide indexed access to a set of flags.
But I think that can only test one bit at a time.
-
Bad idea (sometimes). Property grids (i.e. in designers) don't play nicely with flag enums. Also, flag enums don't play nicely with data binding if you are using WPF or even Winforms.
SledgeHammer01 wrote:
flag enums don't play nicely with ... Winforms.
I haven't had that problem.
-
Does not -- they may very wel be related.