List:MySQL++« Previous MessageNext Message »
From:Paul Date:January 10 2006 5:57am
Subject:Re: subscript_iterator -> operator.
View as plain text  
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.
> 

Thread
subscript_iterator -> operator.alan.alvarez5 Jan
  • Re: subscript_iterator -> operator.Warren Young5 Jan
    • Re: subscript_iterator -> operator.Paul5 Jan
      • Re: subscript_iterator -> operator.Warren Young6 Jan
        • Re: subscript_iterator -> operator.Paul6 Jan
Re: subscript_iterator -> operator.Warren Young10 Jan
  • Re: subscript_iterator -> operator.Paul11 Jan
    • Re: subscript_iterator -> operator.Denis ERCHOFF11 Jan