[boost] Re: Nuemric Conversion review

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-18 22:29:30

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote in message
news:brt1qg$peg$1_at_sea.gmane.org...

> Some traits are free-standing:
>
> int_float_mixture<>
> sign_mixture<>
> udt_builtin_mixture<>
> is_subranged<>
>
> And there's also the bigger traits:
>
> conversion_traits<> that includes all of the above plus some aliases and
> additional useful types.

Ok, I guess I thought you would make all traits free standing, so when I
used it, I could
say

using namespace numeric::conversion;

target_type_of<T>::type
source_type_of<S>::type

etc.

BTW, argument_type is the same as call_traits<T>::param_type, is it not? If
so, why is it provided?

> > The section "Exact, Correctly Rounded and Out-Of-Range Representations"
> > mentions 1 ulp, but that has not been defined anywhere.
> >
> oh, OK.

btw, what is it?

> > Numeric Cast.
> >
> > what is improved in the new version?
> >
> The range checking is performed only when needed and only at the extent
> actually needed.
> In the case of T==S, the return value is a reference allowing most
compilers
> to effectively transform the "conversion" into nothing.
> In the case S is a UDT the argument is taken by reference and nbot by
value.
>
> > Why is the return  type not just Target?
> To allow a reference to be returned when T==S

aha, maybe you could add a small sentence to the docs here.

> "The documentation specifies exceptions like this:
> > virtual const char *what() const // throw()
> >         {  return "bad numeric conversion: overflow"; }
> > the comment after 'const' is bogus.
> > We need the throw() to override the virtual function.
>
> Why? This form of documentation is used all over boost.

Also when the implementation is actually using the throw() specs?
My thought was that when a novice sees the docs, he thinks he can override
what() in the same way, which he can't.

> > can  "nearbyint()" be renamed to nearby_int() ?
> "nearbyint" is the name of a C99 function.

so ? :-)   just because C99 is hard to read it does not mean your code has
to be. In the string lib, Pavol
consistently avoided this.

> > About the traits, then I
> > would prefer the freestanding conventiontemplate<class Traits>
> >   struct YourRawConverterPolicy
> >   {
> >     typedef typename Traits::result_type   result_type   ;
> >     typedef typename Traits::argument_type argument_type ;
>
> Hmmm... I don't get this.... can you explain?

As I mentioned above, instead of one big trait class, then individual
free-standing
traits is prefereed in my oppinion. Each time you just need one type from
your traits,
you pay the (compile time) price of the them all.

> > This would also mean some design changes, right? Didn't you talk about
> this
> > before the review?
>
> I don't know :-)
>
> > Also, can the two nested typedefs somehow be avoided.
>
> Do you mean "result_type" and "argument_type"?
> Remember that these are not necessarily just T and S, but can be "T
const&"
> and/or "S const&"

If you did have free standing traits, then the converter policy could not
take a traits
class, but rather source and target paramters and you would only use
result_type_of<T>::type and argument_type_of<T>::type and only pay for those
two typedefs.

br

Thorsten