Hi list, Alan, Warren,
Definately not std::auto_ptr<>
Try reading here for a start:
http://www.boost.org/libs/utility/operators.htm#deref
and
http://www.boost.org/libs/iterator/doc/iterator_facade.html#id2
I understand Warren's position on including Boost libraries, but usually
you can just extract out the key technique from the boost header files
and use it for your own purposes. The advantage of depending on Boost
is that you wouldn't have to worry about making that technique work with
various compilers. The disadvantage of depending on Boost is that its
an extra dependency thats not terribly useful in this case.
Also check out TR1, it is bits of Boost that have been approved to be
included in the C++ standard libraries in the near future.
the operator->() is a tricky problem, but there are solutions.
Personally I'd just (*iterator).whatever() in the meantime.
Paul
Warren Young wrote:
> alan.alvarez@stripped wrote:
>
>> Would saving a std::auto_ptr in the iterator object save this problem?
>
>
> I don't see how this solves the problem. Even if it did work, it would
> be arm-twisting the very purpose of auto_ptr, so I think you're looking
> in the wrong place. auto_ptr is not a universal smart pointer; there's
> a very limited scope within which it makes sense.
>
> I suggest you study the 1.7.40 version with the erroneous arrow
> operator. Once you can see what the error is, you will be in a better
> position to propose fixes. I guess you should also look at the Boost
> stuff Paul refered to.
>
> Beware: if the fix introduces a mandatory dependency on Boost, that
> alone might be grounds for rejection. At the moment, all I've talked
> myself into are optional features that may depend on Boost. Mandatory
> dependencies make configuration much more complex, particularly given
> some of the weirdnesses of Boost itself.
>
> P.S. You keep replying to me personally. Again: keep this traffic on
> the mailing list.
>
