$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.