Boost logo

Boost :

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


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

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

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

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

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

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