czw., 11 wrz 2025 o 12:56 Klemens Morgenstern via Boost < boost@lists.boost.org> napisał(a):
+ 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.
Thank you for a quick turnaround. My feedback is based on reading the docs rather than looking at the implementation. I am confused by the usage of the name "prepare". For me, it associates with the idea of a "prepared statement", and "prepared statement" for me means "not ready to execute yet: you need to provide values in place of all the placeholders first." Is my intuition wrong? Maybe use q.statement_range<type>() rather than sqlite::statement_range<type>(q) ? Or is statement_range applicable to anything other than statement? I also do not understand the idea behind the second true/false argument. How can type checks not be performed when I explicitly provide types to which to cast the values? Anyway, a naked true/false argument is difficult to understand when seen in the code. Maybe instead two functions: sqlite::statement_range<type>(q); sqlite::statement_range_strict<type>(q); ? Regards, &rzej;