Second iteration of Boost.XInt library uploaded, requesting further comments
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just uploaded the second iteration of the Boost.XInt library to the Boost Vault. I very much appreciate all of the comments and suggestions everyone has offered on the first one, and I've incorporated a number of them. Maybe I'm just a masochist, but please take a look and let me know what you think. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuypFUACgkQp9x9jeZ9/wRD3wCeMKRKaeml9UzhMNTpl15RvBFE pw8AniN8kkXNEFelgY4VYtWNzaCi88cV =lHLU -----END PGP SIGNATURE-----
on 31.03.2010 at 5:24 Chad Nelson wrote :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've just uploaded the second iteration of the Boost.XInt library to the Boost Vault. I very much appreciate all of the comments and suggestions everyone has offered on the first one, and I've incorporated a number of them.
Maybe I'm just a masochist, but please take a look and let me know what you think.
i find 'nan()' member function confusing i would have made 'nan()' a static function returning NaN and renamed the former to 'is_nan()' similarly 'odd()' and 'even()' could be 'is_odd()' and 'is_even()' but these are less confusing to me what others think? by the way does 'token' produced by 'block_exceptions()' presumes the previous state? i.e. does its destructor restore the state its constructor switched from? and are we going to continue in this thread? -- 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 03/31/2010 01:26 PM, DE wrote:
i find 'nan()' member function confusing i would have made 'nan()' a static function returning NaN and renamed the former to 'is_nan()' similarly 'odd()' and 'even()' could be 'is_odd()' and 'is_even()' but these are less confusing to me [...]
The nan function was named that way because it fits in with the naming of the even and odd functions (which n1694 specified). For what it's worth, I agree with you; the constructor taking a not_a_number object was my second choice, not my first.
by the way does 'token' produced by 'block_exceptions()' presumes the previous state? i.e. does its destructor restore the state its constructor switched from?
Yes, it does. That's why they have to be destroyed in the opposite order they were created, or the operation is undefined.
and are we going to continue in this thread?
If anyone wants to. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuz5cUACgkQp9x9jeZ9/wQ4EwCgstJy/Ie31r100Dj08s3y2TPQ VQwAnRgNZFSWoZ2zO8E6JwEL/QV4eQ/i =/Adi -----END PGP SIGNATURE-----
Chad Nelson wrote:
On 03/31/2010 01:26 PM, DE wrote:
i find 'nan()' member function confusing i would have made 'nan()' a static function returning NaN and renamed the former to 'is_nan()' similarly 'odd()' and 'even()' could be 'is_odd()' and 'is_even()' but these are less confusing to me [...]
The nan function was named that way because it fits in with the naming of the even and odd functions (which n1694 specified). For what it's worth, I agree with you; the constructor taking a not_a_number object was my second choice, not my first.
There's still time to change the upcoming standard and you can lead the way now in your library. Consider submitting defects for these things to make future code more readable. _____ 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.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stewart, Robert Sent: Thursday, April 01, 2010 12:26 PM To: boost@lists.boost.org Subject: Re: [boost] Second iteration of Boost.XInt library uploaded, requesting further comments
Chad Nelson wrote:
On 03/31/2010 01:26 PM, DE wrote:
i find 'nan()' member function confusing i would have made 'nan()' a static function returning NaN and renamed the former to 'is_nan()' similarly 'odd()' and 'even()' could be 'is_odd()' and 'is_even()' but these are less confusing to me [...]
The nan function was named that way because it fits in with the naming of the even and odd functions (which n1694 specified). For what it's worth, I agree with you; the constructor taking a not_a_number object was my second choice, not my first.
There's still time to change the upcoming standard and you can lead the way now in your library. Consider submitting defects for these things to make future code more readable.
But the existence of N1694 doesn't mean it is in any way 'Standard'- it is just a suggesting to the WG21 standards group. They didn't rule it out (I think that they were much too busy with other more pressing matters like getting the C++0X standard defined), but they didn't endorse it. is_nan, is_inf ... is part of the C99/TR1/C++0X Standard for *floating-point*, so it would seem only logical to follow this naming. If we are allowing a NaN then testing and copying sign would also seem useful. But let's let Chad get something that everyone can play with in the sandbox first? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
looking at implementation: don't you want to make global integer constants members of enum(s)? as well as static integer constants (haven't noticed so far) i think that enum { bits_per_digit = whatever_it_is, digit_hibit = so_does_this, etc }; is better than global objects (defined in a header) to prove me wrong try to compile two source files including "xint.hpp" and using xint::integer (just for sure) and link them together i expect linker complaints about entities defined in several object files -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
AMDG DE wrote:
looking at implementation: don't you want to make global integer constants members of enum(s)? as well as static integer constants (haven't noticed so far)
i think that
enum { bits_per_digit = whatever_it_is, digit_hibit = so_does_this, etc };
is better than global objects (defined in a header)
to prove me wrong try to compile two source files including "xint.hpp" and using xint::integer (just for sure) and link them together i expect linker complaints about entities defined in several object files
It will not. const size_t bits_per_digit = std::numeric_limits<digit_t>::digits; is equivalent to static const size_t bits_per_digit = std::numeric_limits<digit_t>::digits; In Christ, Steven Watanabe
on 31.03.2010 at 22:18 Steven Watanabe wrote :
It will not. const size_t bits_per_digit = std::numeric_limits<digit_t>::digits; is equivalent to static const size_t bits_per_digit = std::numeric_limits<digit_t>::digits;
i see i'm too lazy too consult the standard but still i think it's a good idea to define compile time constants as enum members can you clear this question for me once and forever, Steven? is it preferable or is it solely a matter of taste? -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
AMDG DE wrote:
on 31.03.2010 at 22:18 Steven Watanabe wrote :
It will not. const size_t bits_per_digit = std::numeric_limits<digit_t>::digits; is equivalent to static const size_t bits_per_digit = std::numeric_limits<digit_t>::digits;
i see i'm too lazy too consult the standard but still i think it's a good idea to define compile time constants as enum members
can you clear this question for me once and forever, Steven? is it preferable or is it solely a matter of taste?
static const size_t is usually better because it has the correct type, and so will behave better for overload resolution. In Christ, Steven Watanabe
on 31.03.2010 at 22:35 Steven Watanabe wrote :
but still i think it's a good idea to define compile time constants as enum members
can you clear this question for me once and forever, Steven? is it preferable or is it solely a matter of taste?
static const size_t is usually better because it has the correct type, and so will behave better for overload resolution.
from that point of view i agree thanks -- 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 03/31/2010 02:35 PM, Steven Watanabe wrote:
i see i'm too lazy too consult the standard but still i think it's a good idea to define compile time constants as enum members
can you clear this question for me once and forever, Steven? is it preferable or is it solely a matter of taste?
static const size_t is usually better because it has the correct type, and so will behave better for overload resolution.
Exactly my point. But while we're on the subject: considering that those are in a namespace (so they don't pollute the global namespace), and are constants, is there any particular reason to use or not use "static" in the declarations? - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuz6J8ACgkQp9x9jeZ9/wQ4IQCgy3lZdFFzpveZw0PgLamsntEl A2MAn2odOrwWxPCxc3lB9T75YV4MiiRh =cdqg -----END PGP SIGNATURE-----
AMDG Chad Nelson wrote:
Exactly my point. But while we're on the subject: considering that those are in a namespace (so they don't pollute the global namespace), and are constants, is there any particular reason to use or not use "static" in the declarations?
The compiler will add static for you, so I prefer to say it explicitly. In Christ, Steven Watanabe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2010 02:03 PM, DE wrote:
looking at implementation: don't you want to make global integer constants members of enum(s)? as well as static integer constants (haven't noticed so far)
i think that
enum { bits_per_digit = whatever_it_is, digit_hibit = so_does_this, etc };
is better than global objects (defined in a header)
The code was written assuming that each of those constants has a particular type. I've never delved into how enums are treated, type-wise, so I'm not sure that would work the same.
to prove me wrong try to compile two source files including "xint.hpp" and using xint::integer (just for sure) and link them together i expect linker complaints about entities defined in several object files
They don't. I'm using a version of the library (only slightly earlier than the first Boost Vault one) in a large project here, and the compiler happily accepts it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuz5t4ACgkQp9x9jeZ9/wTXPgCg+M6cnr6lhsmyAtBgr5Qn+z41 7NUAoKxlMCi49XAoeGqCkUhEAdNizqXu =qKG3 -----END PGP SIGNATURE-----
Chad Nelson wrote:
On 03/31/2010 02:03 PM, DE wrote:
looking at implementation: don't you want to make global integer constants members of enum(s)? as well as static integer constants (haven't noticed so far)
i think that
enum { bits_per_digit = whatever_it_is, digit_hibit = so_does_this, etc };
is better than global objects (defined in a header)
The code was written assuming that each of those constants has a particular type. I've never delved into how enums are treated, type-wise, so I'm not sure that would work the same.
Each enumerated type is a distinct type. Thus, you could have: enum bpd { bits_per_digit = value }; enum dhb { digit_hibit = value }; etc. bpd and dhb are distinct types. _____ 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.
participants (5)
-
Chad Nelson -
DE -
Paul A. Bristow -
Steven Watanabe -
Stewart, Robert