-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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