Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-12-17 19:45:28

> Some months later John comes along and decides that a container (call it
> arg::vector) that I wrote would be better than std::vector. He changes
> the class definition, re-runs the unit test harness and commits the
> change.
> The problem is, of course, that the resulting code /1/ no longer meets
> the strong exception safety guarantee and /2/ is a lot slower. (I had
> provided an efficient, non-throwing swap<> in namespace arg.)
> Now I feel that I failed to provide a container that was sufficiently
> like a standard container - I "rectified" this by partially specialising
> std::swap (which I now realise was illegal).
> If you provide a rational<> template that does not reflect the
> "principle of least surprise" by behaving correctly when used with
> std::abs then you too will be failing.

If John has no reason to expect using std::swap explicitly to work as he
expects (since the only way to get that behavior is illegal), aren't we just
reinforcing his mistaken impression by bending over backwards to make
std::abs work as he expects? Shouldn't the answer be to educate people to
rely on Koenig lookup to do the right thing?

Also, how much of the problems here are really broken compilers in disguise?
I'm not asking because I don't think MSVC support is important. It looks
like I will be forced to use (or at least support) it very soon, so having
boost work in that environment is important to me. I just want to know where
the line is. It changes how we must treat the issue (as temporary or
permanent) and how we must educate people.


P.S. Do we anticipate any problems with the generic graph work and MSVC?
There's no partial specialization there, but I want to use the graph stuff
for my next project.

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