[type_at] Variadic template utility
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time. You can find source code consisting of a single header at Vault/Utilities/type_at.hpp The usage is simple: boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type corresponds to some_type_index where index is in range [0..n]. For example: boost::type_at<2, int, float, char, long>::type corresponds to char. I hope this will be useful.
On Thu, May 26, 2011 at 8:34 AM, tymofey <tymofey@qip.ru> wrote:
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time.
You can find source code consisting of a single header at Vault/Utilities/type_at.hpp
The usage is simple:
boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type
corresponds to some_type_index where index is in range [0..n]. For example:
boost::type_at<2, int, float, char, long>::type
corresponds to char.
Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's 'at' metafunction? - Rob.
Robert Jones <robertgbjones@gmail.com> On Thu, May 26, 2011 at 8:34 AM, tymofey <tymofey@qip.ru> wrote:
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time.
You can find source code consisting of a single header at Vault/Utilities/type_at.hpp
The usage is simple:
boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type
corresponds to some_type_index where index is in range [0..n]. For example:
boost::type_at<2, int, float, char, long>::type
corresponds to char.
Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's 'at' metafunction?
- Rob.
It is, but without the need to drag in mpl::vector with the limitations it imposes.
On 05/26/11 04:47, tymofey wrote:
Robert Jones <robertgbjones@gmail.com> On Thu, May 26, 2011 at 8:34 AM, tymofey <tymofey@qip.ru> wrote:
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. [snip] Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's 'at' metafunction?
- Rob.
It is, but without the need to drag in mpl::vector with the limitations it imposes.
Could you please describe those limitations, other than the one for maximum arity, which, IIUC, is modifiable by redefining the macro: BOOST_MPL_LIMIT_VECTOR_SIZE ? Also, IIUC, one reason for using the macro, and the preprocessor, is to speed compile time by reducing the number of template instantiations. Thus, maybe one advantage of mpl::at vs your type_at is compile time. You might check that somehow. -regards, Larry
On 26/05/2011 13:19, Larry Evans wrote:
On 05/26/11 04:47, tymofey wrote:
Robert Jones<robertgbjones@gmail.com> On Thu, May 26, 2011 at 8:34 AM, tymofey<tymofey@qip.ru> wrote:
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. [snip] Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's 'at' metafunction?
- Rob.
It is, but without the need to drag in mpl::vector with the limitations it imposes.
Could you please describe those limitations, other than the one for maximum arity, which, IIUC, is modifiable by redefining the macro:
BOOST_MPL_LIMIT_VECTOR_SIZE
? Also, IIUC, one reason for using the macro, and the preprocessor, is to speed compile time by reducing the number of template instantiations. Thus, maybe one advantage of mpl::at vs your type_at is compile time. You might check that somehow.
You cannot expand a template parameter pack to instantiate a non-variadic template. Typically, this template<typename... T> struct make_vector { typedef boost::mpl::vector<T...> type; }: doesn't work. GCC gives the error: sorry, unimplemented: cannot expand 'T ...' into a fixed-length argument list And I believe the standard doesn't require it just because it would be difficult to implement in GCC's codebase.
Mathias Gaunard wrote:
On 26/05/2011 13:19, Larry Evans wrote:
On 05/26/11 04:47, tymofey wrote:
Robert Jones<robertgbjones@gmail.com> On Thu, May 26, 2011 at 8:34 AM, tymofey<tymofey@qip.ru> wrote:
... You cannot expand a template parameter pack to instantiate a non-variadic template.
Typically, this
template<typename... T> struct make_vector { typedef boost::mpl::vector<T...> type; }:
doesn't work.
GCC gives the error: sorry, unimplemented: cannot expand 'T ...' into a fixed-length argument list
And I believe the standard doesn't require it just because it would be difficult to implement in GCC's codebase.
My understanding is that the spec requires this to be well-formed code. Clang doesn't currently accept it, and I made a PR against it some time ago: http://llvm.org/bugs/show_bug.cgi?id=9021
Larry Evans <cppljevans@suddenlink.net> On 05/26/11 04:47, tymofey wrote:
Robert Jones <robertgbjones@gmail.com> On Thu, May 26, 2011 at 8:34 AM, tymofey <tymofey@qip.ru> wrote:
While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. [snip] Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's 'at' metafunction?
- Rob.
It is, but without the need to drag in mpl::vector with the limitations it imposes.
Could you please describe those limitations, other than the one for maximum arity, which, IIUC, is modifiable by redefining the macro:
BOOST_MPL_LIMIT_VECTOR_SIZE
? Also, IIUC, one reason for using the macro, and the preprocessor, is to speed compile time by reducing the number of template instantiations. Thus, maybe one advantage of mpl::at vs your type_at is compile time. You might check that somehow.
-regards, Larry
The size of the vector is the only limitation i'm know of. And I wasn't aware that one can change it thus making my proposal pretty usless. Thanks for the info.
participants (5)
-
Johannes Schaub (litb) -
Larry Evans -
Mathias Gaunard -
Robert Jones -
tymofey