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