Boost logo

Boost :

From: Matt Austern (austern_at_[hidden])
Date: 2001-04-19 16:39:22

Ed Brey wrote:
> The part I'm not understanding is what value is there to _not_ having
> the constants in the header, given that a header with built-in values
> can be easily generated?

I should start with my prejudice: I think that the interface is far
more important than the implementation. My assumption is that in
cases like this it is impossible to write good code portably.
If the interface is well done, and if it is standardized or widely
adopted, then individual vendors will each rewrite it for their own
platform. I think it's very important to have an interface that
allows vendors to use whatever tricks are necessary.

So: if your goal is to do the best possible job for one specific
platform, it is *not* true that a header with built-in values can
easily be generated. You can generate a header that contains (say)
a decimal expansion of pi, but that's not what you really want. You
want a constant that contains a binary expansion of pi for a particular
floating-point representation. You're unlikely to get the best
possible binary approximation of pi if you write something like
  const double pi = 3.141592653589793;
(no matter how many decimal digits you use).

If you want the best possible approximation of pi that will fit in
a double on a specific processor, you'll need to play tricks. Maybe
your processor has a special floating point instruction that will
load pi into a floating-point register, or maybe your friendly local
numerical analyst can tell you what the best 64-bit binary
approximation is, and you can twiddle bits by hand. Either way,
it's probably not something you can easily put in a header.

With portable code, of course, you can't do anything better than a
bunch of decimal expansions. That's a reasonable fallback, and
it's probably all that's necessary for version 1.0. But even
version 1.0 shouild be a framework that makes it possible to plug
in platform-specific code.


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