Subject: Re: [boost] Name and Namespace for Potential Boost Extended Floating-Point
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-01 01:25:39
On Wed, Aug 31, 2011 at 9:22 PM, Simonson, Lucanus J <
> Jeffrey Lee Hellrung, Jr. wrote:
> > On Wed, Aug 31, 2011 at 3:16 PM, Christopher Kormanyos
> > <e_float_at_[hidden]>wrote:
> >> From: Matthias Schabel <boost_at_[hidden]>
> >> To: boost_at_[hidden]
> >> Sent: Thursday, September 1, 2011 12:00 AM
> >> Subject: Re: [boost] Name and Namespace for Potential Boost Extended
> >> Floating-Point
> >>>> mp_float
> >>>> mp_int
> >>>> mp_rational
> >>> +1
> >> If this is going to be in the "multiprecision" namespace, isn't
> >> "mp_*" redundant? Why not just
> >> multiprecision::float
> >> multiprecision::int
> >> multiprecision::rational
> >> $0.02
> >> ---------------------------------------------------
> >> No, unfortunately not. Please remember when using a namespace, a name
> >> like "float" can not be distinguished from the POD type float.
> >> Remember that many developers *use* a namespace to avoid typing.
> >> The ugly prefix is needed to guarantee unique naming.
> > Couldn't you just do what "every" other boost library does, and
> > append an underscore?
> In the interest of clarity I would prefer to see mp_float and not float_ in
> user code that *use* the namespace.
Noted. I actually misread the original comment and inferred an objection to
float and int already being C++ keywords.
In any case, it is indeed a stylistic preference. If I was really worried
about verbosity, I would probably alias boost::multiprecision (or whatever
the namespace was) to bmp and then use bmp::float_. Or maybe better is
real. Yes, these objects can't cover *all* real numbers, but their purpose
is to provide (nearly) arbitrarily precise approximations to real numbers,
right? A similar "fudging", if you will, of "real" is used by Boost.Spirit
(qi::real_parser and karma::real_generator).
float_ in no way intuitively means multiprecision floating point data type.
Agreed, but I think the "no way" is a bit excessive. The only thing it
doesn't really convey is the multiprecision aspect, and that context is
given by the enclosing namespace. I see multiprecision::mp_float as having
unnecessary lexical redundancy...or something like that :/
Intuitively, I would expect float_ in a boost library would mean a type that
> wraps a literal floating point value in a type for metaprogramming and might
> be declared something like:
> template <float f>
> float_ : float_c<f>;
I'm guessing your expectations are based on Boost.MPL, but keep in mind that
there are actually float_ and int_ objects in Boost.Spirit.Qi and
Boost.Spirit.Karma which have little to do with wrapping numeric values.
So, again, it's difficult to infer much from an identifier without
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk