Re: [lmi] passing objects instead of references to value_cast

[Greg Chicares]

On 2008-06-13 01:54Z, Vadim Zeitlin wrote:
[...]
>  Notice that I decided to use boost::is_arithmetic<> instead of continuing
> to use std::numeric_limits<> after applying remove_const<> to FromDeref
> type because the former seems more natural to me and because I thought that
> "boost::remove_const<typename boost::remove_reference<From> >" was a bit
> clumsy but if you prefer to keep using std::numeric_limits<> it can be done
> too. The only difference between these 2 approaches is that
> std::numeric_limits<> can be specialized for user-defined types while
> boost::is_arithmetic<> is only true for the built-in types. However I
> didn't find any specializations of std::numeric_limits<> in LMI code so the
> point is moot.

I will apply this change soon. Let me comment on the rationale
first, though. The unchanged 'value_cast.hpp' explains [and I'll
revise the comments when I apply the change]:

/// Narrowing conversions are detected by boost::numeric_cast; in
/// keeping with that function template's design, they are tested iff
/// std::numeric_limits is specialized for both template parameters.
/// Actually, numeric_value_cast (q.v.) is used for the conversion.
///
/// Numeric input and output conversions use the boost::is_arithmetic
/// criterion to determine whether a parameter is of numeric type--a
/// criterion that includes certain nonstandard integral types whether
/// or not they have std::numeric_limits specializations.

But comeau rejects part of the (patched) unit test:
  instantiation of class "std::_Numeric_limits_base<__number>
  [with __number=const char [8]]"
and I guess this message from one of the EDG guys explains why:

http://groups.google.com/group/comp.lang.c++.moderated/msg/50fea16f5e68f36d
|
| > in fact you can check whether a
| > template parameter is a built-in type by testing
| > numeric_limits<T>::is_specialized.
|
| Nope, this won't work for array, pointer and reference types.
| The method you describe only works for fundamental types.

IMO that's sufficient reason to make the change you suggest here.
Perhaps I've misunderstood, though--this message:
  http://lists.nongnu.org/archive/html/lmi/2008-05/msg00014.html
suggests that the comeau error message appears only when we pass
the argument by const reference, and I can't explain why
'char [8]' would be okay but 'const char [8]' would not.

BTW, I looked up the numeric_cast code in boost-1.34, and it now
delegates to boost::numeric::converter, so the original rationale
for using std::numeric_limits<T>::is_specialized no longer holds,
at least not as far as I can readily tell--this function template
has become opaque.

I'm thinking of writing a numeric_value_cast<T>() that doesn't
use boost at all. The original boost::numeric_cast documentation
seemed to say value preservation was an asserted postcondition:
  "An exception is thrown when a runtime value-preservation
  check fails."
but that's not true of either the old or the new boost version.
Furthermore, I hesitate to slouch into a dependency on a sizable
new boost library that I now realize has slipped in through the
back door. Version 1.35.0 is nearly as many bytes as 1.34.1 and
1.33.1 combined, so the defect count pretty much has to be
increasing along with opacity.