RE: [boost] RE: Math constants - efficiency

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-06-23 17:16:35

| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Daniel Frey
| Sent: Monday, June 23, 2003 7:44 PM
| To: boost_at_[hidden]
| Subject: [boost] RE: Math constants - efficiency
|
|
| On Mon, 23 Jun 2003 19:54:36 +0200, Paul A. Bristow wrote:
|
| > These are interesting results, but my enthusiasm is severely reduced by
| > the fact that MSVC 7.1 (Standard) chokes terminally on both versions
| > :-((
| >
| > Compiling...
| > Frey_bench_mark_gcc.cpp
| > Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from
| > 'double' to 'float'
| > Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER
| > ERROR
| >         (compiler file 'msc1.cpp', line 2701)
| >          Please choose the Technical Support command on the Visual C++
| >          Help menu, or open the Technical Support help file for more
| >          information
|
| ??? Line 108 is the static_cast< double >( pi ) for me. How can it compile
| the three lines before but choke on 108? I think I will still have to wait
| for the day MS has no surprise for us a bit longer... :)

Same line of code for me :-(

And how can the compiler actually crash like this?

| But the GCC 2.95.x ICEd on the F<U>()() so the workaround for the MSVC may
| be trivial and acceptable, too.

And why do other very similar codes from Michael Kenniston and Terje work?
Suggestions?

| I know and in this toy code I don't really care :))

No problem.

| > I hope this will produce a bit more sympathy for my attempts to provide
| > a variety of solutions for a variety of compilers. If the result is such
| > a big performance hit on widely used compilers, it is just too early for
| > such an advanced solution.
|
| Hm, I'm not sure I agree. Whatever will be standardizes shouldn't prevent
| good code, but it's not responsible for bad compilers. But there should -
| as I already said - be only one interface.

Don't disagree with that but I see a 'chicken and egg' problem : until there is
a Boost library file, nobody will use it, and there will be no pressure on
compiler
people to get a 'final solution' to work, and to work well.

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
mailto:pbristow_at_[hidden]