
Boost : 
From: Paul A Bristow (pbristow_at_[hidden])
Date: 20070517 05:12:01
>Original Message
>From: boostbounces_at_[hidden]
>[mailto:boostbounces_at_[hidden]] On Behalf Of John Maddock
>Sent: 16 May 2007 18:36
>To: boost_at_[hidden]
>Subject: Re: [boost] [math toolkit] Review results
>
>Paul A Bristow wrote:
>> If we want it to fail at compile time, IMO it MUST be an option
>> becaue there are occasions when it is vital to be able treat all
>> distributions alike. A typical case is our C# .NET (cue hisses and
>> boos) 'applet' to calculate distribution parameters  for any
>> distribution chosen from a dropdown. (This useful program will be
>> posted somewhere soon).
>
>Two other options: we could remove the definitions of accessor
>functions
>that are undefined for that distribution, and then add our own private
>"catch all" versions when we need them. Or we could add the
>"catch all"
>versions to a separate namespace, and users could bring them
>into scope when needed.
These seem more complicated to me, unless I am misunderstanding, again.
There are only quite few *undefined* accessors (mean, etc).
> Do we have customised (as in meaningful and distribution specific)
>error messages for the current functions though? If so we
>should try and keep them.
The compiler outputs:
I:\Boostsandbox\math_toolkit\boost/math/distributions/cauchy.hpp(218) : error C2027: use of undefined type
'boost::STATIC_ASSERTION_FAILURE<x>'
with
[
x=false
]
.\test_cauchy_mean.cpp(47) : see reference to function template instantiation 'RealType boost::math::mean<double>(const
boost::math::cauchy_distribution<RealType> &)' being compiled
with
[
RealType=double
]
but if you click on cauchy.hpp line 218 you see the pretty selfexplanatory code below:
template <class RealType>
inline RealType mean(const cauchy_distribution<RealType>& )
{ // There is no mean:
#ifdef BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED
# ifndef BOOST_MSVC
# error Mean of the Cauchy distribution is undefined!
# else
BOOST_STATIC_ASSERT(sizeof(RealType) == 0);
# endif
#endif
return tools::domain_error<RealType>(
BOOST_CURRENT_FUNCTION,
"The Cauchy distribution does not have a mean: "
"the only possible return value is %1%.",
std::numeric_limits<RealType>::quiet_NaN());
}
>> So to provide an option, a macro seems sensible, perhaps
>> BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED?
>
>The consensus seems to be for making compiler errors the
>default, so maybe
>BOOST_MATH_DEFINE_ALL_ACCESSORS to make them available
>regardless of whether
>they are mathematically defined for the distribution.
OK  I assume this is just the inverse of BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED
Are we *sure* this is the consensus?
IMO providing NaN may be more useful?
>> BOOST_STATIC_ASSERT(false); has been one way of providing a compile
>> time trap and fails with a rather long message, although clicking on
>> the 1st line goes straight to the source code above, so it soon
>> becomes pretty clear.
>
>It would have to be BOOST_STATIC_ASSERT(sizeof(T) == 0) as
>some compilers
>realise that BOOST_STATIC_ASSERT(false) will always fail and issue a
>diagnostic irrespective of whether the template is instantiated.
OK  but I hope compilers don't get even smarter.
>> For MSVC at least one can use the #error pragma thus
>>
>> #ifdef BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED
>> # ifdef BOOST_MSVC
>> # error Mean of the Cauchy distribution is undefined!
>> # else
>> BOOST_STATIC_ASSERT(false);
>> # endif
>> #endif
>>
>> and this produces the rather more explicit message:
>>
>I:\Boostsandbox\math_toolkit\boost/math/distributions/cauchy.hpp(216)
>> : fatal error C1189: #error : Mean of the Cauchy distribution is
>> undefined!
>
>Surely that just gives an error whenever you include the header?
Seems to work for MSVC 8.0.
>Or we could simply not provide the definitions of these
>functions at all:
>but then the error messages might be rather cryptic?
A definite step backwards, IMO.
Paul
 Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk