A malloc error in C++ - incorrect checksum for freed object

[Jerry Coffin]

So you don't even need the vector part. How about just something that
acts like an iterator over an (infinite) sequence of identical values:

This would work for some situations, but quite a few algorithms expect
to see two iterators, one for the beginning of the sequence and the
other for its end. They expect the beginning iterator to become equal to
the end iterator after some finite number of increments, and unless you
provide iterators that act that way, the code will cause problems (e.g.
infinite loops).

 

[Richard Herring]

So you don't even need the vector part. How about just something that
acts like an iterator over an (infinite) sequence of identical values:

This would work for some situations,

e.g. the one under discussion.

but quite a few algorithms expect
to see two iterators, one for the beginning of the sequence and the
other for its end.

But the std:: algorithms that act on _two_ sequences have a different
expectation, namely that the second sequence be magically at least as
long as the first. This is one way of achieving that.

They expect the beginning iterator to become equal to
the end iterator after some finite number of increments, and unless you
provide iterators that act that way, the code will cause problems (e.g.
infinite loops).

Naturally, hence the word "infinite" above. That's what software design
is all about. You need to provide a class that most appropriately models
the relevant concept. "Bounded sequence" and "infinite sequence" are
different concepts, so the solutions are likely to be different too.

 

[Jerry Coffin]

In message <MPG.214c85e97bc4ed839899b5@news.sunsite.dk>, Jerry Coffin
<jcoffin@taeus.com> writes

[ ... ]

e.g. the one under discussion.

Yes, but not for many others.

[ ... ]

Naturally, hence the word "infinite" above. That's what software design
is all about. You need to provide a class that most appropriately models
the relevant concept. "Bounded sequence" and "infinite sequence" are
different concepts, so the solutions are likely to be different too.

I can't agree. There doesn't seem to be any situation (at least with the
standard algorithms) that actually requires an infinite sequence -- some
require it to be bounded, and others don't care. At least if memory
serves, the one I provided CAN act like an infinite sequence -- you can
increment the iterator and look at the value as often as you want to. It
also, however, allows you to check the iterator against a bound whenever
you want to, so it can act as either a bounded or unbounded sequence. I
can't see any advantage for only providing an unbouded sequence over
providing one that can act either bounded or unbounded as the situation
requires.

 

[Richard Herring]

In message <MPG.214c85e97bc4ed839899b5@news.sunsite.dk>, Jerry Coffin
<jcoffin@taeus.com> writes

[ ... ]

e.g. the one under discussion.

Yes, but not for many others.

Then one wouldn't use it in those situations.

[ ... ]

Naturally, hence the word "infinite" above. That's what software design
is all about. You need to provide a class that most appropriately models
the relevant concept. "Bounded sequence" and "infinite sequence" are
different concepts, so the solutions are likely to be different too.

I can't agree. There doesn't seem to be any situation (at least with the
standard algorithms) that actually requires an infinite sequence -- some
require it to be bounded, and others don't care. At least if memory
serves, the one I provided CAN act like an infinite sequence -- you can
increment the iterator and look at the value as often as you want to.

It's only as "infinite" as your "index" type: size_t, or whatever. Not
likely to be a problem, but not truly infinite.

It
also, however, allows you to check the iterator against a bound whenever
you want to, so it can act as either a bounded or unbounded sequence. I
can't see any advantage for only providing an unbouded sequence over
providing one that can act either bounded or unbounded as the situation
requires.

Simplicity. Your solution adds complexity because you need to model the
entire sequence and how to handle the bounds, whereas mine only needs to
model a single _element_ of the sequence (all elements are identical,
don't forget).

You need a pseudo-vector with a constructor and begin() and end() and
operator[] and an iterator with constructor and increment and
comparison, whereas I only need a pseudo-iterator. Having abstracted the
concept of iterator, I don't have to concern myself with the mechanics
of the sequence it iterates over. I don't have to code and test a vector
as well.

 

[Jerry Coffin]

I can't agree. There doesn't seem to be any situation (at least with the
standard algorithms) that actually requires an infinite sequence -- some
require it to be bounded, and others don't care. At least if memory
serves, the one I provided CAN act like an infinite sequence -- you can
increment the iterator and look at the value as often as you want to.

It's only as "infinite" as your "index" type: size_t, or whatever. Not
likely to be a problem, but not truly infinite.

At least IIRC, that's just not so -- the only time it tests against the
end() is when you ask it to. No matter how often you increment the
iterator returned by begin(), dereferencing the result still produces
the same value. You can compare to end() when/if you feel like it, but
if you don't do that comparison, it acts like an unbounded set.