Chap 20 Ex04 JackAndJill

[chrinkus]

Chap 20 Ex04 JackAndJill

[Chrinkus]

Thanks for the kind words. You’re probably right, Uncle Bjarne is a stickler for bounds-checking. How do you think the function should handle this error?

[Josh1603]

I thought this line should fix it.
if (first > last) throw; //Could lead to infinite iterations

However, It looks like comparison operators for iterators are more complex than I'd thought. It seems that comparison is only guaranteed to hold true if the iterator used is a Random Access Iterator (as it's the only type of iterator which provides a > operator).

I think it works for the Jack and Jill examples as they use pointers to an array where the data is stored contiguously in memory (so regular pointer arithmetic can be used) and a vector (with a random access iterator) respectively. Not so sure how to handle this in other cases though.

I did find something about using the std::less function for strict totally ordering of pointers that are not implemented as addresses in continuous virtual address space here but I think I could be barking up the wrong tree (ah-hem) about the relevance of that to non-random access iterators.

Pretty stumped!

(Also to make matters worse, I guess I'm only considering the case of the user mixing up the start and end iterator of the same collection. If they were even further off the mark and mixed up iterators from different collections, then it would likely lead to further issues.)

[Josh1603]

So yeah, it's probably the case that the potential for mixed up iterators isn't the issue. Come to think of it, if the iterators are range checked, it shouldn't even lead to the infinite looping issue...

The program crashes when jill.txt is empty because there's attempted access to an empty vector. So it could simply be that there should be an equality check between the start and end iterator to make sure the container isn't empty and there's actually some data to analyse.

if (first == last) throw; //Empty containers make the loudest noise.

As equality checks work for all iterators and it gets mentioned as a technique later in the chapter, I think that's more likely to be the solution.

[Chrinkus]

I'm so sorry for not responding to this, its been a rough fall-return to work. Looking at this problem again, I believe you're right in your last comment. In neither get_from_ call do we check to see if we have any data. That's okay-ish but after calling high on either of our data sets we should check afterwards to see if the returned iterator, or pointer in this case, is valid.

Something like:
if (jack_high != jack_data + jack_count) // use data

Lastly, I believe that throwing from an algorithm is bad form. Instead we do as above and return the "end" iterator if there's any issue. That would cover most empty container situations since "first" would equal "last" and the loop would never execute.

for (Iterator p = first; p != last; ++p) // guards against empty container