[gsoc][RFC] Pointer Plus Bits
Hello, I previously sent out an email to the list about a pointer plus bits like data structure and received some feedback about a pointer plus bits data structure. After taking into consideration all of the different points of view, comments and concerns voiced by the Boost community I have implemented an extension to my bitfield_tuple which allows the user to easily store parts of a pointer and use the extra bits for storage. Here is a basic overview of the bitfield_tuple: Its a tuple like data structure which stores bitfields instead of whole types inside of single tuple. This allows the user to skirt packing limitations of structs and classes in C++ and create bitfields over the storage type of their choice OR leave that decision up to the data structure (the behavior for selecting the storage type is to select the smallest possible unsigned integral type which will hold the all of the bitfields). example of basic bitfield_tuple declaration. #include<boost/integer/bitfield_tuple.hpp> struct red; struct green; struct blue; using namespace boost; using namespace boost::bitfields; typedef bitfield_tuple< member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5>
rgb565_t;
The bitfield_tuple takes ordered named template parameters (In the case of the storage type order is ignored. IE no matter where you put the storage< type > template the ending result will be the same). the bitfield_tuple supports the following template named template parameters (all of the templates which follow are located within the boost::bitfields namespace): bit_align< std::size_t> -> increases the offset of the next field to an offset which is divisible by the supplied value unless the current index is divisible by the supplied value then there is no increase. filler<std::size_t> -> bits to be skipped. member<typename, typename, std::size_t> -> this is a basic bitfield parameters it takes are the type the bitfield is to return, a naming type and the width of a bitfield flag<typename> -> boolean version of member. storage<typename> -> uses the supplied type for internal storage. pointer<typename, typename, typename> -> NEW described below. Pointer Member Information: The pointer member takes three template parameters. 1) The type you would like to make a pointer to. 2) The name which can be used (instead of an index, index is also still available to use) to access the pointer. 3) This is an integral_constant or integral_constant like type which is used to make a mask over the value bits of the pointer. This has a default value to leave the last two bits open. You can use leading or ending bits of the pointer for storage by supplying a different mask. Reasoning behind allowing for leading storage bits. There are some systems which do low address allocations and then store values within the higher part of the address. While this is much more rare then the use case of stuffing two bits inside of the end of a pointer I felt that it would be best to provide a way to actually do this. Reasoning behind restricting the mask to an integral_constant or integral_constant like type. The intent for this is to associate a non deduced type with the mask itself, however if people feel better simply using hex to specify the mask I could change the behavior to do that. There are mask creation utilities which can be used to create the mask from a higher level the simply supplying hex. Here are some examples of how to declare a bitfield_tuple with a pointer member: #include <boost/integer/bitfield_tuple.hpp> #include <boost/assert.hpp> using namespace boost; using namespace boost::bitfields; struct ptr; struct color; struct i1; struct i2; typedef bitfield_tuple< pointer<int, ptr> > ptr_1; typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> > ptr_plus_two_bools; typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> > ptr_plus_two_bit_color; int main() { ptr_1 p1; int i = 10; p1.get<0>() = &i; BOOST_ASSERT(*p1.get<ptr>() == 10); ptr_plus_two_bools p2; p2.get<ptr>() = &i; ptr.get<b1>() = true; ptr.get<2>() = false; ptr_plus_two_bit_color p3; p3.get<ptr>() = &i; p3.get<color>() = 3; return 0; } The pointer does NOT have to be the first parameter of the bitfield tuple one can simply place things in front of the the pointer and the value mask of the pointer will not be affected. The only thing which is different when this is done is the offset of the pointer within the bitfield_tuples storage, this only changes the location of the bitfield where the pointer is actually being stored. That being said you will always receive the value bits of the pointer in the exact same way they were taken from inside the pointer. -- thanks, Brian Bartman
typedef bitfield_tuple< pointer<int, ptr> > ptr_1; typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> >
typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> >
Zitat von Brian Bartman <bbartmanboost@gmail.com>: ptr_plus_two_bools; ptr_plus_two_bit_color; I don't quite understand the rationale for all the differences between "pointer" and "member", but besides that it looks good. for example, you might want to store an integer that is always a multiple of 4 so the 2 lower bits aren't used. why is the masking/shifting restricted to pointers? i.e. why is there any difference between member<> and pointer<> besides a different interface/view/return type of get<>()?
flag<typename> -> boolean version of member.
how does flag<> differ from member<bool>?
filler<std::size_t> -> bits to be skipped.
what's the reason for letting the user control how the bits are stored? (specified order, filler<>, bit_align<>)
typedef bitfield_tuple< member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5>
rgb565_t;
The bitfield_tuple takes ordered named template parameters
the member naming is nice, but it would also be nice if this could be skipped, because people are used to indexing and might even replace a boost::tuple with a bitfield_tuple. (this would imply that the "name" parameter and the "size_t" parameter are switched so that the "name" can have a default.)
p1.get<0>() = &i;
in case you didn't already plan for that, there should be a metafunction that returns the return type of get<>(). (element<N,T> in Boost.Tuple) the user might need this for example in order to use the "pointer view" as an iterator. thanks,
On Sun, Jul 25, 2010 at 2:05 PM, Stefan Strasser <strasser@uni-bremen.de>wrote:
Zitat von Brian Bartman <bbartmanboost@gmail.com>:
typedef bitfield_tuple< pointer<int, ptr> > ptr_1;
typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> >
ptr_plus_two_bools;
typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> >
ptr_plus_two_bit_color;
I don't quite understand the rationale for all the differences between "pointer" and "member", but besides that it looks good.
for example, you might want to store an integer that is always a multiple of
4 so the 2 lower bits aren't used. why is the masking/shifting restricted to pointers? i.e. why is there any difference between member<> and pointer<> besides a different interface/view/return type of get<>()?
Pointer has one additional parameter which isn't currently isn't used in these examples. It allows the user to specify an integral_constant as a mask for the value bits of the pointer. There is one more field type which I'm going to add which will all the user to supply both a mask and a policy specifying how to store and retrieve data from within the storage type OR simply provide a mask type which will act to indicated the value bits within the type being stored. So for instance you could do what you are talking about and always store data within the lower to bits of an integer.
flag<typename> -> boolean version of member.
how does flag<> differ from member<bool>?
There really isn't any difference Other then less typing.
filler<std::size_t> -> bits to be skipped.
what's the reason for letting the user control how the bits are stored? (specified order, filler<>, bit_align<>)
The rationale behind allowing the user to control the bits is so that the bitfield_tuple can be used to construct packet header.
typedef bitfield_tuple<
member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5>
rgb565_t;
The bitfield_tuple takes ordered named template parameters
the member naming is nice, but it would also be nice if this could be skipped, because people are used to indexing and might even replace a boost::tuple with a bitfield_tuple. (this would imply that the "name" parameter and the "size_t" parameter are switched so that the "name" can have a default.)
OK I'll take that into consideration. It was something I had considered allowing for. I'll see if within the next iteration of this data structure I can't make the naming optional.
p1.get<0>() = &i;
in case you didn't already plan for that, there should be a metafunction that returns the return type of get<>(). (element<N,T> in Boost.Tuple) the user might need this for example in order to use the "pointer view" as an iterator.
I do have more then one way of accessing the proxy reference type that comes back from get. Its a fusion sequence and I provide additional meta functions external to the bitfield_tuple itself for accessing the proxy reference type. Thanks for the feedback
thanks,
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
Zitat von Brian Bartman <bbartmanboost@gmail.com>:
what's the reason for letting the user control how the bits are stored? (specified order, filler<>, bit_align<>)
The rationale behind allowing the user to control the bits is so that the bitfield_tuple can be used to construct packet header.
network packet header? wouldn't that also require guarantees regarding endian-ness and alignment between multiple bitfield_tuples (or a bitfield_tuple and another type) that only a platform/compiler can give? for example: the endian-ness of a 6-bit integer that is part of a bitfield_tuple is platform-dependent, isn't it?
On Mon, Jul 26, 2010 at 9:29 AM, Stefan Strasser <strasser@uni-bremen.de>wrote:
Zitat von Brian Bartman <bbartmanboost@gmail.com>:
what's the reason for letting the user control how the bits are stored?
(specified order, filler<>, bit_align<>)
The rationale behind allowing the user to control the bits is so that
the bitfield_tuple can be used to construct packet header.
network packet header? wouldn't that also require guarantees regarding endian-ness and alignment between multiple bitfield_tuples (or a bitfield_tuple and another type) that only a platform/compiler can give?
Yes. I'm still working on making it able to hold an entire packet at once. It's one of the future goals of the project. It was simple enough to add those features now so I did.
for example: the endian-ness of a 6-bit integer that is part of a bitfield_tuple is platform-dependent, isn't it?
I can set the endian-ness of the storage type itself by using Beman's endains (this is thanks to my mentor Vicente Botet). However one can not store a pointer inside of a the specially endian'ed type or I haven't tested this case and I don't believe that it will work.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
Zitat von Brian Bartman <bbartmanboost@gmail.com>:
The rationale behind allowing the user to control the bits is so that the bitfield_tuple can be used to construct packet header.
network packet header? wouldn't that also require guarantees regarding endian-ness and alignment between multiple bitfield_tuples (or a bitfield_tuple and another type) that only a platform/compiler can give?
Yes. I'm still working on making it able to hold an entire packet at once. It's one of the future goals of the project. It was simple enough to add those features now so I did.
it seems to me that this is beyond the scope of a "bitfield tuple". if I'd have to generate network packet headers I'd probably want a stream/output iterator that I can use to output data which guarantees endianness and alignment, not a data type that allows random access. none of the other (aggregated) types of C++ give any guarantees about the storage layout, not even PODs.
On Mon, Jul 26, 2010 at 11:37 AM, Stefan Strasser <strasser@uni-bremen.de>wrote:
it seems to me that this is beyond the scope of a "bitfield tuple".
You may be right. I'll bright this up with my mentor and see what he thinks about it. Thanks for the feedback.
if I'd have to generate network packet headers I'd probably want a stream/output iterator that I can use to output data which guarantees endianness and alignment, not a data type that allows random access.
none of the other (aggregated) types of C++ give any guarantees about the
storage layout, not even PODs.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
p1.get<0>() = &i;
It might be nice to make the accessor a free function written as: get<0>(p1) = &i; Inside a template I think you would have to write it as: p1.template get<0>() = &1; You shouldn't have to remove the member accessor, just provide both. This should also make the syntax interoperable with tuples. Andrew Sutton andrew.n.sutton@gmail.com
On Mon, Jul 26, 2010 at 10:42 AM, Andrew Sutton <andrew.n.sutton@gmail.com>wrote:
p1.get<0>() = &i;
It might be nice to make the accessor a free function written as:
get<0>(p1) = &i;
Inside a template I think you would have to write it as:
p1.template get<0>() = &1;
You shouldn't have to remove the member accessor, just provide both. This should also make the syntax interoperable with tuples.
OK. Will add a get free function that returns a proxy reference type. Andrew Sutton
andrew.n.sutton@gmail.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
Brian Bartman wrote:
bit_align< std::size_t> -> increases the offset of the next field to an offset which is divisible by the supplied value unless the current index is divisible by the supplied value then there is no increase.
"align" would be a better name. "Bit" is useless in context. When you document this mechanism, I suggest wording more like, "Ensures the offset of the next bit field is divisible by the supplied value."
filler<std::size_t> -> bits to be skipped.
Instead of "filler," how about "padding," "reserve," or even "ignore?"
member<typename, typename, std::size_t> -> this is a basic bitfield parameters it takes are the type the bitfield is to return, a naming type and the width of a bitfield flag<typename> -> boolean version of member.
I think "field" would be a better name. "Member" is too suggestive of classes and the parts in this context are called "bit fields," right?
storage<typename> -> uses the supplied type for internal storage.
I presume you mean that dictates the underlying storage type for the entire bitfield_tuple. I'm not sure I like that interface. I think two distinct types, one that computes the storage type and one that requires it (as the first template argument) might be better. That implies, of course, creating distinct names. Perhaps "bitfield_tuple" and "typed_bitfield_tuple?" (The latter is rather verbose, but no more so than "storage<some_type>" in the current scheme.) _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Jul 27, 2010 at 7:36 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Brian Bartman wrote: "align" would be a better name. "Bit" is useless in context.
The original name was going to be align, however I encountered a naming conflict with boost.Type Traits' align. Then after implementing it as bit_align, I later move all of the templates which make up the bitfield_class template interface into a separate namespace (namespace bitfields). So fixing that is quick. So as a general question should the namespace have a name other then bitfields? Would fields be a better name? And should the bitfield_tuple data structure be within that namespace as well?
When you document this mechanism, I suggest wording more like, "Ensures the offset of the next bit field is divisible by the supplied value."
Thanks for this, I was have some trouble figuring out how exactly to word this for my documentation.
filler<std::size_t> -> bits to be skipped.
Instead of "filler," how about "padding," "reserve," or even "ignore?"
I'm going to go with padding.
I think "field" would be a better name. "Member" is too suggestive of classes and the parts in this context are called "bit fields," right?
The initial intent of the interface of the bitfield_tuple was to make it feel sort of like a class/struct, while the user was supplying the template parameters. For instance, struct rgb565_t { unsigned char red:5; unsigned char green:6; unsigned char blue:5; }; would become something along the lines of, struct red; struct green; struct blue; typedef bitfield_tuple< member<unsigned char, red, 5>, member<unsigned char,green, 6>, member<unsigned char,blue,5>
rgb565_t;
storage<typename> -> uses the supplied type for internal storage.
I presume you mean that dictates the underlying storage type for the entire bitfield_tuple. I'm not sure I like that interface. I think two distinct types, one that computes the storage type and one that requires it (as the first template argument) might be better. That implies, of course, creating distinct names. Perhaps "bitfield_tuple" and "typed_bitfield_tuple?" (The latter is rather verbose, but no more so than "storage<some_type>" in the current scheme.)
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
Brian Bartman wrote:
On Tue, Jul 27, 2010 at 7:36 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
"align" would be a better name. "Bit" is useless in context.
The original name was going to be align, however I encountered a naming conflict with boost.Type Traits' align. Then after implementing it as bit_align, I later move all of the templates which make up the bitfield_class template interface into a separate namespace (namespace bitfields). So fixing that is quick.
So as a general question should the namespace have a name other then bitfields? Would fields be a better name? And should the bitfield_tuple data structure be within that namespace as well?
"bitfields" is fine for the namespace name, presuming the library will be named Boost Bitfields. (See later for spelling considerations.) The name is suggestive and means that nested names don't need to repeat "bit" or "bitfield." "bitfields::bitfield_tuple" is more repetitive than I'd like, but not horrible. Using a "bit" or "bitfield" prefix for every name in the "bitfields" namespace would be silly, so I'm inclined to suggest those prefixes be used for no names. That leads me to wonder whether the class template should be just "tuple." That is, fully qualified, it would be "boost::bitfields::tuple." That could lead to ambiguity, of course, when mixed with other tuple types with using directives in force, but "bitfields::tuple" can be used when those situations arise. Unfortunately, should this become standardized in the future, std::tuple won't work. Then again, there is likely to be a good bit of renaming if things aren't put in the std::bitfields namespace. That is, "std::align," "std::field," etc., may be too broadly applicable to be thought good names, so we needn't choose names for that vague future context now. Then again, someone else may find a better scheme than comes to my mind presently.
I think "field" would be a better name. "Member" is too suggestive of classes and the parts in this context are called "bit fields," right?
The initial intent of the interface of the bitfield_tuple was to make it feel sort of like a class/struct, while the user was supplying the template parameters.
For instance,
struct rgb565_t { unsigned char red:5; unsigned char green:6; unsigned char blue:5; };
would become something along the lines of, struct red; struct green; struct blue;
typedef bitfield_tuple< member<unsigned char, red, 5>, member<unsigned char,green, 6>, member<unsigned char,blue,5>
rgb565_t;
OK, yes, bit fields are declared in the context of a class type, but they aren't normal members. They are called bit fields. It would be better to use a name like "field" or "bit_field." That reminds me, an old (1984) C book I own uses "bit field." C++98 uses "bit-field." I think "bit_field" is the better spelling as it best encompasses both of those spellings. That also would suggest the library name be Boost.Bit Fields or Boost.Bit-fields. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Jul 27, 2010 at 10:17 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Brian Bartman wrote:http://www.newegg.com/Product/ProductList.aspx?<http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100007671%2050001157%20600005851&IsNodeId=1&name=LGA%20775>
"bitfields" is fine for the namespace name, presuming the library will be named Boost Bitfields. (See later for spelling considerations.) The name is suggestive and means that nested names don't need to repeat "bit" or "bitfield." "bitfields::bitfield_tuple" is more repetitive than I'd like, but not horrible. Using a "bit" or "bitfield" prefix for every name in the "bitfields" namespace would be silly, so I'm inclined to suggest those prefixes be used for no names.
I agree. There was only three instances within the library's public interface that I can think of that use either bit or bitfield as a prefix. you have pointed out two of the three thus far. The last one which shouldn't be directly (although there are accessors for it's type) is the proxy reference type which is called bitfield_reference and defined within bitfield_tuple.
That leads me to wonder whether the class template should be just "tuple." That is, fully qualified, it would be "boost::bitfields::tuple." That could lead to ambiguity, of course, when mixed with other tuple types with using directives in force, but "bitfields::tuple" can be used when those situations arise. Unfortunately, should this become standardized in the future, std::tuple won't work. Then again, there is likely to be a good bit of renaming if things aren't put in the std::bitfields namespace. That is, "std::align," "std::field," etc., may be too broadly applicable to be thought good names, so we needn't choose names for that vague future context now. Then again, someone else may find a better scheme than comes to my mind presently.
As it is currently bitfield_tuple is in the boost namespace and extra parts external to the class are located within the bitfields namespace. One of the other names which came up for this data structure was bit_tuple does that sound any better?
OK, yes, bit fields are declared in the context of a class type, but they aren't normal members. They are called bit fields. It would be better to use a name like "field" or "bit_field."
Hmm. I do understand where you are coming from. I'm considering changing it to simply field.
That reminds me, an old (1984) C book I own uses "bit field." C++98 uses "bit-field." I think "bit_field" is the better spelling as it best encompasses both of those spellings. That also would suggest the library name be Boost.Bit Fields or Boost.Bit-fields.
The only reason for the current naming is that the structure which the bitfield_tuple is currently based off of was named bitfield.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
Brian Bartman wrote:
As it is currently bitfield_tuple is in the boost namespace
Why is that?
and extra parts external to the class are located within the bitfields namespace.
Presumably, bitfield_tuple is defined in the your nested namespace and brought into the boost namespace with a using declaration. (I haven't looked.)
One of the other names which came up for this data structure was bit_tuple does that sound any better?
I don't think that's good. It isn't a tuple of bits, but rather of arbitrarily grouped bits. Hence "bit_field_tuple" is the better name. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Zitat von "Stewart, Robert" <Robert.Stewart@sig.com>:
One of the other names which came up for this data structure was bit_tuple does that sound any better?
I don't think that's good. It isn't a tuple of bits, but rather of arbitrarily grouped bits. Hence "bit_field_tuple" is the better name.
there is no reason to be strict with the naming here. even if it's technically two words, there's boost::dynamic_bitset, std::bitset and maybe other examples. (regarding the underscore. I agree wrt to a bitfield tuple not being a tuple of bits)
Stefan Strasser wrote:
there is no reason to be strict with the naming here. even if it's technically two words,
That is a reason, though one can choose to discount it.
there's boost::dynamic_bitset, std::bitset and maybe other examples.
There's also unordered_map, and the typical hash_map, (plus friends) but you're right that the standard containers generally compress the type names into a single word (as with multimap). It's probably best to keep "bitfield." _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Jul 27, 2010 at 11:18 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Brian Bartman wrote:
As it is currently bitfield_tuple is in the boost namespace
Why is that?
Not really sure why. But it will be shortly within the bitfields namespace.
and extra parts external to the class are located within the bitfields namespace.
Presumably, bitfield_tuple is defined in the your nested namespace and brought into the boost namespace with a using declaration. (I haven't looked.)
One of the other names which came up for this data structure was bit_tuple does that sound any better?
I don't think that's good. It isn't a tuple of bits, but rather of arbitrarily grouped bits. Hence "bit_field_tuple" is the better name.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman
participants (4)
-
Andrew Sutton -
Brian Bartman -
Stefan Strasser -
Stewart, Robert