[mpl] sequence details
Hi, What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ? I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this. In a library I'm currently working on, I use a decorator pattern to make a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization. Thanks for your help, Tobias
Tobias Schwinger wrote:
Hi,
What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ?
I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this.
In a library I'm currently working on, I use a decorator pattern to make
[ This refers to: http://tinyurl.com/6c35p ]
a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization.
Thanks for your help,
Tobias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tobias Schwinger <tschwinger@neoscientists.org> writes:
Tobias Schwinger wrote:
Hi, What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ?
I was hoping Aleksey would answer, but he seems to have dropped off the face of the earth (temporarily, I hope). I am guessing that Aleksey would say "don't do that!" He has always maintained that relying on sequence type identity was just wrong.
I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this. In a library I'm currently working on, I use a decorator pattern to make
[ This refers to: http://tinyurl.com/6c35p ]
a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization.
I don't know the details of your problem, so I can't say for sure, but you might consider using partial specialization based on the sequence's tag and/or size. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Dave, David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
Tobias Schwinger wrote:
Hi, What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ?
I was hoping Aleksey would answer, but he seems to have dropped off the face of the earth (temporarily, I hope).
Thanks for your attempt to fill the (hopefully temporary) gap.
I am guessing that Aleksey would say "don't do that!" He has always maintained that relying on sequence type identity was just wrong.
This, in itself, makes pretty much sense to me. However, I need to get to the types "all at once" rather than "one at a time" (details below).
I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this. In a library I'm currently working on, I use a decorator pattern to make
[ This refers to: http://tinyurl.com/6c35p ]
a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization.
I don't know the details of your problem, so I can't say for sure, but you might consider using partial specialization based on the sequence's tag and/or size.
I am working on a library which allos to work with function types [ the link above points to the announcement of the preview version on this list, yesterday ]. The problem lies in the metafunction to synthesize function types from an MPL Seuqence [ ref. class template function_type ]: The current procedure is: - check for the sequence tag - if it is a vector use its ::type member - if it is an mpl sequence, but not a vector use mpl::copy to make it (other cases are checked for, that do not matter in this context) - the _impl-part of the story then uses a partial specialization cascade to extract the elements - build the function type from them (this works fine for non-typeof-based sequences) Specializing by size would mean: - use at_c for every element - build the function type from them (reads nicely here, but has to be done for the whole cascade, (max_arity*kinds_of_function_types_supported) times, which would result in an unreadable and inefficient mass of code) Probably the latter is still the better way to go, however, I was hoping (and still do) for a better solution than these two. Unless you (or someone on the list) knows one, it's probably a wise idea to just wait for Aleksey to reappear before changing things around... Best regards, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
Hi Dave,
David Abrahams wrote:
Tobias Schwinger wrote:
Hi, What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ? I was hoping Aleksey would answer, but he seems to have dropped off
Tobias Schwinger <tschwinger@neoscientists.org> writes: the face of the earth (temporarily, I hope).
Thanks for your attempt to fill the (hopefully temporary) gap.
I am guessing that Aleksey would say "don't do that!" He has always maintained that relying on sequence type identity was just wrong.
This, in itself, makes pretty much sense to me.
However, I need to get to the types "all at once" rather than "one at a time" (details below).
I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this. In a library I'm currently working on, I use a decorator pattern to make
[ This refers to: http://tinyurl.com/6c35p ]
a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization. I don't know the details of your problem, so I can't say for sure, but you might consider using partial specialization based on the sequence's tag and/or size.
I am working on a library which allos to work with function types [ the link above points to the announcement of the preview version on this list, yesterday ].
The problem lies in the metafunction to synthesize function types from an MPL Seuqence [ ref. class template function_type ]:
The current procedure is:
- check for the sequence tag - if it is a vector use its ::type member - if it is an mpl sequence, but not a vector use mpl::copy to make it (other cases are checked for, that do not matter in this context)
That seems sorta crazy.
- the _impl-part of the story then uses a partial specialization cascade to extract the elements - build the function type from them (this works fine for non-typeof-based sequences)
Specializing by size would mean:
- use at_c for every element
Not at all; just use iterators dereference and increment them. boost/python/detail/caller.hpp uses this pattern.
- build the function type from them (reads nicely here, but has to be done for the whole cascade, (max_arity*kinds_of_function_types_supported) times, which would result in an unreadable and inefficient mass of code)
This is going to be a job for the PP library, no matter what you do.
Probably the latter is still the better way to go, however, I was hoping (and still do) for a better solution than these two.
Unless you (or someone on the list) knows one, it's probably a wise idea to just wait for Aleksey to reappear before changing things around...
Suit yourself. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
- use at_c for every element
Not at all; just use iterators dereference and increment them. boost/python/detail/caller.hpp uses this pattern.
Well, that's nicer in case 'at' has non-constant complexity. Still, I find this "surprisingly brutal". Can you give me a vague idea of this technique's performance (seconds/functions), if recognizable at all ?
This is going to be a job for the PP library, no matter what you do.
Oh! Use it already. My concern was about the preprocessed code (becomes huge, causes numerous template instantiations when used and in some way obscures the preprocessed headers). However, if it works for Boost.Python I'll call it "common practice" and just use it ;-). Thanks, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
- use at_c for every element
Not at all; just use iterators dereference and increment them. boost/python/detail/caller.hpp uses this pattern.
Well, that's nicer in case 'at' has non-constant complexity. Still, I find this "surprisingly brutal".
I don't see why. How would you fill up members of a struct with successive elements of a sequence? x.m1 = *i; ++i; x.m2 = *i; ++i x.m3 = *i; ... Yes, we have shorthands like *++i, but it amounts to the same thing.
Can you give me a vague idea of this technique's performance (seconds/functions), if recognizable at all ?
I have no data other than that it's "fast enough."
This is going to be a job for the PP library, no matter what you do.
Oh! Use it already. My concern was about the preprocessed code (becomes huge, causes numerous template instantiations when used and in some way obscures the preprocessed headers).
Sounds pretty FUDdy, duddy.
However, if it works for Boost.Python I'll call it "common practice" and just use it ;-).
Hope I helped. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Tobias Schwinger