Boost logo

Boost :

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

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote in message

> 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

using namespace numeric::conversion;



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
> to effectively transform the "conversion" into nothing.
> In the case S is a UDT the argument is taken by reference and nbot by
> > 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
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
> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at