Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2001-04-30 13:41:47


From: "Paul A. Bristow" <pbristow_at_[hidden]>
>
> As a mere cooking chemist, I can share the users' instinct,
> and fear WEB's pessimism about discouraging use. If we
> don't get it used, we are wasting our time.
>
> area = pi * r * r;
>
> seems right, whereas putting brackets in looks
> (and indeed to the scientist reader is) confusing.
>
> In much more complex expressions, the extra brackets
> are a real turnoff.
>
> Users can of course always write
>
> const double pi = boost::math::constants::pi();
>
> but at the cost of some inefficiency I fear.
>
> Which leads me back to the MACROS which meet the
> requirement for consistent high accuracy, but
> duck these important issues!

I don't follow how macros duck the issue, unless one was willing to put
up with:
  #define pi 3.14...

which I'm sure you weren't proposing. A pseudo-scoped usage of macros
leads to equations like:

area = BOOST_PI * r * r

which looks much worse than "pi()".

> I look forward to a other ideas.

Unfortunately, I can't think of a solution that gives us everything:
1. Unadorned constants (no parentheses or casting)
2. Inlining (for constant folding and fewer memory accesses (e.g.
immediate versus direct instructions))
3. Grouping (ability to pull all a group of names into a scope using a
single statement)
4. Genericness (templatized code automatically gets proper type)

(My list is in no particular order.)

Hopefully someone will come up with a solution that can do it all, but I
fear that we are in tradeoff land. Using multiple interfaces to provide
varying sets of features is among the options.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk