Aleksey Gurtovoy wrote:
Peter Dimov writes:
When using boost::function<bool()> to implement event callbacks such as is_visible or is_enabled, it's very convenient to pass 'true' or 'false' directly, instead of going through bind( identity<bool>(), true ). An UI button I recently did even had separate bool properties in addition to the callback events for these reasons.
I wonder whether it's reasonable to add
this_type& operator=( T const & t );
to function<T()> that does the obvious thing.
Of course f = t; is merely a shorthand way of spelling f = boost::lambda::constant(t), but a dependency on lambda isn't always desirable.
Thoughts?
http://thread.gmane.org/gmane.comp.lib.boost.devel/76774 http://thread.gmane.org/gmane.comp.lib.boost.devel/76778 http://thread.gmane.org/gmane.comp.lib.boost.devel/76784
I ended up with 'f = always( whatever )',
What an amazing coincidence. :-)
which grew on me to the point that I don't wish for the above anymore.
Well, I still do. is_enabled( true ) is much better than is_enabled( always(true) ). _I_ can handle either syntax, but other programmers find the former much more accessible. The =0 collision didn't occur to me, mostly because I've never treated boost::function as a function pointer. I know which feature I'd prefer if given the choice. I'm not sure what Doug had in mind when he said that it would be unimplementable, as the scalar constructor and the scalar assignment are not templates. However, now that I think about it, I could just define true_ and false_ function objects. This doesn't solve the general problem but it'd get the job done in this specific case.