RE: [boost] Re: Re: Math Constants Formal Review - using namespacestoselectfloat size is simpler?

From: Paul A Bristow (boost_at_[hidden])
Date: 2003-06-20 08:56:37

|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Ken Hagan
|  Sent: 20 June 2003 11:27
|  To: boost_at_[hidden]
|  Subject: [boost] Re: Re: Math Constants Formal Review - 
|  using namespacestoselectfloat size is simpler?
|  
|  Paul A Bristow wrote:
|  > This scheme may offer more surprises to the many naive 
|  users (like me) 
|  > than an explicit (and convenient 'global') choice, for example:
|  >
|  > using boost::math::double_constants;
|  >
|  > to ensure that the expected size is used.
|  >
|  > One can make the compiler warn you about size conversions, 
|  whereas I 
|  > have the impression that these rules will mean that you 
|  won't get any 
|  > warnings.
|  
|  AFAICT, you will either get exactly the type that the 
|  context requires, or a diagnostic from the compiler saying 
|  that it is ambiguous. (This assumes that a selection of 
|  possible types are available for each
|  constant.) I don't think it is possible to get a quiet conversion.
|  
|  In contrast, "using boost::math::double_constants" does 
|  allow you to get an implicit size conversion, where the 
|  context requires one. Compilers will warn, but only if users 
|  haven't disabled the warning.
|  
|  So, with the "clever" approach, all users will find 
|  themselves writing a few explicit conversions to avoid 
|  ambiguities. With the "simple" approach, only users who have 
|  their warning level right up will need to write explicit 
|  conversions, and then only to silence the compiler.
|  
|  Listening to compiler warnings is something the community 
|  might want to encourage (so the simple approach would then 
|  have no advantages), but it isn't the job of a language 
|  standard to mandate "good" programming practices. (In the 
|  absence of such constraints, the definition of "good" tends 
|  to change with time.)

I am grateful for this reassurance that conversions not expected,
though I hope the compiler writers know the rules -
as Michael Caine would have said "Not a lot of people know that" :-) 

Thanks too for your accurate summing up of pros and cons.
My slight preference for the 'simple' approach 
perhaps came from always setting the compiler to warn about
conversions and carefully 'casting them all away'.
Alas Microsoft have not chosen this as their default
and it is not obvious how to ensure that
all files are compiled with the right warning option.
(After getting some helpful hints, I previously posted guidance
on how to modify common.js to achieve this).

But I am persuaded that the 'casting' method is OK.

Paul