Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-04 13:49:02

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?
> 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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at