Peter,
> On 8/3/17, 4:22 AM, "sqlite-users on behalf of Ulrich Telle" wrote:
> > IMHO it would be better if the function sqlite3_bind_pointer would make a
> > copy of the type string
> > and would thus be independent of the life span of the type parameter.
>
> I believe that this was a deliberate choice to deter using temporary strings
> for type names.
Well, the comment regarding the type parameter ("The T parameter should be a
static string, preferably a string literal.") just tells that the type string
"should" be static. It doesn't warn that it doesn't work if the life time of
the type string is shorter than that of the statement to which the pointer is
bound. At least the description should be enhanced.
If one uses the SQLite3 API directly, this is most probably not a big deal,
since most likely string literals will be used to specify the pointer type. But
as soon as one tries to implement a SQLite wrapper (may it be for C++ or other
languages like Python etc), this restriction makes things cumbersome. String
parameters may not be guaranteed to live as long as needed, and it might be
necessary to convert them to const char* before passing them on to SQLite. Then
you have to implement some sort of housekeeping (or have to live with memory
leaks, if you allocate a copy yourself and never free it). Since SQLite already
does housekeeping regarding the pointer itself, I assume that it wouldn't be
too difficult to extend this to make a copy of the type string and free it,
when the pointer value goes out of scope and its destructor is invoked.
Regards,
Ulrich
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
