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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 16:50:47

Paul Mensonides wrote:
>>-----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.
> 

Is either way defined behaviour? Got some standard references for me, perhaps?

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

Oh! I'm sorry -- assumed there was enough context around.

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

In this particular case it doesn't cost much. But if I'm going to do a trivial 
thing as finding out whether 'int' is a (any cv-qualified) function I need a 
second non-trivial template instantiation and a couple of trivial ones as you 
mentioned already. I'm not sure this feature is worth its price. Further, if your 
compiler is smart enough you can easily write it yourself if you need it.

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

Can't really say 'printf' is a dark corner of the language... "Dark history", 
perhaps. And open variadics can be quite useful. We shouldn't make assumptions on 
how many people use them -- variadic functions have been there for a long time.

Thanks,

Tobias