Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2003-11-21 07:12:27

"Matthias Schabel" <boost_at_[hidden]> wrote in message
> From: Matthias Schabel <matthias_at_[hidden]>

>The "experts" tend to also view implicit
> conversions as dangerous :
> Meyers, More Effective C++ pg. 24-31

Also says "Automatic conversions from one type to another can be extremely
convenient." :-)
Point about all this is, that in an ideal C++ world I would be able to
provide an implicit conversion with a (switch offable!) warning.
I gather that this sort of area is currently being discussed for the next
version of the standard... (Hopefully this discussion is useful as one more
example of
problems caused by lack of it.)
This may be possible now to some extent using Boosts "concept checking"
scheme, though top_of_head the only
thing that will give this sort of warning is a (say) double to int, but if I
embed it in a function with a funny enough name:
 maybe it'll make some sense :-) .
Whatever its some way down the road, but maybe part of
my requirements on the aspiration. Interesting problem in
For the moment I'm going to 'live dangerously ' :-)

> Efficiency - the units can exist on top of existing data vectors as a
> reference-
> containing wrapper, sparing the cost of copying _many_ data elements
> while
> at the same time enabling unit correctness :

 I am limiting myself to sorting out the basics first.


> Of course, the codes I'm working with involve 3D data sets
> of up to 256^3 voxels and similar sized PDE solvers, so the compilation
> time is negligible compared to runtime...

It would be interesting to
a) compare compile time
b) run time
of using a user defined type v an inbuilt type per compiler
Ideally run time is the same, but only experiment would tell.
(and all depends on exact nature of the calcs)
(presumably you wouldnt be doing unit conversions in these calcs! )

> it may not be worth expending a tremendous amount of energy in
> documentation...

I am some way in, so may as well carry on I guess :-).
At the very least if the thing is not used as is, a future developer may
find it useful.
I'll be happy to finish it. Hopefully it doesnt get popular,
 else its just a lot more work maintaining and developing it :-)


>I think we need outside comment to ascertain which solution
> is most
> appealing.

Hence you need docs.
I am writing up so that others can see some of the problems and my
decisions and solutions.
Perhaps then they will make comment.
Raw code is not the fastest,neatest way to communicate ideas.

Andy Little

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