Boost logo

Boost :

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-07-16 12:56:04


> -----Original Message-----
> From: Michael Kenniston [mailto:Msk_at_[hidden]]
> Sent: Friday, July 13, 2001 8:47 PM
> To: boost_at_[hidden]
> Subject: [boost] Static data vs. inline functions
>
>
> In the design of the Quantity library, a trade-off
> arose which might be of more general interest.
> It affects the interface, not just the implementation,
> so it's important to get it "right".
>
> The general problem is the need for a bunch of constants
> of type T, where T is a user-defined class. In the
> specific case of the quantity library, T is
> "quantity<...>" and the constants are things like
> "foot" and "meter".
>
> There are (at least) two ways of handling this:
>
> 1 - const T mything( init_value );
> // ...
> T x = mything;
>
> 2 - inline T mything() { return mything( init_value ); }
> // ...
> T x = mything();
>
> If the constructor for T is simple enough, either of
> the two methods should allow a good compiler to optimize
> well by inlining the init_value, so efficiency does not
> appear to be a major consideration here.
>
> The first method is certainly more conventional, provides
> a cleaner, more concise syntax without the extraneous "()",
> and so is probably a little easier to understand and to use.
> It also clearly expresses the "const" nature of mything.

The same sort of inconclusive discussion took place over
the presentation of math constants.

The (naive) users are VERY keen to avoid extraneous (),
but the gurus maintain that providing functions is much
more efficient.

My personal view is that functions and their () are really nasty.
and make the code really significantly more difficult to read.

So I would assume that compilers will work properly, unless
you have evidence that they really don't.

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB UK
+44 1539 561830
mailto:pbristow_at_[hidden]
 


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