Re: [boost] [parameter] Lack of safety?

From: Fred Bertsch (fred.bertsch_at_[hidden])
Date: 2006-04-12 20:14:27

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_at_[hidden]> wrote:
> "Fred Bertsch" <fred.bertsch_at_[hidden]> 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