From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-22 05:05:44
From: Alan Griffiths [mailto:alan_at_[hidden]]
> No, the point still holds...
> arg::vector => boost::rational
> std::swap => std::abs
> client::swap(C&, C&) => client::abs(const C&)
> client::C& C::swap(C&) => boost::rational<int> C::abs() const
> The difficulty I foresee is that there is no way of stopping
> the client code existing inside a class that has an abs/swap member.
> (OK, I admit that implementing abs by forwarding to C::abs is less
> likely than the equivalent swap scenario.)
OK. I start to see what you are referring to. But aren't the signatures
going to be different?
Member: n.abs(), or using "this", abs()
If any form of client code created a two-arg member abs() (one for the
object, one for inside the (...)) then it has totally different semantics,
and someone somewhere has broken an implicit contract...
Oh, but is the problem that the compiler stops looking as soon as it finds a
member version of abs() at class scope, even though the version it finds
cannot match the call? Yuk. I was right - my brain does hurt.
It looks to me like there is no even remotely obvious way of writing this
stuff so that it works correctly in all cases. I would be interested in
getting the committee's comments on how all of this was meant to work. [Even
if the comment was just "oops" :-)] Is there a way of formally requesting a
rationale-style "how do I get this to work" comment? If so, I'd be willing
to write up the scenario.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk