[type_traits] "member_function_pointer_traits" ?
Dear Boosters, what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ? In the latter case I hereby volunteer for implementing it. I suggest an interface similar to the one of function_traits but with two additional constants for 'const' and 'volatile' qualification of the pointee method, because there is no member function type without the pointer thus making it impossible to use remove_pointer / is_[qualifier] or pass 'Class::member_function' (without the '&', that is) as an argument of parametrized type to a template function. Best regards, Tobias
On Thursday 29 July 2004 9:22 am, Tobias Schwinger wrote:
Dear Boosters,
what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ?
AFAIK, it's just not yet implemented.
In the latter case I hereby volunteer for implementing it.
Great!
I suggest an interface similar to the one of function_traits but with two additional constants for 'const' and 'volatile' qualification of the pointee method, because there is no member function type without the pointer thus making it impossible to use remove_pointer / is_[qualifier] or pass 'Class::member_function' (without the '&', that is) as an argument of parametrized type to a template function.
Sounds good to me. Doug
Doug Gregor wrote:
On Thursday 29 July 2004 9:22 am, Tobias Schwinger wrote:
what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ?
AFAIK, it's just not yet implemented.
In the latter case I hereby volunteer for implementing it.
Great!
Got an initial version together which is (AFAIK, hopefully) worth looking at. If there is still interest in a submission, I need to know where to put it. {CVS/ftp/scp [need an account then], mail [need to know where], my web server [not sure this is legal since parts are based on code written by other boost authors] }
[...first design ideas...]
Sounds good to me.
Inspired by people on the list and in depth analysis of the existing library code, the objective of "adding something like function_traits, but for member function pointers" has evolved to "providing a set of metafunctions conforming to the concepts commonly used troughout the library (such as type-trait,bool-trait,...) to classify and decompose function pointer types" According to the review docs this seems to be a fast-track candidate, however I would very much welcome anyone willing to build an example program with some compilers not tested with so far, before formally requesting for review. Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:412F50A3.6030507@neoscientists.org...
Got an initial version together which is (AFAIK, hopefully) worth looking at.
If there is still interest in a submission, I need to know where to put it.
Try the yahoo files section first (http://tinyurl.com/5rlel) but I think it might be full. Otherwise, I don't think there's anything wrong with putting it on your server.
According to the review docs this seems to be a fast-track candidate, however I would very much welcome anyone willing to build an example program with some compilers not tested with so far, before formally requesting for review.
Let people critique it before proposing it for fast track review. Jonathan
Dear Boosters, A collection of additional type_traits metafunctions to classify and decompose (any kinds of) function pointer types, has been uploaded to the yahoo files section. [ Archive name is: 'function_pointer_traits.zip' ] I very much welcome any critiques, bug reports and error messages (reported by your compilers when trying to build the example program) ! It is tested with gcc 3.4.1 & 3.3.3 and on bcc 5.6.4, so far. Best regards and thanks for any help in advance, Tobias
Tobias Schwinger wrote:
Dear Boosters,
what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ?
In the latter case I hereby volunteer for implementing it.
I suggest an interface similar to the one of function_traits
Please, no more trait blobs! IMO you should separate the traits into individual meta functions that works on all function pointer types. For instance: function_arity<T>::type Self explanatory. function_signature<T>::type MPL sequence containing all types of the function signature, including return type and type of *this if T is a member function pointer. And while we're at it, why not deprecate function_traits? -- Daniel Wallin
Daniel Wallin wrote:
Please, no more trait blobs! IMO you should separate the traits into individual meta functions that works on all function pointer types. For instance:
function_arity<T>::type Self explanatory.
I'm writing this adaptor again and again. Last time was 4 days ago. If function_arity were in boost it could save a lot of my time :)
function_signature<T>::type
Why metafunction? Function signature itself could be viewed as MPL sequence (or view in MPL terms?): typedef argument_list<void (int)> args; static_assert(is_same<int,at_c<args,0>::type>); or may be even more natural (because arguments usually are numbered from 1): typedef result_and_arguments<void (int)> sig; static_assert(is_same<void,at_c<sig,0>::type>); // result static_assert(is_same<int, at_c<sig,1>::type>); // first arg Conversion from *any* sequence to function signature could help in back convertion. -- Alexander Nasonov
Please, no more trait blobs! IMO you should separate the traits into individual meta functions that works on all function pointer types. For instance:
function_arity<T>::type Self explanatory.
I agree, because of: - MPL-interoperability - Currently only the arity-part works on compilers without support for partial template specialization. This clearly delimits compiler support. - Including blobs of unused code unnecessarily increases compilation time.
function_signature<T>::type MPL sequence containing all types of the function signature, including return type and type of *this if T is a member function pointer.
Is it a good idea to separate this even further ? function_return<T>::type function_input<T>::type And only valid on member function pointers: function_this<T>::type is_const_function<T>::type/value is_volatile_function<T>::type/value A 'function_signature' metafunction could then be implemented on top of these. As I mentioned in the original post: A function type can exist without a pointer while a member function type can not. How to address this ? Handle all three cases or require pointer types ? I would appreciate any suggestions.
And while we're at it, why not deprecate function_traits?
It was just a -careful- request ! - Tobias
participants (1)
-
alnsn＠yandex.ru -
Daniel Wallin -
Doug Gregor -
Jonathan Turkanis -
Tobias Schwinger