Row: New class with iterators (WIP)

[Kacperos155]

What I'm trying to implement:

• Iterators
  • [x] InputIterator for SQLite::Statement with auto-reset on begin()
  • [x] BidirectionalIterator for SQLite::Row. Should be RandomAccessIterator but this is too much boilerplate code for probably non-existing gain.
• Class Row with methods to get:
  • [x] Row number (from 0 to n)
  • [x] Column object
  • [x] Column ID from name
• Internal code changes:
  • [x] Split row execution from SQLite::Statement - smaller files, better readability
  • [x] Better structure for weak_ptr with sqlite3_stmt
  • [x] Better enforcement of Column usage safety
• Other:
  • [x] Fix SQLite::Statement move constructor (and re-enable this test)
  • [x] Documenting comments for all new changes
  • [x] Tests coverage for changes and new functionality
  • [x] Many, many small changes...

Examples:

SQLite::Statement query(database, queryStr);

for(const auto& row : query)
{
    for(const auto& column : row)
    {
        std::cout << column.getName() << ": ";
        std::cout << column.getText() << "\t";
    }
    std::cout << '\n';
}

SQLite::Statement query(database, queryStr);

for (auto it = query.begin(); it != query.end(); std::advance(it, 2))
{
    std::cout << "Table row: " << it->getRowNumber() << '\n';
}

std::for_each(query.begin(), query.end(), [](const SQLite::Row& row)
{
    std::cout << row.getColumn(0).getText() << '\n';
});

[Kacperos155]

@SRombauts What do you think about this changes? Should this PR be separeted to smaller ones?

[dougnazar]

Ironically, I'd just done a simple iterator this morning before I saw yours. Mine was no where near as ambitious as yours, just basically a 80 line (mostly boiler-plate) wrapper around Statement.

[Kacperos155]

Iterator functionality is now working 😄 I am sure there isn't any API break excluding undefined behavior of Column class after destruction of Statement. Because of the scale of changes, I require code review to keep working on this. Also, this needs more test coverage, benchmarking and feedback, but I think any improvements to this should be in next PRs.