Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-06-18 02:47:50

Paul A Bristow wrote:
> Absolutely, but on the previous review,
> many users wanted to "Keep It Simple Sir"
> and deliberately only have (for example) double const pi -
> avoiding the complexity of other schemes, get warnings of conversions,
> difficulty during debugging,
> and inefficient code from older compilers.

What do these users say about the STL? I bet it's too complex, difficult
to debug, etc. for them :)

> They would chose just the plain double const files.
> You would just ignore them - at no cost to you!

There is a cost: You have several use schemes. It's like providing
another version of std::vector or std::string because some people want a
more efficient version or an easier interface (which usually is only
more efficient or easier in a very limited view). I don't think that
it's a good idea and I'd vote "no" for inclusion of such a library.

> | > 2 Avoiding paying for what you don't use, which leads to
> | Hm, there is some small overhead, but not much IMHO. In fact
> | far less than a lot of other boost libraries. :)
> Agreed, though don't forget there are dozens of constants, not just pi.

If you don't use a constant, it never gets instantiated. Templates
should ensure that the code is not bloated in this case, maybe the
compile-time is affected, but not much as there is no recursion. But
this needs some testing, see below.

Also, two lines per constant is not too much, is it? Or with the help of
a MACRO (sigh), it's just one line and has even more functionality :)

> For systems where every byte counts, they may be
> best.
> (For me, while generating the other files,
> the extra cost of generating the MACROS file is negligible).
> If you hate MACROs them don't use these files - at no cost to you!

No! Like I already said above: I cannot write code which works for all
headers the user might want to use. Are we writing a library for general
use or not? If yes, then there should be only one interface.

> I will try to compare your proposal more carefully with Michael
> Kenniston's
> version - which seems to work efficiently and conveniently and
> extensibly
> with small enough risk of surprises about precision for novice users.
> As Ed Brey reported during this review, Kenniston's method files
> DO generate efficent code with Optimising MSVC 7.1 and gcc,
> not creating any code for unused constants - an important requirement.
> So the only cost is in compile time - which should be tolerable.
> However I am away from my machine at present so it may be a day or two.
> If you have more examples of use similar to those in the folder
> "testFunctionConstants",
> containing a test.cpp with lots of comments and header
> functionconstants.hpp
> these will be helpful. the Folder pi also gives his examples of
> extending to
> handle complex. quadfloat folder gives an example of a UDT
> (a 128bit floating point software type).
> I am confident that your system also generates efficient code using an
> efficient compiler.
> But have you considered or tried debugging?

Currently, I don't have time for that. Maybe at the weekend, but I can't
promise. But I agree that it should be verified in practice.

What I'd also like to hear is opinions from others here on the list.
What do you think?

Regards, Daniel

Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at