Range for loop for statements

[Alvov1]

Closes #181

Adds a nested RowIterator class to Statement that enables range-based for loops over query results:

SQLite::Statement query(db, "SELECT id, name FROM test");
for (SQLite::Statement& row : query)
{
    std::cout << row.getColumn(0).getInt() << "\n";
}

Notes:

• begin() calls reset() automatically, so re-iterating the same Statement always starts from the beginning
• Bindings set before the loop are preserved across reset()
• Empty result sets are handled correctly (loop body never executes)
• RowIterator satisfies std::input_iterator_tag with full iterator traits

[SRombauts]

The PR description calls this "full iterator traits." The traits are all here, but the interface isn't: there's no operator== and no post-increment operator++(int) next to this operator!=. Range-based for only calls operator!=, so nothing breaks today. The catch is that anyone who reaches for it with <algorithm>, or checks it against the C++20 std::input_iterator concept (which requires ==), hits a wall. Either add operator== and post-increment, or soften the claim to "usable in range-based for loops."

[SRombauts]

This line is redundant: the copy constructor gets generated anyway. Declaring it also has two quiet side effects: it makes implicit copy-assignment deprecated, and it suppresses the implicit move members, so moves fall back to copy (harmless for a single pointer, but not the intent). The RowIterator() = default; above it is the one that's actually needed, since the Statement* constructor suppresses the implicit default constructor. For a trivial pointer holder I'd drop this line and let copy, move, assignment, and the destructor stay implicit (Rule of Zero). Not blocking.

[SRombauts]

Very minor and not blocking, not really an issue: the diff drops a blank line here (and another around prepareStatement() below) that aren't part of the iterator change. You could revert them to keep the diff focused, but it's completely fine to leave as-is if you prefer.

[SRombauts]

Thanks, all three earlier points are addressed. Two small follow-ups below, both non-blocking.

[SRombauts]

The implementation is fine, but the doc overstates it. It compares the Statement*, not the row, so two live iterators over the same statement always compare equal regardless of position. That is correct for a single-pass stream iterator (it is how std::istream_iterator works, and your @warning already rules out two live iterators). Only the wording needs to match:

/// Return true when both iterators refer to the same statement, or are both the end sentinel.

[SRombauts]

Worth flagging: the copy this returns shares the one live cursor, so *it++ gives the row after the increment, not before. This is inherent, not a bug to chase down. operator* hands back the single Statement&, Statement is move-only (Statement.h:79), and sqlite overwrites the row data on the next step, so the returned copy cannot hold the old row. std::istream_iterator gets away with *it++ because it caches its value by copy; here the value is a live cursor, so we cannot.

Caching the row would mean copying every column into the iterator, which is not worth it. The honest signal for a single-pass iterator is to return void from post-increment:

void RowIterator::operator++(int) { ++*this; }

That still satisfies std::input_iterator (weakly_incrementable only requires i++ to be a valid expression, with no constraint on its return type), and it turns auto old = *it++; into a compile error instead of a silent wrong-row read. If you would rather keep the conventional copy-returning form, add a @warning saying the iterator is single-pass and *it++ reflects the advanced row.

[SRombauts]

Hey @Alvov1, thanks a lot for your contribution!
I was going to approve and merge it as-is, but I discovered the subtleties of the operation++() return value (see review comment above).
It's not a big deal, but I'd like to know what you think of it: I would just return void if it was me, but you may have other ideas on how you would use it yourself
Cheers!
Sébastien

[SRombauts]

One more thought, and only if you are up for it: this feature is genuinely nice, and right now the only place it shows up is the tests. Would you be open to adding a small bit of documentation so people actually discover it? The natural spot is the query loop snippet in README.md (around line 341), where the classic while (query.executeStep()) example lives; showing the range-based for equivalent right next to it would do the job. A short variant in examples/example1/main.cpp would also work and has the bonus of being compiled by CI.

No worries if you would rather I add it after merging, just let me know which you prefer.