From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-10-23 06:59:29
> -----Original Message-----
> From: Ed Brey [mailto:edbrey_at_[hidden]]
> Sent: Monday, October 22, 2001 10:44 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math constants for naive and gurus? - which
> constants do you want?
>
>
> From: "Paul A. Bristow" <boost_at_[hidden]>
> > >
> > > The current version in the vault has several files
> > > (float_constants.h, double_constants.h, long_constants.h) that
> > > each define identical names in the global namespace. This is
> > > certainly not acceptable for a boost library. Now, if the
> > > objective is just to show that the constants can be partitioned
> > > into multiple headers, that is fine. However, one should never
> > > count on the user just including only one of multiple headers,
> > > since any given library may include any given header in a .hpp
> > > file (perhaps because a constant is needed in inlined code).
> >
> > I naively envisaged that only one would be #included.
Would it not be simpler to check that the other types (float and long
doubles say)
have not already been included?
> > > What didn't make sense is why the compiler would generate code
> > > for unused constant classes. Fortunately is that the answer is
> > > due to a simple (arguable) bug in the library. The constant
> > > class has a superfluous constructor. If you remove the
> > > constructor, then the compiler generates code only for what is
> > > used, and optimally efficient code at that. ("The compiler" here
> > > is VC6.) If there was ever a poster child for not littering
> > > classes with do-nothing constructors, this is it.
> >
> > I don't understood you here.
> >
> The > constructor is boost::math::constant::constant. The line to remove
is:
> constant() {} // Returns the value of the constant.
Sorry for temporary brain failure here - of course.
But MSVC6 produces this in debug mode:
51: const double cp = 3.141592653589793238462643383279502884197;
00401650 mov dword ptr [ebp-8],54442D18h
00401657 mov dword ptr [ebp-4],400921FBh
52: double ccp = constpi; <<<<<<<<<<< simple assignment.
0040165E mov eax,[constpi (00470028)]
00401663 mov dword ptr [ebp-10h],eax
00401666 mov ecx,dword ptr [constpi+4 (0047002c)]
0040166C mov dword ptr [ebp-0Ch],ecx
53: double pd = 3.141592653589793238462643383279502884197;
0040166F mov dword ptr [ebp-18h],54442D18h
00401676 mov dword ptr [ebp-14h],400921FBh
54: double p = pi; <<<<<<<<<< Using function
0040167D mov ecx,offset pi (00470022)
00401682 call
@ILT+260(boost::math::constant<boost::math::pi_tag,double>::operator double)
(00401109)
00401687 fstp qword ptr [ebp-20h]
// function actually being called
70: template<> inline constant<pi_tag, double>::operator double()
const
71: {
00401990 push ebp <<<<<<<<<<< What does all this do?
00401991 mov ebp,esp
00401993 sub esp,44h
00401996 push ebx
00401997 push esi
00401998 push edi
00401999 push ecx
0040199A lea edi,[ebp-44h]
0040199D mov ecx,11h
004019A2 mov eax,0CCCCCCCCh
004019A7 rep stos dword ptr [edi]
004019A9 pop ecx
004019AA mov dword ptr [ebp-4],ecx
72: return 3.141592653589793238462643383279502884197;
004019AD fld qword ptr [__real_at_8@4000c90fdaa22168c000 (00470110)]
<<<<<<<< pi in hex?
73: }
004019B3 pop edi
This doesn;t look optimal to me (but then Intel X86 code already looks
sub-optimal to me!)
I'm not sure how to look at the release version code - can you
share your investigations with us?
Thanks for applying your expertise to this.
Paul
PS What do other compilers do with this?
Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB UK
+44 1539 561830
Mobile +44 7714 33 02 04
mailto:pbristow_at_[hidden]