Re: [boost] Function Types Review Begins Monday, November 6, 2006

From: Richard Smith (richard_at_[hidden])
Date: 2006-11-17 08:48:28

Tobias,

Sorry for not replying to your comments sooner.

On Fri, 10 Nov 2006, Tobias Schwinger wrote:

> Richard Smith wrote:
> >
> >>>  [...] instead of writing
> >>>
> >>>    bft::is_function< T, bft::variadic >::value
> >>>
> >>>  you would write
> >>>
> >>>    boost:is_function<T>::value && boost::is_variadic<T>::value
> >>
> >>I think, I don't like it. It's too irregular for my taste.
> >
> > I'm not sure what exactly you mean by 'irregular'
>
> [...] It's the parts of the library that become asymmetric
> between decomposition and synthesis.

I'm still not entirely sure I'm following you.  Do you mean
you want two metafunctions such that

  synthesise< decompose<_> >

is the identity?  If so, you've already lost that because
components doesn't store whether you have a function,
function reference, function pointer or member function
pointer.

> >>>5.  Extern "C" linkage
> >
> > The is_union type trait doesn't really work, but it still
> > exists.
>
> Oh, boost::is_union only works with compilers that provide
> extensions for type introspection (and, AFAIK, there are
> compilers that do so).

That's exactly my point.  A good quality compiler that
supports type introspection and that properly implements
language linkage in the type system would presumably allow
for querying language linkage.

> > I think it would be good if the documentation said that
> > extern "C" functions (at least in those compilers that
> > correctly fold language linkage into the type) *shouldn't*
> > be matched by default_cc, but that without some as yet
> > unspecified compiler support, they will incorrectly match.
>
>   is_function_pointer< ext_c_func_ptr, default_cc >::value
>
> works correctly. It tells me whether ext_c_func_ptr has
> the C++ default calling convention.

Even on a compiler (e.g. Comeau) that folds language linkage
into the type system?

On such a system, surely

  extern "C" typedef void (*ext_c_func_ptr)();
  is_function_pointer< ext_c_func_ptr, default_cc >::value

*should* return false?  (I appreciate it may not, but this
is an problem with the implementation, albeit a problem that
can't necessarily be solved at the moment.)

> Adding a note to the docs won't hurt, though.
>
> >
> > Likewise I think an extern_c_cc that (currently) never
> > matches would be good.
>
> For what?

So that a compiler supporting type introspection and
language linkage in the type system can implement it
properly.

For example, in Digital Mars __cdecl and extern "C" are
synonyms, so you already have support for it on that
platform.

> <snip>
> > What are your thoughts on adding support for pointers to
> > member data to the library?  I guess it depends to what
> > extra you see this as an extension to the Boost.TypeTraits
> > library for manipulating function types, and to what extent
> > it is viewed as a utility component for use in implementing
> > function wrappers and so on.
> >
>
> Supporting data members is trivial. So of what help could the library be?

Consistency.  TR1 defines 'callable' types to include data
members; Boost.Function, Boost.Bind and Boost.Lambda all
support data mebers as unary functions.  The
is_callable_builtin<> metafunctions are just for convenience
-- they can be implemented by mpl::or_'ing together
is_function, is_function_reference, is_function_pointer, and
is_member_function_pointer.  I'm suggesting that you should
include is_member_object_pointer too.

> >>>10.  Syntactic sugar around parameter_types
> >>>
> >   parmeter_type< F, 0 >::type
> >
>
> In that special case
>
>   mpl::at_c<parameter_types<F>,0>::type
>
> isn't inconvenient enough to justify "convenience clutter"
> in the interface, IMO.

Well, I disagree, and I think implementing this level of
convenience function will serve to encourage people to use
the library.

> I can understand the objective of keeping application code
> free of metaprogramming magic. In this case you better
> stay away from all metaprogramming libraries (including
> this one and TypeTraits) and building template-based
> interfaces altogether.

Perhaps it's not intended to, but, frankly, that sounds
incredibly patronising.  I find it absolutely extraordinary
that someone on this list would advise people who find the
MPL intimidating to "stay away from ... building
template-based interfaces altogether".  There's a whole
world of difference between the two; and like it or not, in
quite a lot of circles, the MPL *does* have a (perhaps
largely undeserved) aura of impenetrability.  I'm all for
trying to rectify this and encourage its use, but advising
people to avoid all template code isn't the way to achieve
this.

> >>>13.  Why is bft::components useful?

> > I can't see any uses of it in the example/ directory.
> >
>
> You're right. Obviously I did not remember correctly.

Would it be possible to see a use case?

> > Sorry, which expression models which two concepts?
>
>   components<T,ClassTransform>

OK.  And which two concepts does it model?  I can see that
it's an MPL sequence, but what else is it?

--
Richard Smith