+ On Mon, Sep 8, 2025 at 10:07 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Klemens Morgenstern wrote:
I think it's more a naming problem. If the resultset was named cursor or result_cursor or something a lot of it would be more obvious.
Probably not. "Cursor" still implies that you can have several.
I wrote a new design the statement/resultset to follow the sqlite API closer and implement C++ conventions here: https://github.com/klemens-morgenstern/sqlite/pull/16 new docs: http://klemens.dev/sqlite-statement This removes the resultset & static_resultset completely and makes iterating the statement explicit. Instead of for (auto res : conn.prepare("select 42").execute<std::tuple<int>>()); it is now: auto q = conn.prepare("select 42"); for (auto res : sqlite::statement_range<std::tuple<int>>(q)); // or for (auto itr = sqlite::statement_iterator<std::tuple<int>>(q); itr != sqlite::statement_iterator<std::tuple<int>>(q); itr ++); Where sqlite::statement_range behaves like std::ranges::istream and sqlite::statement_iterator like std::istream_iterator. By default, they return a `sqlite::row`, but as shown above, they can be modified to provide the same functionality as the previous static_resultset. By using input iterators the ownership should be completely obvious now and it should work as any experienced sqlite developer expects. I think this addresses the major issue (since the connection ownership design is trivial and has been discussed), but I'd like to ask for some feedback on this design.