Peter Dimov wrote:
John Torjo wrote:
Sorry, I mis-explained. For boost::bind, the above works like a bliss.
It will have problems working with other code, that uses result_type. For example, boost::transform_iterator:
#include <boost/bind.hpp> #include <boost/iterator/transform_iterator.hpp> using namespace boost; #include <algorithm> #include <vector> #include <string>
struct test { std::string s; };
void clear_s( std::string & s) { s.erase(); }
int main(int argc, char* argv[]) { std::vector<test> v; std::for_each( // of course, it would be simpler to use Range Template Library :D make_transform_iterator(v.begin(),mem_fn(&test::s)), make_transform_iterator(v.end(),mem_fn(&test::s)), clear_s);
return 0; }
Your examples are getting more and more contrived. ;-)
sorry 'bout that. I've written the above in a hurry :( What I want to say is that sometimes mem_fn might be aggregated in another object (other than bind), that might use the 'result_type' typedef internally. Such an example is transform_iterator. I'm sure you're familiar with it. Based on result_type, it computes the iterator's value_type. Regarding the example above, I would like to be able to have a const sequence and also a non-const one. Which now should be realizable like this: // begin of sequence, const boost::make_transform_iterator(tests.begin(), mem_fn(&test::s) ); // begin of sequence, non-const boost::make_transform_iterator(tests.begin(), bind<std::string&>(&test::s,_1) ); This is acceptable. I just wish (when needing non-const sequence) I didn't have to write bind<std::string&>, since this requires me to know test::s's type. What if it changes in the future, etc.? I know that a solution that would not require me to write bind<std::string&> would be rather easy to implement and think it would be very useful. What do you think? Now that I think of it, I would even like something like: bind<non_const>(&test::s,_1); Best, John