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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 04:50:16

Paul Mensonides wrote:
>>-----Original Message-----
>>From: boost-bounces_at_[hidden] 
>>[mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger
> 
> 
>>>Just to be pedantic, the types of member functions are 
>>
>>regular function types
>>
>>>also.  
>>
>>To be even more pedantic: there are no types of member 
>>function types (there are 
>>only function types decorated with a pointer to member which 
>>as a whole are 
>>'compound non-function types'). But it seems I look at it the 
>>very same way:
> 
> 
> I disagree.  The type of a member function is a regular function type.  Note
> that type equivalence does not imply functional equivalence (i.e. how it works).
> The notion of 'type' is only a conceptual abstraction.  Regardless, the type of
> a member function is a regular function type, even though the type of a
> pointer-to-member-function differs significantly from a pointer-to-function.
> 

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.

> 
>>>Furthermore, you *can* have cv-qualified function types, 
>>
>>such as 'int
>>
>>>(int) const'.  
>>
>>While theoretically correct, things are too 
>>implementation-defined around here to 
>>rely on that you can do anything with cv-qualified function 
>>types (not decorated 
>>with a pointer to member, that is). E.g:
>>
>>    typedef int(int) const x; // parse error with GCC
> 
> 
> Should be a parse error on any compiler.
> 
> typedef int x(int) const; // correct
> 

Yeah, right -- actually I know -- just posted too quickly (shame on me).
Still doesn't compile with GCC, though ("invalid specifier").

> 
>>We shouldn't use types like this -- this is the reason why 
>>the library does not 
>>support them.
> 
> 
> I understand (though don't entirely agree with) your motivation for this.  There
> isn't much you can do with cv-qualified function types, and there are a load of
> gray areas (even in the standard).  Another fun one is exception specifications.
> 

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. 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.

> 
>>>remove_pointer_to_member< void (x::*)() >::type -> void ()
>>
>>Yeah. For the protocol: this code won't work with GCC 
>>(doesn't match the 
>>specialization) or MSVC ( R is substituted with void 
>>__thiscall(x::*)() ).
> 
> 
> I know.  For the record, however, both GCC and MSVC are wrong.  It should match
> the specialization and the result should be 'void ()'.
> 

That's what I meant; I should've added "EDG and Borland do it right".

> 
>>The fact that there can be calling conventions particular to 
>>member-functions 
>>makes these "add/remove member pointer transformations" even 
>>more troublesome.
> 
> 
> It is particularly annoying that there's a separate calling convention for this.
> It is totally unnecessary.  I'd be more than happy if we could get rid of the
> inferior __stdcall calling convention also.  Note also that calling convention
> is properly in the domain of "extra-linguistic instructions to the compiler" and
> should be implemented with pragmas.  This is especially true if C++ picks up
> C99's _Pragma operator which can be the result of a macro expansion.  E.g.
> 
> #define __stdcall _Pragma("__stdcall")
> 

C99's _Pragma seems pretty close to GCC's "__attribute__(whatever)"...

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) ;-).

> 
>>>non-static member function).  I think it is a misuse of 
>>
>>terminology to say "the
>>
>>>type of a function" and really mean "the type of a pointer 
>>
>>to function."
>>
>>The review version of the library redefined and widened the 
>>term "function type" 
>>for that matter. I never really liked it and the boostified 
>>version will 
>>pedantically use the term "function type" as defined by the 
>>standard and will not 
>>refer to a function pointer as being a function type!
> 
> 
> That's fine with me.  I only really commented to point out that there is no
> "member function type" as a distinct entity.  I don't think that 'nonmember' is
> a property of a function type--it just doesn't make sense.

I use the terms "callable scalar type" (pointer/reference/member pointer to 
function) and "callable builtin type" (like "callable scalar" but includes 
function types) in identifier names which involve 'nonmember'.

The term "member" is only used in combination with "function pointer" and within 
the property tags "const_member" and "volatile_member" ("member" indicates they 
are ignored for any non-member-function-pointer).

Thanks for your reply which made me clarify my post.

Regards,

Tobias