while (*it1==*it2) { // or: while (pred(*it1,*it2)) for version 2
if (it2==last2) return first1;
if (it1==last1) return last1;
++it1; ++it2;
}
This compares the values the iterators are referencing, then afterwords checks to see if the ends of the ranges have been reached. This implies that it is acceptable to dereference last1 and last2.
It looks like cppref checks for last before dereferencing, if I'm reading it correctly. Seems like it's only an issue on this side.
The actual code that's inside the implementation-part of <algorithm> (specifically, stl_algo.h in GCC) is hard to follow, but it definitely does some checking before it ever calls the predicate and also checks for "++__p == __last2" and "++__current == __last1" as well, similar to cppref but more condensed.
It looks like both bits of code, here and at cppreference, are not the end-all of how to implement the algorithm in full. It is pared-down slice of code to show what it does, without the overhead of all the code to make it actually work.
Yeah, they're both pared down, that's cool. I'm just concerned about sending students here and them seeing a comparison to last *after* a value comparison.
The cplusplus C++ reference is seriously outdated, sending students here IMO is really not recommended for reference material. Updates stalled around the time C++14 was either at the stages of being finalized or just afterwards is my guess by what is and isn't in the reference. The curse of a solo person as admin with that nasty real life taking precedence.
cppreference IS updated quite frequently, team effort. They have begun adding C++20 material as it gets put in the "done" out-basket.
Send student there, not here.
Asking questions, needing gentle nudges with written code, but of course here.
Also, cppreference.com is a Wiki, so you are more than welcome to fix the reference code (I think). Just be sure to get it right, or some other wikier will be obnoxious about it.
I tend to ignore "reference implementations" just because they tend to be a little off. Teach your students to read the documentation for what it is supposed to do, and remind them that the actual implementation can do it any way it likes, so long as the result matches the documented behavior.
Do go ahead and point out to students that even stuff they see online written by people who should know better will have fencepost errors. It is a distressingly common source of bugs in the software industry.
Perhaps point them to it and ask them if they can figure out what is wrong with it, and what to do to fix it.
Here is how the GNU Standard Library does it (simplified):
1 2 3 4
while (*it1==*it2) { // or: while (pred(*it1,*it2)) for version 2
if (++it2==last2) return first1;
if (++it1==last1) return last1;
}
One very teeny tiny part of the abstraction that IMO went a bit too far, and so makes finding out what it means to use it in the "normal" way is (one method) how to seed a C++ random engine.
What does the C++ standard have to say about how "epoch" is implemented?
1. Does it state a specific date/time must be used?
2. Does it state how epoch is implemented left up to the implementation?
3. Is it silent, no word about how it is to be implemented? So again it boils down to each implementation "rolls its own."
Your link, Grey Wolf, shows that it is either 2 or 3. Something every other reference or mention of epoch I've found online implies. But nothing definitive..."The C++ standard says/mandates....." or even some wording that gives a hint.
While I don't know the exact standard specifications every reference I've run across regarding std::random_device indicates (in a roundabout way) what the standard is for implementing it. Because of varying hardware/OS parameters.
"Ok, compiler makers, you decide if you want a truly non-deterministic engine."
FurryGuy, Sorry, it was not meant to answer your question directly (I don't know what the C++ standard says about what epoch to use) it was just meant to show there is more than one in use.