[ongoing review of binary_int] reviewers for small utility wanted
Reviews of binary int utility are needed. The tool is very small (but useful) and review should not take much of time. Both Scott Schurr and Matt Calabrese put quite a lot of effort into their work. Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value; Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 ); /Pavel
"Pavel Vozenilek" wrote
Reviews of binary int utility are needed. The tool is very small (but useful) and review should not take much of time. Both Scott Schurr and Matt Calabrese put quite a lot of effort into their work.
Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value;
*** implementation I expected the binary_int to be in boost namespace. I would expect use of mpl maths on binary_int e.g typedef boost::binary_int<0001> left; typedef boost::binary_int<0010> up; typedef mpl::or_<left,up> left_n_up; I understand about use of enums, however they can cause problems in addition where some compilers dont recognise e.g addition of two enums etc. *** design I would expect value_type to reflect the number of nibbles e.g boost::binary_int<0000,0001> // unsigned char boost::binary_int<0000,0000,0001> // unsigned short or unsigned int dependent on platform dependent type Traditionally these types are regarded as unsigned are they not? Often they are used for port flags which require a specific size which may be 8 bits and will then require a downcast in some cases. Should have the self 'type' member Overall the use of nibbles I like. I find the comma separators between nibbles good. Without them it is often difficult to find out where you are in a mask. This is how I like to work when using bitmasks. *** implementation I didnt look closely. *** documentation I found it a bit sparse, because there are no operations etc. On structure I believe that the documentation should be separate from the utility stuff. Personally I think separation of any stuff into utility is a bit arbitrary anyway as most of boost libraries are utility . It is not the same as the usual boost format making documentation for e.g enable_if hard to find. *** Use the library? I tried it out in VC7.1.No problems, but not much functionality... Lack of bost namespace was unexpected. I thought this was a requirement on proposals? ** should it be a Boost library? Yes, but only on condition that the library is much more fleshed out. Overall I like the idea, but I dont think that it has been worked on enough yet. It should have the masking operations. They should probably use the mpl operators. I also beleive that binary literals should be part of the languge anyway.
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
I prefer templates to macros. , so I prefer Scott Schurrs version. I also happen to like the nibble separators. Also I would like a bit of separate documentation. regards Andy Little
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
I would expect value_type to reflect the number of nibbles e.g
boost::binary_int<0000,0001> // unsigned char boost::binary_int<0000,0000,0001> // unsigned short or unsigned int dependent on platform dependent type
2.13.1 Integer literals, bullet 2 states If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be represented: int, unsigned int, long int, unsigned long int. I would expect the same for binary_literal. -- Alexander Nasonov
"Alexander Nasonov" wrote
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
I would expect value_type to reflect the number of nibbles e.g
boost::binary_int<0000,0001> // unsigned char boost::binary_int<0000,0000,0001> // unsigned short or unsigned int dependent on platform dependent type
2.13.1 Integer literals, bullet 2 states
If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be represented: int, unsigned int, long int, unsigned long int.
I would expect the same for binary_literal.
I'd prefer to have 8 bit math available... but I take your point. BTW In my exmple I should have used bitor rather than or from my previous post ...... I expected the binary_int to be in boost namespace. I would expect use of mpl maths on binary_int e.g typedef boost::binary_int<0001> left; typedef boost::binary_int<0010> up; typedef mpl::bitor_<left,up>::type left_n_up; ..... cheers Andy Little
Pavel Vozenilek <pavel_vozenilek <at> hotmail.com> writes:
Reviews of binary int utility are needed. The tool is very small (but useful) and review should not take much of time. Both Scott Schurr and Matt Calabrese put quite a lot of effort into their work.
Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value;
I vote not to accept this library for the following reasons: 1. No documentation 2. It's not clear whether it's supposed to be an int constant or a literal. These are different things. The former is always int while the latter has different types depending on constant's value. Refer to 2.13.1/2. 2a. If it's supposed to be an int constant, then I expect one class template for every integral type. 2b. If it's supposed to be a literal, then it should obey 2.13.1/2 rules as if the literal were octal. 3. I expect integration with MPL.
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
This version looks better to me. There is no contradiction with 2.13.1/2 rules. I don't like BOOST_SUFFIXED_BINARY_LITERAL much, though. Is it possible to get rid of it and to use BOOST_BINARY_LITERAL( 0000 0110U ) instead? -- Alexander Nasonov
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
This version looks better to me. There is no contradiction with 2.13.1/2 rules. I don't like BOOST_SUFFIXED_BINARY_LITERAL much, though. Is it possible to get rid of it and to use BOOST_BINARY_LITERAL( 0000 0110U ) instead?
It is possible, but requires quite a few more macros to implement (approximately double). How about: BOOST_BINARY_LITERAL(...) BOOST_BINARY_LITERAL_U(...) BOOST_BINARY_LITERAL_L(...) BOOST_BINARY_LITERAL_UL(...) (etcetera, if we need/want long long support) All of these are easy to implement. BTW, is there any reason why we couldn't go with just 'BOOST_BINARY'? Regards, Paul Mensonides
Paul Mensonides <pmenso57 <at> comcast.net> writes:
It is possible, but requires quite a few more macros to implement (approximately double). How about:
BOOST_BINARY_LITERAL(...) BOOST_BINARY_LITERAL_U(...) BOOST_BINARY_LITERAL_L(...) BOOST_BINARY_LITERAL_UL(...)
(etcetera, if we need/want long long support)
It looks nice.
All of these are easy to implement. BTW, is there any reason why we couldn't go with just 'BOOST_BINARY'?
This one is even better. -- Alexander Nasonov
"Paul Mensonides" <pmenso57@comcast.net> writes:
boost-bounces@lists.boost.org wrote:
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
This version looks better to me.
I'm also more inclined towards the macro version (with Paul's suggested name change), although if we got some of the MPL interoperability things that Andy Little mentioned, and of course the absolutely _essential_ documentation, I might be inclined the other way.
BTW, is there any reason why we couldn't go with just 'BOOST_BINARY'?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
This version looks better to me.
I'm also more inclined towards the macro version (with Paul's suggested name change), although if we got some of the MPL interoperability things that Andy Little mentioned, and of course the absolutely _essential_ documentation, I might be inclined the other way.
I think a template-based version is unacceptable for one primary reason. To the template mechanism, 001 and 0001 are the same thing. That is a bad thing when specifying groups of binary bits, as the groupings are often not simple four-bit groupings. The macro version can differentiate between the two, and can specify any pattern of bit groups. Other then the ability to tack UL (etc.) onto the end, it isn't a great strength that the macro produces a literal--only that it produces a compile-time constant suitably typed. IMO, as far as this is concerned, the template-based version and the macro-based version are more-or-less equivalent. The great strength of the macro version is the support for arbitrary bit groupings. Regards, Paul Mensonides
"Paul Mensonides" <pmenso57@comcast.net> wrote
more-or-less equivalent. The great strength of the macro version is the support for arbitrary bit groupings.
Might be an idea to remind of macro weakneses * Macro doesnt respect namespaces. * Macro can be redefined * Macro is global cheers Andy Little
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little
"Paul Mensonides" <pmenso57@comcast.net> wrote
more-or-less equivalent. The great strength of the macro version is the support for arbitrary bit groupings.
Might be an idea to remind of macro weakneses
* Macro doesnt respect namespaces.
The macro is namespace prefixed--specifically 'BOOST_'. For all intents and purposes (i.e. categorizing, interfacing, and avoiding collision), 'BOOST_NAME' is equivalent to saying 'boost::name'.
* Macro can be redefined
That would violate the contract that Boost has with its users. Unless explicitly specified as otherwise for a particular case in the documentation, the namespace ::boost and any name prefixed with BOOST_ is unilaterally reserved by Boost. Besides, we don't need to protect against intentional misuse.
* Macro is global
So is '::boost::name', that is, it is just as globally accessible. Sure, 'name' in '::boost::name' isn't global, but neither is 'NAME' in 'BOOST_NAME'. Regards, Paul Mensonides
On 10/21/05, Paul Mensonides <pmenso57@comcast.net> wrote:
Other then the ability to tack UL (etc.) onto the end, it isn't a great strength that the macro produces a literal--only that it produces a compile-time constant suitably typed.
Another somewhat nice side-effect is that since it resolves to an octal literal, you get a more readable error message if your value is too large. For instance, in VC++ 7.1, if I try to make a literal over 8 bytes in size, I get a single, easy-to-read message, which is consistent with the errors I'd get with hex or octal literals: error C2177: constant too big -- -Matt Calabrese
"Paul Mensonides" <pmenso57@comcast.net> writes:
I think a template-based version is unacceptable for one primary reason. To the template mechanism, 001 and 0001 are the same thing. That is a bad thing when specifying groups of binary bits, as the groupings are often not simple four-bit groupings. The macro version can differentiate between the two, and can specify any pattern of bit groups. Other then the ability to tack UL (etc.) onto the end, it isn't a great strength that the macro produces a literal--only that it produces a compile-time constant suitably typed. IMO, as far as this is concerned, the template-based version and the macro-based version are more-or-less equivalent. The great strength of the macro version is the support for arbitrary bit groupings.
I guess I consider that a non-essential but very-nice-to-have feature. So I wouldn't go as far as labelling the template-based approach "unacceptable," but that does tilt me strongly back towards the macro approach. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 10/21/05, Paul Mensonides <pmenso57@comcast.net> wrote:
BOOST_BINARY_LITERAL(...) BOOST_BINARY_LITERAL_U(...) BOOST_BINARY_LITERAL_L(...) BOOST_BINARY_LITERAL_UL(...)
One reason I'd prefer not to do that is because as it stands, you can use any suffixes you want with the literal, including suffixes which are provided as extensions with your particular compiler, such as to specify 64-bit ints and 64-bit unsigned ints, etc. If the length of BOOST_SUFFIXED_BINARY_LITERAL is what is not liked, it could be changed to BOOST_SUFFIXED_BITS or something like that. I only wanted BINARY_LITERAL in the name as opposed to just BINARY or BITS to stress that it is, in fact, a literal. The result of the macro is an octal literal and can be used as such. If it's really disliked that much, I don't mind changing it to whatever is wanted. Also, it was unmentioned in this post, but arbitrary groupings of bits are supported up to 8 bits per group, such as BOOST_BINARY_LITERAL( 11001001 00 00011 1101 00 11 ), as per suggestion by Paul during development. I'd like to write up documentation and rationale this weekend to cover all of this and I really should have had it done and uploaded already, but I've been going crazy with work and am also currently developing a units library for boost and am a part of a long discussion on it as well. I seem to be spending 95% of my day coding and engineering libraries in front of a computer screen and it's becoming tough to balance what needs to be done first. -- -Matt Calabrese
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Calabrese On 10/21/05, Paul Mensonides <pmenso57@comcast.net> wrote:
BOOST_BINARY_LITERAL(...) BOOST_BINARY_LITERAL_U(...) BOOST_BINARY_LITERAL_L(...) BOOST_BINARY_LITERAL_UL(...)
One reason I'd prefer not to do that is because as it stands, you can use any suffixes you want with the literal, including suffixes which are provided as extensions with your particular compiler, such as to specify 64-bit ints and 64-bit unsigned ints, etc.
I think it is reasonable for us to provide the standard suffixes and maybe the long long suffixes. If users want other extension suffixes, they can do it fairly easily with BOOST_PP_CAT (the macro does produce a literal, after all).
If the length of BOOST_SUFFIXED_BINARY_LITERAL is what is not liked, it could be changed to BOOST_SUFFIXED_BITS or something like that. I only wanted BINARY_LITERAL in the name as opposed to just BINARY or BITS to stress that it is, in fact, a literal.
Documentation should be enough for that.
The result of the macro is an octal literal and can be used as such. If it's really disliked that much, I don't mind changing it to whatever is wanted.
As a convenience utility, convenience is important. If the macro name is too long, people will find it "nicer to look at" to just do the octal conversion themselves. Regards, Paul Mensonides
Alexander Nasonov <alnsn-boost <at> yandex.ru> writes:
Pavel Vozenilek <pavel_vozenilek <at> hotmail.com> writes:
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
This version looks better to me. There is no contradiction with 2.13.1/2 rules. I don't like BOOST_SUFFIXED_BINARY_LITERAL much, though. Is it possible to get rid of it and to use BOOST_BINARY_LITERAL( 0000 0110U ) instead?
Sorry for not being clear about Matt Calabrese's version. I vote to accept it into boost. -- Alexander Nasonov
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
Reviews of binary int utility are needed. The tool is very small (but useful) and review should not take much of time. Both Scott Schurr and Matt Calabrese put quite a lot of effort into their work.
Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value;
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
Is there some rationale that describes how useful these libraries are somewhere? Are we running simultaneous reviews for two separate librareis? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams"
Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value;
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
Is there some rationale that describes how useful these libraries are somewhere?
Scott's library has HTML file with section on binary_int. How to use Matt's version is described in http://lists.boost.org/Archives/boost/2005/09/93007.php
Are we running simultaneous reviews for two separate librareis?
People should pick which utility (if any) fits into Boost. That there are two alternatives is lucky accident. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
"David Abrahams"
Scott Schurr's version is in http://boost-consulting.com/vault/ (file binary_int.zip). It can be used as: unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value;
Matt Calabrese's version is in http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. It can be used as: int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 );
Is there some rationale that describes how useful these libraries are somewhere?
Scott's library has HTML file with section on binary_int. How to use Matt's version is described in http://lists.boost.org/Archives/boost/2005/09/93007.php
This is a question about usefulness, not about "how to use."
Are we running simultaneous reviews for two separate librareis?
People should pick which utility (if any) fits into Boost.
That there are two alternatives is lucky accident.
I don't think either of your replies actually answers the questions I was asking. Care to try again? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams"
Is there some rationale that describes how useful these libraries are somewhere?
Not in docs. But it has quite obvious value e.g. for those working on control systems, for example.
Are we running simultaneous reviews for two separate librareis?
No. The review is about small utility which has two alternative implementations. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
"David Abrahams"
Is there some rationale that describes how useful these libraries are somewhere?
Not in docs. But it has quite obvious value e.g. for those working on control systems, for example.
Yes, but that doesn't (necessarily) mean it is widely useful enough to belong in Boost. For those of us having limited imagination, it would be a good idea to have that rationale in the docs.
Are we running simultaneous reviews for two separate librareis?
No. The review is about small utility which has two alternative implementations.
Clearly the interfaces are markedly different too. It's not one small utility; it's two. So I guess the answer is "yes." It's a bit unusual for us, but I guess there's nothing wrong with ti. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Like others, I suspect, I have hesitated before expressing views on these useful utilities, as I have no strong views or knowledge, except an incredulity that the LANGUAGE should not have a way of specifying binary input - and that there that this hasn't been mentioned for C++0x. Surely binary has always been MUCH more useful than octal? Having briefly perused both offerings, and read expert views on them, I conclude that neither is in a polished state, but that both have their merits, and I agree that there is room for BOTH in Boost, and no comelling reason to make a choice. I therefore support acceptance of BOTH, subject to MAJOR improvement of documentation, examples, rationale, including the pros and cons, and cross reference to the 'other way of doing it'. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Vozenilek | Sent: 21 October 2005 02:10 | To: boost@lists.boost.org | Subject: [boost] [ongoing review of binary_int] reviewers for | small utilitywanted | | Reviews of binary int utility are needed. The tool is very small (but | useful) and review should not take much of time. Both Scott | Schurr and Matt | Calabrese put quite a lot of effort into their work. | | | Scott Schurr's version is in http://boost-consulting.com/vault/ (file | binary_int.zip). | It can be used as: | unsigned int regValue2 = binary_int<1000,1001,0011,0000>::value; | | | Matt Calabrese's version is in | http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp. | It can be used as: | int x = BOOST_BINARY_LITERAL( 101 0111 1010 0110 ); | | | /Pavel | | | | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
From: "Paul A Bristow" <pbristow@hetp.u-net.com>
Like others, I suspect, I have hesitated before expressing views on these useful utilities, as I have no strong views or knowledge, except an incredulity that the LANGUAGE should not have a way of specifying binary input - and that there that this hasn't been mentioned for C++0x. Surely binary has always been MUCH more useful than octal?
Ditto.
Having briefly perused both offerings, and read expert views on them, I conclude that neither is in a polished state, but that both have their merits, and I agree that there is room for BOTH in Boost, and no comelling reason to make a choice.
I therefore support acceptance of BOTH, subject to MAJOR improvement of documentation, examples, rationale, including the pros and cons, and cross reference to the 'other way of doing it'.
I came to the same conclusion, now that I've read through the review threads on the two libraries. My question was why not provide both means in one library? Those that like the balance of forces in the template version better can use that version. Those that prefer the balance in the macro version can use that version. Thus, the two need to be merged inasmuch as possible. At the very least, the documentation can be merged and tradeoffs can be presented to allow for an informed choice between the versions. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (8)
-
Alexander Nasonov -
Andy Little -
David Abrahams -
Matt Calabrese -
Paul A Bristow -
Paul Mensonides -
Pavel Vozenilek -
Rob Stewart