Its learning curve is inherently steep and more importantly, it simply cannot be flattened by making bind less useful.
I guess the current design gives maximal power; so it it seems ok. Requering that the user calls
bind( f, local_copy( i ) )
would document that the programmer knows that f takes a reference, but that it can act on a copy. However, once you know the mechanism, you would be irritated by such constraints.
Thorsten
I agree with Thorsten's point. The first inclination when binding a function with a reference is that the arguments passed to that bind functor is actually passed by reference. That is what you are actually saying in your bind statement. While having pass-by-value may be more convenient and occur more often, the counter-intuitiveness of the semantics will lead to subtle bugs in people's code who misunderstand or forget bind's behavior in this area. It is not a matter of reducing the power of bind or "hand-holding" as has been said, but enforcing the semantics of what the programmer is actually saying. If you are binding to a reference argument, you should not need a ref( arg ) to say that the argument really is a reference. If you are binding to a reference, and want to pass by value, let the programmer type the extra 5-10 characters and explicitly say that he's changing the semantics of the bind. I personally like "bind( f, value( i ) )" myself. All that would need to be done is to introduce a argument_traits type class that will wrap references with a reference_wrapper, and also provide a value() wrapper. If you are binding often to a reference and want to pass-by-value, you might need to re-evaluate your interface. Just my 2 cents. Best, John
"Dill, John" <john-dill@uiowa.edu> writes:
While having pass-by-value may be more convenient and occur more often, the counter-intuitiveness of the semantics will lead to subtle bugs in people's code who misunderstand or forget bind's behavior in this area.
A bold prediction in the face of contradictory evidence. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Personally, I'd prefer to have it the way it is.
From a maintenance engineer's perspective I prefer this:
static void f( std::string & s ) { std::cout << s; std::string().swap(s); } void do_stuff() { std::string l_yo("yo"); boost::bind( f, boost::ref(l_yo))(); } Imagine this being a huge project. It's a tough job for a maintenance engineer (that's me) to grasp it all. By seeing boost::ref I understand that f receives a non-const reference to l_yo. It might be modified during the call to f. Of course I could understand that by just checking out of f. But the advantage here is that I see where the call is made that l_yo might be modified by f. As I'm sure you all are aware of in C# when you specify a function like this void do_stuff(ref int i) { ++i; } You have to call it like this: int l_i = 4233; do_stuff(ref l_i); You see at the place the call is made that l_i might be modified by do_stuff. I would love to have that in C++. Could you design the arguments of a function so that the compiler requires you to write something like this? // declaration void do_stuff( boost::requires_ref<int> i ); // works fine do_stuff(boost::ref(i)); // compilation error do_stuff(i); Mårten
As I'm sure you all are aware of in C# when you specify a function like
"Mårten Rånge" <marten.range@tapiren.com> wrote in message news:20040415161750.1D99437E66@smtp2-2-sn4.m-sp.skanova.net... [snip] this
void do_stuff(ref int i) { ++i; }
You have to call it like this:
int l_i = 4233; do_stuff(ref l_i);
You see at the place the call is made that l_i might be modified by do_stuff. I would love to have that in C++. Could you design the arguments of a function so that the compiler requires you to write something like this?
perhaps if operator.() could be overloaded. You could use a pointer instead. br Thorsten
participants (4)
-
David Abrahams -
Dill, John -
Mårten Rånge -
Thorsten Ottosen