
----- Original Message -----
From: "Piotr Jachowicz"
On 27 April 2010 20:55, Michael Caisse
wrote: Piotr -
I don't think this is "unexpected behavior" to most. You have *not* bound abc. You have bound a pointer. What that pointer points to may change and when you use the pointer it may very well point to something different than at the time of the bind.
This isn't "unexpected". Your bind is to a pointer. You need to either ensure that the value pointed at doesn't change or you can pass an object containing the data itself.
I've called it "unexpected", because f1() and f2() in code below behaves differently:
void echo1(const char* c) { cout << c << '\n'; }
void echo2(const string& s) { cout << s << '\n'; }
int main() { boost::function
f1 = boost::bind(echo1, "abc"); //ups! binding to address of temporary boost::function f2 = boost::bind(echo2, "abc"); //ok, bind copies temporary string("abc") f1(); f2(); }
Does this really behave differently? Because you should get the behavior you expect. Here you use a string literal to bind and although it is techically a pointer, the type in the strictest sense is char[4] and in order to change the memory where the string literal is stored you would be mucking around with the data segment and in most compilations you would change the literal for any place in your program that literal was used thereafter. Not to be too pedantic but, f1() and f2() don't behave differently - they each get different data (in your original case).
Incoming book "How to code with C++0x and not commit suicide" will have to contain advise "When you bind, ensure that function signature have no pointers; otherwise you are in trouble".
Using care with pointers has been a tenet since C.
To be serious: library should naturally promote its proper usage. Code like "boost::bind(echo1, "abc")" looks natural, does not emit any warning, and is dangerous. Cases like that promote stereotype "It's better to avoid Boost because it contains many traps". I think that compiler warning would save hours of debugging for many programmers.
The compiler is not going detect the problem. I have been of the opinion that boost has a cost that sometimes may be overlooked. It, like template programming in general, is has a pretty steep learning curve and, IMHO, challenges what may be gaps in basic knowledge. I would say because template programming is rooted in strong typing sensibilties even though it works to achieve type flexibilty. I can say this for myself - I have be a C++ programming for over 15 years and used templates, like the STL, but boost programming and other material of the generic programming meta-programming variety have challenged me to introspective of my knowledge. I would just observe the old saying "It is a poor craftsman who blames his tools" ;-)
michael
--
---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Piotr Jachowicz _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users