I agree that it's impossible to enforce "static strings" or "strings that live long enough" with the C/C++ type system.
You chose to force key management down the throat of your users, with two problems : - All the potential memory leaks, thread races, etc that may occur if your key management has subtle concurrency bugs. - Making your users think they can build *stuff* on top of this API, *stuff* that are explicitly out of scope of the pointer API as described by the design rationale of SQLite pointers API. Plus memory problems if your users think they can feed your API with arbitrary strings built at runtime. I think the problem, assuming there is one, is not in the SQLite API. Gwendal > Le 4 août 2017 à 08:36, Ulrich Telle <ulrich.te...@gmx.de> a écrit : > > Gwendal, > >> But... why don't you simply ask your users for a static string as well??? >> C++ makes it trivial to support this requirement of the C API. > > I could do that, of course. But it wouldn't solve the issue. It would push > the problem just one level up. > >> // pointerType should be a static string >> void wxSQLite3Statement::Bind(int paramIndex, void* pointer, char >> *pointerType, void(*DeletePointer)(void*)) > > That doesn't enforce a static string. The signature would have to be at least: > > void wxSQLite3Statement::Bind(int paramIndex, void* pointer, const char* > pointerType, void(*DeletePointer)(void*)) > > However, if not called with a string literal, it would still easily fail to > work. Simplified example: > > void* ptr = ...; > char* pType = malloc(10); > strcpy(pType, "carray"); > // ... > stmt.Bind(1, ptr, pType, NULL); > // ... > free(pType); > > Yes, I know, this is an artificial example. No one would implement it this > way in practice. It just demonstrates that even with a method signature > asking for a const char* it is not guaranteed to work. It would most probably > fail at runtime. > > Additionally, wxWidgets supports various implicit string conversions. So - > just as SQLite itself - my wrapper methods can't detect whether a static > string or string literal was passed or whether the compiler constructed a > temporary string object. And the compiler will not issue error messages, > often not even warnings. > > As mentioned in an earlier post, for my wrapper classes I decided to > implement the necessary housekeeping. Regarding the use of SQLite and my > wrapper classes I just quote a sentence which can be found in all SQLite > sources: > > "May you do good and not evil." > > Regards, > > Ulrich > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
