Boost logo

Boost :

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?

  int x;

  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
> coworkers.

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
without qualification.

-- 
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