From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 07:31:17
Paul Mensonides wrote:
>>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.
>
>>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?
> 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.
>
> 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.
Regards,
Tobias