Why prevent copies?
g-pechorin opened this issue · 3 comments
This is a "it works for me, what am I missing?" issue;
Why prevent copying?
I'm working with the generators to implement iterators for a complex container. If we/I assume that user-code is smart enough to copy their members, why prevent the generators from copying?
I suspect that copy operation is not applicable to generators as it may create forks...
But I think that move semantics for generators does make sence - to support swap operation at least.
And swap is needed to support iterators on hierarchical trees for example.
Why do you need to copy generator instance? What is your use case ?
I'm trying to use the generator as the guts of an iterator. The container is (homemade and) formed from a linked list of std::vector
and I lack (the free time for) a more inspired solution.
If I want member variables that are $generator
instances then I need copy (or move I guess) so that I can return the instances - right?
I think that I'm coming from a "pure functional" (Scala) background here so I hadn't considered that the $generator
would be relying on "external state" to get its job done.
- my
$generator
which works by emitting a pointer to the next element - my iterator which wraps the
$generator
- iterator emitting a pointer to the next element which comes out of the
$generator
As far as I can see you have explicit copy constructor of the generator, right?
If so then conceptually that is right thing to do.
I am disabling blind copy constructor to prevent cases when C++ creates copies of variables under the hood. Calling yield on copy will not update state of the copied iterator for obvious reasons.