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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-07 05:35:04

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] 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