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