Re: [boost] [function types] First reaction

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-13 13:36:50

Hello Alisdair,

Alisdair Meredith wrote:
> Sorry if this duplicates any previous comments, but you get my
> perspective raw from the documentation, rather than following other
> reviews <g>
> 
> I suspect I will only be able to reveiw the documentation as our
> production compiler is Borland, which I don't beleive is intended as a
> supported compiler.
>

it's currently not among the supported compilers.

There might be partial support in the future. Providing full support for the 
current version of BCB seems nearly impossible, due to the lack of partial 
template specialization for member function pointers.

If Borland is serious about continuing "C++Builder classic", it should be time 
for a new version, soon (and if they fix the bug above or at least introduce a 
native typeof operator I'll fully support it).

> 
> I find the motivation compelling enough to investigate the library, but
> wonder what to do about callable types that are not function types?  Do
> we need a Callable Types library on top of function types?
> 
> In partial answer to my own question, it is worth noting that a
> function pointer and a struct-with-overloaded-function-call-operator
> are VERY different beasts anyway - for instance only the struct type
> can be portably cast to void *, struct types may overload mulitple
> calling signatures, etc.
> 

If we want to look at a class type with a single overload for the parentheses 
operator which is not a function template (like an instantiation of 
boost::function or STL functors) we can use this library to look at its 
operator() member.

If we wanted to encapsulate this functionality in a metafunction we need a way 
to find out the type of the expression "T::operator()", which in turn requires a 
typeof operator or Boost.Typeof, which in turn requires registration for some 
compilers.

If we drop the idea of putting this into a metafunction, however, we can use a 
function template to deduce the type of "T::operator()" instead of requiring 
typeof, which is by far the more attractive solution in most situations. The 
only problem with this technique is that it has to applied manually. One of the 
examples shows this technique.

Then there are class types with a parentheses operator which is a function 
templates or multiple overloads of the operator() function:
C++ does not provide a way to query this. Even worse: the technique described 
above will fail to compile for these kind of functors because in this case we 
have to know which overload or instantiation we want when creating a pointer 
(this applies to any overloaded or templated function) with a cast expression.

If we do know which overloads are there, the synthesis part of this library can 
be used to create the type for such a cast expression, though.

> 
> Tag types:
> The list of tag types includes all variation of function and function
> pointer, but nothing for function references.  Is this intentional?
> 

Are you talking about the synopsis block ?
Well, I had to put the "..." somewhere ;-).

> Given const and volatile are effectively independant dimensions, it
> would be nice for the tags not to require a specific ordering (i.e.
> const_volatile)  However, apart from providing a redundant
> volatile_const set of typedef I have no better answer.  This only
> starts to become a problem is the const/volatile set is expanded in a
> future C++ standard, so can safely be ignored for now <g>
> 

In fact, I'm not too sure about handling cv with the tags is the wisest choice.

The const/volatile qualification of a member function can be seen as const 
volatile qualification on the "this-pointee", therefore it's a thinkable 
solution to use cv-qualification of the class type instead.

> 
> As I read on I can't help but notice the similarity with type_traits,
> but don't see any cross-reference in the docs.  In particular, I'm
> wondering if the interfaces differ in any way, and whether the ultimate
> plan would be to submit function_types as an expansion to type_traits
> for library TR2?
>

Of course, TypeTraits deals with a similar topic and FunctionTypes can be seen 
as an expansion, already. I gave it an own indentity rather than trying to write 
a "plugin for TypeTraits" because the interfaces and dependencies of the two are 
too different and not to interfere with the ongoing efforts of standardisation.

This library should be "officially boostified", before talking about "ultimate 
plans" and TR2, IMO.

> 
> OK, that's the end of lunch-break, will try to take a deeper look this
> evening.
> 

Thank you, already. I'm looking forward to read more.

Regards,

Tobias