From: David Abrahams (dave_at_[hidden])
Date: 2006-04-13 17:07:52
"Fred Bertsch" <fred.bertsch_at_[hidden]> writes:
> I can see that there's no way to make the assignment operator do any
> better. I didn't mean to imply otherwise. However, that doesn't change
> the fact that it doesn't do the right thing.
> I would claim that if code far from a call can change the order of
> parameters in a function call, and if the compiler won't tell me about
> it, then this is dangerous.
How different is that from this situation?
void f(int x) // "code far from a call"
// ... lots of code
a_call(x); // I thought I was passing ::x
Here code far from a call can affect the meaning of that call. I
don't see why the order of parameters is especially more sacrosanct
than other changes to the meaning of a function call.
> I don't mean to say that it could be done better. It's really a very
> slick library. I'm just saying that I won't recommend its use to my
That's your perogative of course. Maybe you should tell them to avoid
using scopes, though, because lexical scoping can cause the same
problems without this library being involved ;-)
> I think it would be reasonably safe, however, if you put the
> argument identifiers in a separate namespace. I like that idea. It's
> potentially ugly, but it should be considerably safer.
Normally the keyword objects should be declared in a nested namespace
of the one that declares functions whose parameters they identify, and
that should generally be a different namespace from that of the
functions that use those keyword objects. However, it's idiomatic to
bring those keywords in via using directives to make them available
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk