Re: [boost] Boost.Function / type_traits questions

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-09-22 21:00:38

On Sunday 22 September 2002 06:57 pm, David Abrahams wrote:
> I notice that any_pointer doesn't contain a member function pointer among
> its union fields. I take it that means that member functions /always/ go
> through conversion to a function object when stored inside a
> boost::function instance... presumably to prevent all function objects from
> growing just so they can support virtual functions. Correct?

Yes.

> Now, the docs say:
>
> a.. A function object f of type F is stateless if it is a function pointer
> or if boost::is_stateless<T> is true. The construction of or copy to a
> Boost.Function object from a stateless function object will not cause
> exceptions to be thrown and will not allocate any storage.
>
> So I look in the table for is_stateless, and it's labelled "PC" meaning it
> requires direct compiler support and partial specialization. There are a
> whole bunch like that. I'm baffled by that combination! If it requires
> direct compiler support, then you sure don't need partial specialization,
> because the compiler can "just make it work". Maybe this means that given
> some other trait that requires direct support, plus partial specialization,
> we can implement is_stateless ourselves?

Hmmmm, "PC" is clearly wrong for is_stateless. It looks like the correct set 
would be "CD": either we need direct compiler support for is_stateless, or we 
need direct compiler support for is_empty, has_trivial_copy, and 
has_trivial_destructor (each of which is marked 'P', for some strange 
reason). Shouldn't is_POD be marked 'C'?

        Doug