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

[Greg Chicares]

On 2008-06-02 09:52Z, Vadim Zeitlin wrote:
[...]
>  I did test g++ 4.1 with Boost 1.34 and unfortunately the problem is still
> there, so this does look like a compiler bug in g++ 4.1, considering that
> the problem doesn't arise with neither previous nor subsequent versions of
> the compiler and that error messages are rather nonsensical:
> 
> value_cast.hpp: In member function 'To value_cast_chooser<To, From, 1>::
>       operator()(const From&) [with To = bool, From = char [2]]':
> value_cast.hpp:269:   instantiated from 'To value_cast(const From&)
>       [with To = bool, From = char [2]]'
> value_cast_test.cpp:721:   instantiated from here
> value_cast.hpp:248: error: invalid operands of types 'const char (&)[2]'
>        and 'int' to binary 'operator!='
> 
> The line numbers in value_cast.hpp are not the same as in the cvs but The
> line 721 of the test is unchanged and reads
> 
>     BOOST_TEST_EQUAL(true, value_cast<bool>("1"));
> 
> and even if I remove BOOST_TEST_EQUAL() and leave just the value_cast, the
> error message is the same -- in spite of the fact that there is no
> operator!=() anywhere.

I wonder whether they did something like defining a global
  template<typename T> bool operator bool(T t) {return !t;}
but it's probably not worth tracking down a gcc-4.1
regression that's apparently fixed in later versions.

>  OTOH I wonder if it's worth trying to work around g++ 4.1 problem if it's
> indeed a compiler bug and, moreover, an already fixed one. It seems that
> the only thing which doesn't work is value_cast<bool, char []> and there is
> an easy workaround (already used by quite a few tests) which is to use
> value_cast<bool, std::string> instead.

Where both of these
  value_cast<bool, std::string>
  value_cast<bool, char[]>
are tested, the intention is to make sure they both work.

It looks like boost::lexical_cast has similar tests. IIRC,
boost once made a change that seemed necessary for
  boost::lexical_cast<bool, char[]>
to work, but the change they committed broke
  boost::lexical_cast<bool, char>
or vice versa; that may have motivated me to make sure this
file tested all the cases I could think of.

> And if I comment this test out, the
> test compiles and runs with only a single failure but one which happened
> before my modifications too. For the record, the failure is
> 
> **** test failed:
> '100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
> ==
> '100000000000000003774589324822814887066163651282028976933086588120176268637538771050475113919654290478469527765363729011764432297892058199009821165792668120252416'
> [file value_cast_test.cpp, line 331]
> 
> I didn't look at it yet but this doesn't look especially good...

Relative error on the order of (1+DBL_EPSILON) or so? I suspect
that the test as written requires more than C99 requires, so that
this is just a QoI issue for snprintf(). If that guess is correct,
then the test should be liberalized ever so slightly.

>  Anyhow, for now the main question is whether I should continue to spend
> time on fixing the problem with value_cast<bool, char[]> which happens with
> g++ 4.1 (only)

Sounds pointless.

> or simply disable the test (perhaps for this compiler only)
> and continue testing with Comeau and MSVC?

Yes, I think the best approach is to guard those particular
tests with something like:

  #if !(defined __GNUC__ && 40199 <= LMI_GCC_VERSION < 40200)
    ...cast-to-bool tests...
  #endif //  !(defined __GNUC__ && 40199 <= LMI_GCC_VERSION < 40200)