Suggested change to type_traits/function_traits
I only just now subscribed to this list so forgive me if this has been suggested and rejected before. Currently function_traits<F> exposes the argument types for F as individual typedefs, arg1_type, arg2_type, etc. I think this could be made more powerful with two changes: 1. First, change it to be 0 indexed, arg0_type should be first. This is more consistent with the rest of boost and C++ in general. 2. Have an inner arg struct, templated over an integer indicating which argument you want. So instead of: typedef some_type arg0_type; typedef some_other_type arg1_type; //... You would have: template<int i> struct arg template<> struct arg<0> { typedef some_type type; } template<> struct arg<1> { typedef some_other_type type; } // etc. I think this would make function_traits more usable for metaprogramming. As is, to access the different argN_types you have to resort to using boost preprocessor. For backwards compatibility the old interface could co-exist with the new one.
Joseph Garvin wrote:
I only just now subscribed to this list so forgive me if this has been suggested and rejected before.
Currently function_traits<F> exposes the argument types for F as individual typedefs, arg1_type, arg2_type, etc. I think this could be made more powerful with two changes:
1. First, change it to be 0 indexed, arg0_type should be first. This is more consistent with the rest of boost and C++ in general.
IIRC, Boost.Bind, Boost.Lambda and Boost.Spirit uses 1-based argument indexing for their placeholders. Regards, Johan Nilsson
Hi,
2. Have an inner arg struct, templated over an integer indicating which argument you want. So instead of:
typedef some_type arg0_type; typedef some_other_type arg1_type; //...
You would have:
template<int i> struct arg
template<> struct arg<0> { typedef some_type type; }
template<> struct arg<1> { typedef some_other_type type; }
// etc.
I think this would make function_traits more usable for metaprogramming. As is, to access the different argN_types you have to resort to using boost preprocessor. For backwards compatibility the old interface could co-exist with the new one.
The Boost function_types library which I'm using since yesterday is more like this (but not exactly like this) and defining meta-functions and MPL sequences. Besides that it has the advantage that it works for both normal functions and for member functions. Regards, Barend
Joseph Garvin wrote:
I only just now subscribed to this list so forgive me if this has been suggested and rejected before.
There are searchable archives.
Currently function_traits<F> exposes the argument types for F as individual typedefs, arg1_type, arg2_type, etc. I think this could be made more powerful with two changes:
1. First, change it to be 0 indexed, arg0_type should be first. This is more consistent with the rest of boost and C++ in general.
That would be a breaking change, so untenable.
2. Have an inner arg struct, templated over an integer indicating which argument you want. So instead of:
typedef some_type arg0_type; typedef some_other_type arg1_type; //...
You would have:
template<int i> struct arg
template<> struct arg<0> { typedef some_type type; }
template<> struct arg<1> { typedef some_other_type type; }
// etc.
I think this would make function_traits more usable for metaprogramming. As is, to access the different argN_types you have to resort to using boost preprocessor. For backwards compatibility the old interface could co-exist with the new one.
Adding the new interface is not unreasonable. Whether the two should have different starting indices is arguable. std::get<0>(t) returns the first element of the tuple t, for example, but I think arguments are typically addressed with one-based indices, and using different starting indices would be potentially confusing in the same trait. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (4)
-
Barend Gehrels -
Johan Nilsson -
Joseph Garvin -
Stewart, Robert