[xint] Sixth release, preliminary review again please
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.zip&directory=&>). I think it's nearly ready for an official review. :-) The changes between this release and the last one are: * Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation. * Minor redesign, taking advantage of proper policy-based design. nan() and operator~() are now only available on nothrow and fixedlength types, respectively, and is_nan() gets different definitions in the standard and nothrow types. * Added unsigned support, by request, with a variety of options for what to do when a calculation results in a negative number. * Added the difference function. * Added support for wide-character strings, by request. * Added the safe-bool idiom, by request. This release, like the last ones, includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. Still on my immediate to-do list: * Add support for GCC's -fno-exceptions option. * Add more examples. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwcD6UACgkQp9x9jeZ9/wSfTwCfTMiucMP3uho9YmGJCyzMPe+s MhwAoMUe9tnFTHpQVDkCIfWiwpCjcuZi =QS39 -----END PGP SIGNATURE-----
At Fri, 18 Jun 2010 20:30:33 -0400, Chad Nelson wrote:
The changes between this release and the last one are:
* Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation.
I think you might want to clarify that, since “parameter” has a general meaning having nothing to do with the library.
* Minor redesign, taking advantage of proper policy-based design.
I've always wondered about this: is there a description somewhere of what constitutes “proper policy-based design?” I've never felt confident that I understood exactly what PBD is. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2010 10:22 PM, David Abrahams wrote:
The changes between this release and the last one are:
* Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation.
I think you might want to clarify that, since “parameter” has a general meaning having nothing to do with the library.
The general meaning is the one I had in mind. :-) fixedlength is one of the structs that I use for Boost.Parameter; it takes a (small-p) parameter of a length, in bits. The other structs previously took a Boolean parameter, but now they don't -- their mere existence, or lack thereof, is enough to tell the Boost.Parameter-enabled classes what to do. It was the first time I'd used Boost.Parameter on a class template. I wasn't able to find any examples of how to use it for that, other than the sole one in the documentation, so the learning curve was pretty steep. That's why the aforementioned "other structs" took a parameter even though they really didn't need one, it was my first attempt. If you ever feel the urge to update the documentation with more examples, please feel free to use XInt's integer_t class, I'm sure the next guy who tries to learn it would appreciate it.
* Minor redesign, taking advantage of proper policy-based design.
I've always wondered about this: is there a description somewhere of what constitutes “proper policy-based design?” I've never felt confident that I understood exactly what PBD is.
Just going by what I read around the 'net (since I don't have a copy of Alexandrescu's "Modern C++ Design", and didn't want to wait for one to be delivered from Amazon), it looks like it involves using one or more class templates, specialized to perform the same task in different ways depending on its parameters. I didn't find a single page that described it really well, I went through about a dozen of them to figure it out. I'm sure someone will correct me if I've got it wrong, but here's the way I'm using it in XInt. I've got several "policy" classes: nan_functions (which handles the differences between nothrow-integers and exception-based integers having to do with the Not-a-Number value), fixed_functions (handles the high-level differences between fixed-length and variable-length integers), and unsigned_negative_functions (which handles the various behaviors of unsigned types when confronted with negative values). Each of those is a class template itself, and takes one or more parameters describing which of the various policies it should implement. integer_t uses each of those policy classes as base classes. The parameters determine which version of the policy class it gets, via specialization. To make things clearer, here's a stripped-down version of fixed_functions: template <bitsize_t Bits, typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions: virtual public integer_t_data<BOOST_XINT_APARAMS> { public: T operator~() const { [...] } }; template <typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions<0, T, BOOST_XINT_APARAMS>: virtual public integer_t_data<BOOST_XINT_APARAMS> { // Nothing needed here at present. }; If the number of bits is zero, it means the integer is variable-length; any non-zero value means fixed-length. As you can see above, fixed-length types automatically inherit an operator~ function; variable-length ones, thanks to the specialization for zero bits, don't. A better example might be unsigned_negative_functions, which has a _fix_negative_unsigned function that's different for each of the six specializations, but it's not as easy to explain. For those playing the home game, the code responsible for all this is in the bottom half of boost/xint/detail/options.hpp (the top half of it deals with Boost.Parameter stuff). Feel free to ask if you have any questions... as you can probably tell from the above, I enjoy explaining things. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwcUMQACgkQp9x9jeZ9/wRsvQCfYkm5K/m25wMJ4dfo6obeP6Nk r/sAoM64Un0Guc4Ud/xLINe7Rh0NZccd =fcYp -----END PGP SIGNATURE-----
At Sat, 19 Jun 2010 01:08:37 -0400, Chad Nelson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/18/2010 10:22 PM, David Abrahams wrote:
The changes between this release and the last one are:
* Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation.
I think you might want to clarify that, since “parameter” has a general meaning having nothing to do with the library.
The general meaning is the one I had in mind. :-) fixedlength is one of the structs that I use for Boost.Parameter; it takes a (small-p) parameter of a length, in bits. The other structs previously took a Boolean parameter, but now they don't -- their mere existence, or lack thereof, is enough to tell the Boost.Parameter-enabled classes what to do.
So you're using a “deduced parameter” interface, I presume.
It was the first time I'd used Boost.Parameter on a class template. I wasn't able to find any examples of how to use it for that, other than the sole one in the documentation, so the learning curve was pretty steep. That's why the aforementioned "other structs" took a parameter even though they really didn't need one, it was my first attempt. If you ever feel the urge to update the documentation with more examples, please feel free to use XInt's integer_t class, I'm sure the next guy who tries to learn it would appreciate it.
If you could be more specific about what you found missing from the docs, that might help.
* Minor redesign, taking advantage of proper policy-based design.
I've always wondered about this: is there a description somewhere of what constitutes “proper policy-based design?” I've never felt confident that I understood exactly what PBD is.
Just going by what I read around the 'net (since I don't have a copy of Alexandrescu's "Modern C++ Design", and didn't want to wait for one to be delivered from Amazon), it looks like it involves using one or more class templates, specialized to perform the same task in different ways depending on its parameters. I didn't find a single page that described it really well, I went through about a dozen of them to figure it out.
I'm sure someone will correct me if I've got it wrong, but here's the way I'm using it in XInt. I've got several "policy" classes: nan_functions (which handles the differences between nothrow-integers and exception-based integers having to do with the Not-a-Number value), fixed_functions (handles the high-level differences between fixed-length and variable-length integers), and unsigned_negative_functions (which handles the various behaviors of unsigned types when confronted with negative values). Each of those is a class template itself, and takes one or more parameters describing which of the various policies it should implement.
integer_t uses each of those policy classes as base classes. The parameters determine which version of the policy class it gets, via specialization.
To make things clearer, here's a stripped-down version of fixed_functions:
template <bitsize_t Bits, typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions: virtual public integer_t_data<BOOST_XINT_APARAMS> { public: T operator~() const { [...] } };
template <typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions<0, T, BOOST_XINT_APARAMS>: virtual public integer_t_data<BOOST_XINT_APARAMS> { // Nothing needed here at present. };
If the number of bits is zero, it means the integer is variable-length; any non-zero value means fixed-length. As you can see above, fixed-length types automatically inherit an operator~ function; variable-length ones, thanks to the specialization for zero bits, don't.
A better example might be unsigned_negative_functions, which has a _fix_negative_unsigned function that's different for each of the six specializations, but it's not as easy to explain.
For those playing the home game, the code responsible for all this is in the bottom half of boost/xint/detail/options.hpp (the top half of it deals with Boost.Parameter stuff). Feel free to ask if you have any questions... as you can probably tell from the above, I enjoy explaining things. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwcUMQACgkQp9x9jeZ9/wRsvQCfYkm5K/m25wMJ4dfo6obeP6Nk r/sAoM64Un0Guc4Ud/xLINe7Rh0NZccd =fcYp -----END PGP SIGNATURE----- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/18/2010 10:22 PM, David Abrahams wrote:
I think you might want to clarify that, since parameter has a general meaning having nothing to do with the library.
The general meaning is the one I had in mind. :-) fixedlength is one of the structs that I use for Boost.Parameter; it takes a (small-p) parameter of a length, in bits. The other structs previously took a Boolean parameter, but now they don't -- their mere existence, or lack thereof, is enough to tell the Boost.Parameter-enabled classes what to do.
So you're using a deduced parameter interface, I presume.
Yes. I couldn't figure out how to directly pass value, rather than type, parameters to class templates... I can't tell if I missed something or if it's just not possible (I suspect the latter, but read on). Since I had to create a type for everything anyway, and there aren't any required parameters, the deduced interface made perfect sense.
It was the first time I'd used Boost.Parameter on a class template. I wasn't able to find any examples of how to use it for that, other than the sole one in the documentation, so the learning curve was pretty steep. That's why the aforementioned "other structs" took a parameter even though they really didn't need one, it was my first attempt. If you ever feel the urge to update the documentation with more examples, please feel free to use XInt's integer_t class, I'm sure the next guy who tries to learn it would appreciate it.
If you could be more specific about what you found missing from the docs, that might help.
In general, the biggest problem I found was that there was only the one example of how to use it on class templates. I couldn't tell which of the design decision you'd made on it were universal, and which you might have made differently under different circumstances. Using Boost.Parameter on class templates seems very different from using it on anything else, so my previous experiences with it didn't help as much as I expected in figuring out the best way to use it there. With more than one example, I could have gotten a better idea of what was possible, and where I could best use those abilities. I also had some trouble figuring out how to pass values (again, rather than types) to the class template in a way that MSVC would accept. Writing a class template that takes the value is easy enough for any reasonably competent C++ developer to figure out, but finding a way to actually *use* that value (as, for instance, a parameter to a non-Boost.Parameter-enabled class template) in MSVC was maddening, until I stumbled across integral_c. MSVC claims that such parameters aren't compile-time constants; GCC doesn't have any problem with them. That's a problem that many people won't run across, but I'd think that it's common enough to frustrate a good portion of people trying to use Boost.Parameter. (It did occur to me to try creating a class with a non-explicit conversion constructor for the type that I wanted to pass in, but I was put off by the limitations described in type_traits' is_convertible function -- that it doesn't work with C++ Builder 5 or earlier, or Metrowerks 7 or earlier. I don't know how commonly used those are, and I didn't want to limit the people who can use XInt, so I didn't attempt it.) I'm not criticizing the existing Boost.Parameter documentation. It was thorough, and sufficient to show me what I needed to do. I just would have felt more comfortable with it, and understood it more quickly, if I'd had a second example to compare to the first. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkweP0QACgkQp9x9jeZ9/wSKbwCaAn1z0sbHudjxmQv09p5KSgW1 HVgAnRQlzvGTZWcYGd/wcOdp5IwkFj9A =ixaf -----END PGP SIGNATURE-----
At Sun, 20 Jun 2010 12:18:16 -0400, Chad Nelson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/18/2010 10:22 PM, David Abrahams wrote:
I think you might want to clarify that, since parameter has a general meaning having nothing to do with the library.
The general meaning is the one I had in mind. :-) fixedlength is one of the structs that I use for Boost.Parameter; it takes a (small-p) parameter of a length, in bits. The other structs previously took a Boolean parameter, but now they don't -- their mere existence, or lack thereof, is enough to tell the Boost.Parameter-enabled classes what to do.
So you're using a deduced parameter interface, I presume.
Yes. I couldn't figure out how to directly pass value, rather than type, parameters to class templates... I can't tell if I missed something or if it's just not possible (I suspect the latter, but read on).
Not supported by the library; you have to use wrappers.
Since I had to create a type for everything anyway, and there aren't any required parameters, the deduced interface made perfect sense.
Yeah, it works particularly well for template parameters.
It was the first time I'd used Boost.Parameter on a class template. I wasn't able to find any examples of how to use it for that, other than the sole one in the documentation, so the learning curve was pretty steep. That's why the aforementioned "other structs" took a parameter even though they really didn't need one, it was my first attempt. If you ever feel the urge to update the documentation with more examples, please feel free to use XInt's integer_t class, I'm sure the next guy who tries to learn it would appreciate it.
If you could be more specific about what you found missing from the docs, that might help.
In general, the biggest problem I found was that there was only the one example of how to use it on class templates. I couldn't tell which of the design decision you'd made on it were universal, and which you might have made differently under different circumstances. Using Boost.Parameter on class templates seems very different from using it on anything else, so my previous experiences with it didn't help as much as I expected in figuring out the best way to use it there. With more than one example, I could have gotten a better idea of what was possible, and where I could best use those abilities.
Patches welcome :-)
I also had some trouble figuring out how to pass values (again, rather than types) to the class template in a way that MSVC would accept. Writing a class template that takes the value is easy enough for any reasonably competent C++ developer to figure out, but finding a way to actually *use* that value (as, for instance, a parameter to a non-Boost.Parameter-enabled class template) in MSVC was maddening, until I stumbled across integral_c. MSVC claims that such parameters aren't compile-time constants; GCC doesn't have any problem with them. That's a problem that many people won't run across, but I'd think that it's common enough to frustrate a good portion of people trying to use Boost.Parameter.
(It did occur to me to try creating a class with a non-explicit conversion constructor for the type that I wanted to pass in, but I was put off by the limitations described in type_traits' is_convertible function -- that it doesn't work with C++ Builder 5 or earlier, or Metrowerks 7 or earlier. I don't know how commonly used those are, and I didn't want to limit the people who can use XInt, so I didn't attempt it.)
I'm not criticizing the existing Boost.Parameter documentation. It was thorough, and sufficient to show me what I needed to do. I just would have felt more comfortable with it, and understood it more quickly, if I'd had a second example to compare to the first.
And I don't feel criticized, so no harm no foul. I am asking because I'd like to know if we could do something better. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/20/2010 12:34 PM, David Abrahams wrote:
So you're using a deduced parameter interface, I presume.
Yes. I couldn't figure out how to directly pass value, rather than type, parameters to class templates... I can't tell if I missed something or if it's just not possible (I suspect the latter, but read on).
Not supported by the library; you have to use wrappers.
Nice to have confirmation on that. It wasn't obvious.
If you could be more specific about what you found missing from the docs, that might help.
In general, the biggest problem I found was that there was only the one example of how to use it on class templates. [...]
Patches welcome :-)
I was just waiting for an invitation. :-) I'll work one up, you'll have it by Friday at the latest. My writing style probably won't fit with yours, I hope that won't be a problem. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkweqh8ACgkQp9x9jeZ9/wSHtwCg01LzahOwItW3W6c34VGPqqnZ te0Ani2qPLo95HFfUGlki4kzxiZaQtrV =lHi5 -----END PGP SIGNATURE-----
At Sun, 20 Jun 2010 19:54:10 -0400, Chad Nelson wrote:
I was just waiting for an invitation. :-) I'll work one up, you'll have it by Friday at the latest. My writing style probably won't fit with yours, I hope that won't be a problem.
Nope; editing is easier than writing. Thanks for the hand. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-20 09:13 PM, David Abrahams wrote:
I was just waiting for an invitation. :-) I'll work one up, you'll have it by Friday at the latest. My writing style probably won't fit with yours, I hope that won't be a problem.
Nope; editing is easier than writing. Thanks for the hand.
My pleasure! I'm attaching the example (which fits into your documentation just under the existing class template example) and the final code for it. Let me know if I got anything wrong, or if there's anything that needs changing. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwjkAoACgkQp9x9jeZ9/wQpqQCgsJjFAzSoD40QZfzsHmJegQ+w 8ssAnjctgEsG2ZEayjD6RG4PogxHwTX5 =scN5 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-18 08:30 PM, Chad Nelson wrote:
The next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.zip&directory=&>).
I think it's nearly ready for an official review. :-)
No one has mentioned any objections to it in the week since I posted the latest version. Does that mean that there aren't any problems with it, or that no one has looked at it? ;-) To anyone interested in it, please answer this: do you think it's ready for official review? I've still got some minor additions to make to the documentation, but unless someone comes up with a problem, the version of the code in the Sandbox should be pretty much complete. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwk1a4ACgkQp9x9jeZ9/wTUgACfWiz7DXvRxduenoePVhEsFlpc v7gAnA/yQzDzMO+7czC4vQpJC/Oo07Hj =dPTZ -----END PGP SIGNATURE-----
on 25.06.2010 at 20:13 Chad Nelson wrote :
No one has mentioned any objections to it in the week since I posted the latest version. Does that mean that there aren't any problems with it, or that no one has looked at it? ;-)
To anyone interested in it, please answer this: do you think it's ready for official review?
I've still got some minor additions to make to the documentation, but unless someone comes up with a problem, the version of the code in the Sandbox should be pretty much complete.
i'd say it's pretty much complete for a review i looked at it but when i wanted to say a thing about it it turned out someone else has already said that anyway making it into boost once you can always make xint 2.0 with slight improvements (over the previous version) one more thing: i liked it better when arbitrary sized integer and fixed integer were distinct classes good luck with the review! -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-28 07:09 AM, DE wrote:
To anyone interested in it, please answer this: do you think it's ready for official review?
i'd say it's pretty much complete for a review i looked at it but when i wanted to say a thing about it it turned out someone else has already said that
Great minds think alike. ;-)
anyway making it into boost once you can always make xint 2.0 with slight improvements (over the previous version)
There are several improvements I intend to make in future releases, but I'd like to get the first version out there and work out any bugs first.
one more thing: i liked it better when arbitrary sized integer and fixed integer were distinct classes
What did you like about it, that the current design doesn't have? Maybe I can make the current one work that way too.
good luck with the review!
Thanks! The lack of responses has me seriously considering delaying it though... you're only the second person to respond since I asked. I suspect that a lot of people are out on vacation right now, so maybe it would be better to put it off for a couple months. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwoyQEACgkQp9x9jeZ9/wQHAQCgjzrMQe0zSDEzq1ZAlFTqrvue ICwAnibJgVzPIMKLrWd5Tmxv1H7jGB18 =/Kao -----END PGP SIGNATURE-----
On 28 Jun 2010, at 17:08, Chad Nelson wrote:
good luck with the review!
Thanks! The lack of responses has me seriously considering delaying it though... you're only the second person to respond since I asked. I suspect that a lot of people are out on vacation right now, so maybe it would be better to put it off for a couple months.
You have been very thorough with your preliminary reviews, in quick succession. I can't say for sure, but I think most people's initial issues have been addressed, but possibly people are unwilling to do deep reviews, at this, the sixth release! I would advise submitting for review. I would like to see the library in boost. Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-28 02:18 PM, Christopher Jefferson wrote:
Thanks! The lack of responses has me seriously considering delaying it though... [...]
You have been very thorough with your preliminary reviews, in quick succession. I can't say for sure, but I think most people's initial issues have been addressed, but possibly people are unwilling to do deep reviews, at this, the sixth release!
You're probably right. I know I shouldn't expect anyone else to be as interested in it as I am, but somehow that often slips my mind.
I would advise submitting for review. I would like to see the library in boost.
That makes two of us. :-) I've just gone over the submission requirements again, and found a few things that I still need to do. I'll request a full review as soon as they're finished, maybe in a week or two. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwqDVAACgkQp9x9jeZ9/wSbOACcCVWZ6dM7nTSIj1RiQL6/R7Bc 7MAAn1AEEd9RRGAQjVEIPd4HT6o3IvJz =qIkv -----END PGP SIGNATURE-----
on 28.06.2010 at 20:08 Chad Nelson wrote :
one more thing: i liked it better when arbitrary sized integer and fixed integer were distinct classes
What did you like about it, that the current design doesn't have? Maybe I can make the current one work that way too.
from a user point of view i find it more convenient when distinct entities are responsible for distinct well defined tasks in this case i don't like the all-in-one solution because fusion of these distinct things involves mixing of completely unrelated details e.g. lets say unbounded integer by definition has no signedness (it is always signed) but on the other hand finite representation (like binary 2's complement or other) has well defined concepts of signed/unsigned integers i like that error behavor is now a parameter of a template because in fact it just controls such a small detail that we actually don't expect to show itself at all contrary, unbounded and bounded integers cover slightly different scopes all this is just my personal complaint so don't take it too close -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-29 07:41 AM, DE wrote:
one more thing: i liked it better when arbitrary sized integer and fixed integer were distinct classes
What did you like about it, that the current design doesn't have? Maybe I can make the current one work that way too.
from a user point of view i find it more convenient when distinct entities are responsible for distinct well defined tasks in this case i don't like the all-in-one solution because fusion of these distinct things involves mixing of completely unrelated details e.g. lets say unbounded integer by definition has no signedness (it is always signed) but on the other hand finite representation (like binary 2's complement or other) has well defined concepts of signed/unsigned integers
I prefer distinct classes for logically distinct purposes as well, but several people recommended combining them. And I have to admit, the code will be a lot easier to maintain that way.
i like that error behavor is now a parameter of a template because in fact it just controls such a small detail that we actually don't expect to show itself at all
contrary, unbounded and bounded integers cover slightly different scopes
You might be surprised at how similar they are though, and how few code changes are really needed between them.
all this is just my personal complaint so don't take it too close
I'll try not to. :-) One thing I considered was (re)adding a fixed_integer class, which took the same parameters as the integer_t class but made the fixedlength one mandatory. I abandoned the idea because, although logically tempting, there was no practical benefit to it, and I'd have to duplicate a lot of code to do it. In any case, since you'll almost certainly be using typedefs to identify the different types of integers used, your code should be just as readable with only integer_t as it would with fixed_integer. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwqEL0ACgkQp9x9jeZ9/wS+/ACg24p0V3JhRJ11thVIDVbN3cmU pHwAoJMZZ1LOJ4NKXUFayf2J+4hZx41k =Df9W -----END PGP SIGNATURE-----
participants (4)
-
Chad Nelson -
Christopher Jefferson -
David Abrahams -
DE