-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger
It's essentially saying the same thing, but I got your nuance: whether member or nonmember has nothing to do with the function type and only with the result type of operator& (or function-to-pointer conversion) applied an entity of that type.
Exactly. It is one of those places where the type system cheats internally.
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. You cannot catch the cv-qualification of a function with 'const T'. I.e. typedef void func(); const func != void () const (In fact, 'const func' is illegal.)
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. 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. The only reason for library support for them (cv-qualified function types), IMO, is completeness. I'm not saying that it is particularly useful.
#define __stdcall _Pragma("__stdcall")
C99's _Pragma seems pretty close to GCC's "__attribute__(whatever)"...
Incidentally, this brings up annoying thing #3. C++ already sort-of has a language-level facility for this kind of thing--e.g. extern "C". Calling convention could be part of such a linkage specification. In the case of __stdcall, extern "verbose". Of course, the annoying part is that you can't touch anything with this kind of linkage specification with templates--though you should be able to.
Because of your awesome Boost.Preprocessor, my library does not have to worry about this sort of changes at all (its just a tuple element in the configuration) ;-).
Once again, the preprocessor to the rescue! Regards, Paul Mensonides