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. 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. 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. -Fred Bertsch On 4/12/06, David Abrahams <dave@boost-consulting.com> wrote:
"Fred Bertsch" <fred.bertsch@gmail.com> writes:
There are cases where boost::parameter can translate its arguments to the wrong arguments at the function implementation side. I'm hoping that I'm doing something wrong, but it seems like a problem with the parameter library.
I guess it depends on your point of view, but I don't think this can reasonably be viewed as a library problem
The parameter library suggests creating global variables named with the names of the arguments to your function.
Well, namespace-scope constants, yeah.
If you have an inner scope at the calling site with a variable with the same name, things don't work.
It seems natural to me that if you have something declared at an inner scope with the same name and you use that name without qualification, the compiler picks up the inner declaration (except in the case of ADL, which is an abomination ;->). That's just the normal C++.
I'm okay if this simply results in a compiler error, but in some fairly simple cases, it can correctly compile to the wrong call to the implemented function.
Here's an example:
void FooImpl( int x, int y ) { // Gets x = 8, y = 14. We wanted x = 12, y = 8. }
BOOST_PARAMETER_KEYWORD( tags, x ) BOOST_PARAMETER_KEYWORD( tags, y )
<schnipp most of the Boost.Parameter related stuff because it's not relevant to the problem>
void Bar( int y ) { ... Foo( y = 8 ); ^^^^^ The problem happens right here, before the parameter library can possibly get a chance to intervene and do something wrong (or right).
I realize why, in a language with built-in support for named parameters, you might expect this to work, but we can't work magic here --- we can only get pretty close :^). In C++, what would you expect the expression
y = 8
to do in the context of this function body? If you want to reference the keyword object, you either need to avoid hiding it (pick a different name for your function parameter), or use qualification to reference the other symbol. In this case, since your keyword objects are in the global namespace, it would be
::y = 8
HTH,
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- F