Re: [boost] [function types] New tag type logic [update]

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-07 15:45:03

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger

> >>In more detail: Given a compiler allows CV-qualified 
> functions, these 
> >>types pass the library without problems; the library detects them 
> >>properly because top-level cv-qulification is ignored.
> > 
> > 
> > I'm not sure what you mean here, but it makes me wary.  
> 
> The library uses the TypeTraits template 'remove_cv'. I
> 
> n theory e.g:
> 
>    template<typename T> struct remove_const          { 
> typedef T type; };
>    template<typename T> struct remove_const<T const> { 
> typedef T type; };
> 
> should work, shouldn't it? In practice it depends on the 
> compiler, of course.

That will remove any cv-qualifiers on a pointer to function (as in a "const
pointer to function"), but it won't remove the cv-qualifiers from a raw function
type.  There is no way to add or remove such qualifiers without taking the type
apart and putting it back together with or without the cv-qualification.

> >>There is no way to emphasize a
> >>query or specification
> >>for the cv-qualification of nonmember callable builtin types, which 
> >>would involve adding overhead for an esoteric and 
> unportable feature.
> > 
> > 
> > I assume that you mean compile-time overhead.  
> 
> What else could I possibly mean here?

I'm not familiar with all that your library does, so, from my point of view,
there might be a runtime component to the library.  I assume that you mean
compile-time overhead, but I don't see why there has to be.  Say you where going
to support them only on compilers that deal with the properly.  All it takes is
to defer them to the implementation of pointers-to-member-functions.  I.e. say
that you have 'is_pointer_to_const_member_function', then you can make
'is_const_function' without any (significant) overhead:

struct C { };

template<class T> struct is_const_function
    : is_pointer_to_const_member_function<T C::*> { };

Granted, you have to do a little more than that (by eliminating those types that
cannot be the subject of a pointer-to-member--such as references), but it isn't
that hard.  It also isn't too much of a burden to say: this metafunction doesn't
work on x, y, and z compilers.

> > If you have support for pointers
> > to cv-qualified member functions, it seems (to me) that the 
> required 
> > boilerplate to deal with cv-qualified function types is 
> already there.  
> > If you don't have support for cv-qualified member 
> functions, then you 
> > should; they are not esoteric at all.
> 
> Sure I have (btw. it would've not passed the review without, 
> I guess) - but only for the function types in member function 
> pointers. Implementing things differently would mean a lot of 
> portability-trouble.

I understand.

> > The only reason for library support for them (cv-qualified function 
> > types), IMO, is completeness.  I'm not saying that it is 
> particularly useful.
> > 
> 
> In a perfect world (where your "remove_member_pointer" 
> template always works) I'ld support them. However, currently 
> I don't see that completeness outweighs its price here. 
> Further I believe it's a good idea to keep the user away from 
> dark corners of the language by design.

If that is the case, then you shouldn't be supporting open variadics.  Support
for that adds significant overhead to the implementation.  Granted, variadic
function types are more common than cv-qualified function types, but they are
still quite rare.

Regards,
Paul Mensonides