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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 05:14:15

Tobias Schwinger wrote:
> 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).
                            ^^^^^^^^^^^^^^^^^^^^
Should be non-member-function-pointer-callable-builtin-type (and I won't use such 
a term in the documentation :-) ).

> 
> 
> Thanks for your reply which made me clarify my post.
> 
> 
> Regards,
> 
> Tobias
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>