[boost] Re: borland patch for random/graph tests

From: Alisdair Meredith (alisdair.meredith_at_[hidden])
Date: 2003-02-03 05:44:51

Beman Dawes wrote:

> * Patches really are best to be supplied as diff output; that cuts errors
> applying them.  The -c switch helps make them more readable. It may be
> better to attach the diff output as a file, if long lines would be wrapped
> by pasting it inline.

Is this form better?  [diff through WinCVS]

cvs diff uniform_smallint.hpp (in directory
C:\Projects\3rdParty\boost\boost\random\)
Index: uniform_smallint.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/random/uniform_smallint.hpp,v
retrieving revision 1.20
diff -r1.20 uniform_smallint.hpp
190a191,192
> #elif defined( __BORLANDC__ )
>   typedef typename detail::uniform_smallint< boost::is_float<typename UniformRandomNumberGenerator::result_type>::value == false >::BOOST_NESTED_TEMPLATE impl<UniformRandomNumberGenerator, IntType>::type impl_type;

*****CVS exited normally with code 1*****

cvs diff uniform_int.hpp (in directory
C:\Projects\3rdParty\boost\boost\random\)
Index: uniform_int.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/random/uniform_int.hpp,v
retrieving revision 1.21
diff -r1.21 uniform_int.hpp
208a209,210
> #elif defined( __BORLANDC__ )
>   typedef typename detail::uniform_int< boost::is_float<typename UniformRandomNumberGenerator::result_type>::value == false >::BOOST_NESTED_TEMPLATE impl<UniformRandomNumberGenerator, IntType>::type impl_type;

*****CVS exited normally with code 1*****

> * Testing for "defined( __BORLANDC__ )" is usually discouraged because it
> will fail when the compiler changes to a new version which behaves
> differently. Also, there may be a Boost config macro which applies, and is
> the preferred way to detect a compiler deficiency.

Yes, and I probably should have used the new BOOST_WORKAROUND macros
too.

In this case the same borland bug is responsible for both patches,
suggesting that if there is not yet a BOOST_specific macro to test it
might be useful to add one.  Of course, there may already be one that is
appropriate known to those more familiar with the workarounds.  The
issue is with (at least) Borland's treatment of BOOST_STATIC_CONSTANT. 
For some reason it refuses to allow use of const static bool members
without a class instance.  In this case all that was needed was a
compile-time boolean flag to pick the right specialization so the test
could be performed directly in-place.

-- 
AlisdairM