Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for string_view #298

Open
KingDuckZ opened this issue Sep 4, 2020 · 2 comments
Open

Add support for string_view #298

KingDuckZ opened this issue Sep 4, 2020 · 2 comments
Assignees

Comments

@KingDuckZ
Copy link

Not sure if this is possible, but it would be nice to have string_view support in calls to bind()

@pylorak
Copy link

pylorak commented Mar 21, 2023

IMHO the benefits of string_view are not many for SQLiteCpp. Most strings it receives from callers are passed on to sqlite3 which requires C-style zero-terminated strings. This means for each string_view passed in, a copy of the string needs to be allocated and padded with a null-byte (since string_views will usually not be null-terminated).

Note that if the caller already has a std::string, passing string_views is actually worse than passing in the std::string by const-ref, because the c_str() member function of std::string is non-allocating in practical implementations. So with a string_view you force an extra allocation.

This means in the case of SQLiteCpp, string_views are only useful to hide the extra allocations needed in any case when passing in a substring inside a larger memory area.

@ztane
Copy link

ztane commented Dec 27, 2023

@pylorak I believe you're not quite right. SQLite3 documentation says:

If a non-negative fourth parameter is provided to sqlite3_bind_text() or sqlite3_bind_text16() or sqlite3_bind_text64() then that parameter must be the byte offset where the NUL terminator would occur assuming the string were NUL terminated. If any NUL characters occurs at byte offsets less than the value of the fourth parameter then the resulting string value will contain embedded NULs. The result of expressions involving strings with embedded NULs is undefined.

I.e. it is perfectly fine to not terminate them, and therefore using string_view would constitute an optimization, not pessimization throughout.

Furthermore, the same applies to queries. It is quite common to have fixed queries in an application. Now with C++17 literals you could do something like static const auto query = "INSERT INTO foo (bar, baz) VALUES (?, ?)"sv; to get a string_view literal which, unlike std::string is certainly not going to have heap-allocated contents and expensively initialized at start-up, yet would know its length.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants