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
> > 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
> 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
> 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?
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk