Re: [boost] Getting the contained object from boost::function

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-10 09:55:49

From: "Douglas Gregor" <gregod_at_[hidden]>
> On Sunday 07 October 2001 11:05, you wrote:
> > I have encountered a situation where I have a boost::function:
> >
> > boost::function<void> onClick;
> >
> > initialized to a function object with a known type F (which is similar
to a
> > std::vector<boost::function<void> > with a broadcasting operator().)
> >
> > At some later point I need to ask onClick "do you contain an instance of
F?
> > if yes, please give me a reference to it so I can add another handler."
>
> With the current interface, this isn't possible, but I think it would be a
> worthwhile addition. I suggest the following interface (modeled after
> boost::any)
>
> template<typename R, typename T1, ..., typename TN>
> class function {
> public:
>   // type of target function object, or typeid(void) if empty
>   const std::type_info& type() const;
> };
>
> //
> template<typename To, typename R, typename T1, ..., typename TN>
> To& function_cast(function<R, T1, ..., TN>& f);
>
> template<typename To, typename R, typename T1, ..., typename TN>
> const To& function_cast(const function<R, T1, ..., TN>& f);

Perhaps it's time to discuss a common 'variant-to-contained-object' cast
that would work on any, function, and the future discriminated union and
"bounded" variant.

The easiest approach is to just adopt the name 'any_cast' but I don't like
it much. any_derived words are usually misleading. Any cast?

A problem with the precise definition of such a cast is when is the returned
pointer/reference invalidated.

> > Ideas?
>
> I would think that onClick shouldn't be a boost::function<void>, but a
> full-fledged signal. Unfortunately, we don't have one of those in Boost
yet.

Yes, actually this is what I ended up with.

> > BTW, the function documentation mentions 'operator bool' which has been
> > replaced by 'operator safe_bool.'
>
> It's an intentional trade-off. On one hand, the function documentation
> out-and-out lies to the user about a conversion. On the other hand, the
user
> doesn't need to go look up what safe_bool is in the (nonexistant)
> documentation.

Whether this is acceptable depends on the point of view; is boost::function
merely an useful third party library or something that is aimed at std::?

You can't even think of getting such a specification standardized. :-)

I suggest something like:

typedef <implementation-defined> bool_type; // convertible to bool

operator bool_type() const;

// no operator! in the specification, as it is a workaround.

> safe_bool should go into utility.hpp, and then it would have documentation
so
> this problem would be avoided. I promised to do that but haven't yet
> delivered :(.

Actually I don't think that this would be a good idea. A 'standard'
safe_bool will enable comparisons between unrelated types.

> > Also, operator! is not necessary.
>
> It's a workaround. At least one compiler (Borland, perhaps?) doesn't find
the
> appropriate conversion sequence without an explicit operator!.

A comment will save you from answering this question again. :-)

--
Peter Dimov
Multi Media Ltd.