[fusion] transform & iterators
For the first attached testcase, can anyone explain why "Doesn't" doesn't? I would not expect the second test to compile. But is there some way to bridge the gap between fusion iterators, boost.Range ranges and standard iterators? Is there any way to turn a fusion iterator into a standard- conforming iterator? -Dave
On 3/11/2010 12:11 PM, David A. Greene wrote:
For the first attached testcase, can anyone explain why "Doesn't" doesn't?
Because fusion::transform is purely functional --takes its arguments as const and returns a transformed view and returns a view which is also const (immutable). In that regard, fusion is more like MPL (functional) than STL (imperative).
I would not expect the second test to compile. But is there some way to bridge the gap between fusion iterators, boost.Range ranges and standard iterators? Is there any way to turn a fusion iterator into a standard- conforming iterator?
There's no way I know that would allow that. First, fusion iterators have different types for each iterator position, unlike STL where begin and end and everything in between have a single iterator type. IOTW, fusion iterators are polymorphic. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
On Thursday 11 March 2010 01:50:14 Joel de Guzman wrote:
On 3/11/2010 12:11 PM, David A. Greene wrote:
For the first attached testcase, can anyone explain why "Doesn't" doesn't?
Because fusion::transform is purely functional --takes its arguments as const and returns a transformed view and returns a view which is also const (immutable). In that regard, fusion is more like MPL (functional) than STL (imperative).
Ok, but if push_back takes an argument by const reference, what's the problem? Is bind() messing things up by creating a function object that expects a non-const reference? push_back isn't altering the sequence in any way so immutability shouldn't be a problem.
I would not expect the second test to compile. But is there some way to bridge the gap between fusion iterators, boost.Range ranges and standard iterators? Is there any way to turn a fusion iterator into a standard- conforming iterator?
There's no way I know that would allow that. First, fusion iterators have different types for each iterator position, unlike STL where begin and end and everything in between have a single iterator type. IOTW, fusion iterators are polymorphic.
Ugh. That makes things difficult then. There's no simple way to define a function that just takes a pair of iterators and does something with them. Surely others have tried to do things like this before. What's the typical solution? -Dave
AMDG David Greene wrote:
On Thursday 11 March 2010 01:50:14 Joel de Guzman wrote:
There's no way I know that would allow that. First, fusion iterators have different types for each iterator position, unlike STL where begin and end and everything in between have a single iterator type. IOTW, fusion iterators are polymorphic.
Ugh. That makes things difficult then. There's no simple way to define a function that just takes a pair of iterators and does something with them. Surely others have tried to do things like this before. What's the typical solution?
Use a recursive function template or use one of fusion's algorithms. In Christ, Steven Watanabe
On Thursday 11 March 2010 11:39:10 Steven Watanabe wrote:
Ugh. That makes things difficult then. There's no simple way to define a function that just takes a pair of iterators and does something with them. Surely others have tried to do things like this before. What's the typical solution?
Use a recursive function template or use one of fusion's algorithms.
But the non-compiling example in the first testcase shows that a fusion
algorithm doesn't provide a general solution. The sequence could be the
result of an application of transform() or some other algorithm that causes
problems. Unless there's some other technique I've missed.
In any case, I wasn't completely clear about what my goal is. Ultimately
I'd like to initialize a class with a pair of iterators:
struct foo {
vector<int> data;
template<typename InputIterator>
foo(InputIterator begin, InputIterator end) : data(begin, end) {}
};
foo could be initialized from many different kinds of sources:
vector<int> mydata;
foo f(mydata.begin(), mydata.end());
fusion::vector
David A. Greene schrieb:
On Thursday 11 March 2010 11:39:10 Steven Watanabe wrote:
Ugh. That makes things difficult then. There's no simple way to define a function that just takes a pair of iterators and does something with them. Surely others have tried to do things like this before. What's the typical solution?
Use a recursive function template or use one of fusion's algorithms.
But the non-compiling example in the first testcase shows that a fusion algorithm doesn't provide a general solution. The sequence could be the result of an application of transform() or some other algorithm that causes problems. Unless there's some other technique I've missed.
Change the signature of square's invocation operator to result_type operator()(int i) const and the sample should compile fine.
In any case, I wasn't completely clear about what my goal is. Ultimately I'd like to initialize a class with a pair of iterators:
[snip]
Unfortunately, it appears this isn't possible and foo will need at least two constructors:
struct foo { vector<int> data;
template<typename InputIterator> foo(InputIterator begin, InputIterator end) : data(begin, end) {}
template<typename Sequence> foo(Sequence d) { // Some fusion algorithm } };
That's correct.
But that doesn't seem to be a general solution either due to the transform() problem described above.
Joel referred to fusion::transform taking the sequence cref qualified only. This should not be a limitation for your particular use-case though. -Christopher
participants (5)
-
Christopher Schmidt -
David A. Greene -
David Greene
-
Joel de Guzman -
Steven Watanabe