Non-pointer iterators....

[fungus]

Re: Non-pointer iterators....

Clark S. Cox III wrote:

>
No need for it to even contain a single object; just use that
container's "end" iterator.
>

I could do that with some of the code but
not all of it. Some of the code was working
on a subset of data so I don't know where
container.end() is.


--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.


We’re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It’s a completely nonsensical process.

[fungus]

Re: Non-pointer iterators....

P.J. Plauger wrote:

"fungus" <umailMY@SOCKSa rtlum.comwrote in message

>So it's the work of the Code-Nazis, no real reason?

>
You've been given several good reasons, but now you're being
deliberately provocative.
>

The point is that it broke code (and I suspect
not just mine). I'd expect more of a reason
than it's "more correct to do it that way".


--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.


We’re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It’s a completely nonsensical process.

[P.J. Plauger]

Re: Non-pointer iterators....

"fungus" <umailMY@SOCKSa rtlum.comwrote in message
news:m95jh.322$ Pz.317@news.ono .com...

P.J. Plauger wrote:

>"fungus" <umailMY@SOCKSa rtlum.comwrote in message

>

>>So it's the work of the Code-Nazis, no real reason?

>>
>You've been given several good reasons, but now you're being
>deliberately provocative.
>>

>
The point is that it broke code (and I suspect
not just mine). I'd expect more of a reason
than it's "more correct to do it that way".

About 40-odd years ago, Princeton University upgraded their
IBM 7090 to an IBM 7094, which added a divide-check trap.
Where the 7090 treated a zero divide like division by 1.0,
the 7094 terminated execution. Within the first week of
turning on this feature, a significant fraction of all
Fortran programs regularly trapped out. Some of these had
been working for years and doing mildly important things
like plotting spacecraft trajectories and analyzing cancer
data.

By the second week, the community was unanimous in
demanding that the damned thing be turned off. They
*liked* the erroneous answers they had been getting.

My personal taste has drifted, over the decades, in the
direction of greater safety and reliability in writing
and running computer programs. YMMV.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Bo Persson]

Re: Non-pointer iterators....

fungus wrote:

P.J. Plauger wrote:

>"fungus" <umailMY@SOCKSa rtlum.comwrote in message

>

>>So it's the work of the Code-Nazis, no real reason?

>>
>You've been given several good reasons, but now you're being
>deliberately provocative.
>>

>
The point is that it broke code (and I suspect
not just mine). I'd expect more of a reason
than it's "more correct to do it that way".

The code was broken all along, it just happened to work on one specific
implementation.

The standard allows a vector::iterato r to be a pointer, but it does not
require it. Most other iterators cannot be pointers.


Henry Ford once thought all cars should be black (because it simplified his
Model T implementation) . We shouldn't base our code on such an assumption
always being valid.


Bo Persson

[Rolf Magnus]

Re: Non-pointer iterators....

fungus wrote:

P.J. Plauger wrote:

>"fungus" <umailMY@SOCKSa rtlum.comwrote in message

>

>>So it's the work of the Code-Nazis, no real reason?

>>
>You've been given several good reasons, but now you're being
>deliberately provocative.
>>

>
The point is that it broke code (and I suspect not just mine).

No, the code was already broken. I already told you: If you want something
that behaves like a pointer, then just use a pointer. If you use an
iterator, don't assume it offers anything else than the standard iterator
interface. Assumptions tend to lead to code that is slow, unportable or
plain incorrect.

I'd expect more of a reason than it's "more correct to do it that way".

You've already been told that it also allows better run-time checking (esp.
in debug builds), e.g. when trying to increment an iterator beyond the end
of the container or using an iterator with a container that it doesn't
belong to.