Re: [boost] Math constants for naive and gurus? - which constants do you want?

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-23 07:55:35

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?

This would be problamatic, too.  For example, I might write a header:

#include "some_other_header.hpp"
#include <boost/unqualified_double_constants.hpp>
double const pi2 = pi * 2;

If some_other_header.hpp happened to include the float version of the constants, I would silently lose precision.  If I reversed the other of the #include lines, I could cause a similar problem in some_other_header.

> But MSVC6 produces this in debug mode:
[Debug results snipped]
> 
> 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?

As you probably know already, the assembly output of debug mode is not very useful, since debug mode efficency is not of interest.  To get assembly output for release mode, I create a minimal Win32 Console Application with a single source file.  If building from the command line, I add the switch /FAs, or if using the IDE, under project settings for Win32 Release, I go to the C/C++ tab, Listing Files category, and set the listing file type to Assembly with Source Code.  Then I compile the program in Release mode and look for a .asm file in the Release directory.

Often, to keep the resulting assembly file small, I'll avoid #including any files, and just copy and paste any definitions of interest directly into my test program.  In this case of math constants, however, #including is probably fine, because I don't think there is any baggage that will make it needlessly to the assembly output.

The testing I did was rather simplistic.  Rather than share my results, I'd rather have you independently generate your own results from your own tests, now that you know how get to the release mode assembly.  I'm certain you'll be able to think of more real-world test cases than I could.

Assuming that inspection of the assembly output yields positive results, the next test I would recommend is taking some signficant piece of math-intenstive code, and compiling it twice, once with plain old constants definitions, and once with the template definitions.  There would be too much output to wade through by hand, be one should be able to do comparisons of the resulting assembly, object, and executable files.  I expect that they will be byte-for-byte identical.