[boost] Re: Math constants - update & files removed

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-02-20 06:19:31

Gennaro Prota wrote:
> On Thu, 19 Feb 2004 15:55:08 -0000, "Paul A Bristow"
> <boost_at_[hidden]> wrote:
> 
>>Daniel Frey seems close to a portable solution, but <...>
> 
> Daniel, could you please summarize your problem? Actually I saw a
> sketch implementation of your idea a while ago and I quite liked it. I
> know there were problems with some compilers though and that there
> were doubts as to whether the code was standard conforming or not, but
> I can't recall the details. I would search the list archives but it's
> likely that the old discussions refer to a version of the code that
> you have changed later. Please, bring me up to date 8-)

OK, here we go:

- The latest version can be found in the files section 
<http://groups.yahoo.com/group/boost/files/MathConstants/>. Have a look 
at _m2_v2 and also at the examples for the unit libraries. They are 
probably good to show why a simple approach using #define is doomed to 
fail in the light of generic programming :)

- I don't have enough time (as usual)

- No documentation yet (will come next)

- The current version works on GCC3+ and Intel7+, but there were some 
problem with the VC7.1, which gave an internal compiler error. As I 
don't have the VC7.1 (not even Windows), I need help here. The code 
itself should be standard conforming, though, but I admit it's driving 
compilers to the edge - and further ;) OTOH, I don't see the point in 
providing bad interfaces to support old, non-conforming compilers - YMMV.

- typeof would be a great help, otherwise I have to switch back to some 
other system to deduce the operator's return types. Probably like 
bind/lambda do. I think that there is a need for such a general 
component which should IMHO use typeof when available and manually 
configuration from the user otherwise. Due to the mentioned lack of 
time, I haven't done anything useful in that direction yet. IIUC, FC++ 
would also benefit from such a component, so I think we should really 
attack this topic soon. Anyone? :o)

HTH

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial solutions & technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de