> like sqlite3_malloc() or sqlite3_mprinft() to produce the string. OK, I won't be doing that.
> I guess NO So I will need to use SQLITE_TRANSIENT then? > You should know where the memory used to store the string in your own code comes from and how to deal with it. It will nearly always be a local variable, unless I can avoid this copy and use sqlite3_result_value directly as suggested by Igor. This would be better as it should speed matters up. Not tried this yet. RBS On Tue, Dec 15, 2015 at 9:33 AM, Hick Gunter <hick at scigames.at> wrote: > >Thanks for clarifying that. > > > >> If the pointer refers to memory obtained from sqlite3_malloc > >How do I know that is the case? > >My callback procedure (the procedure that does the actual work, altering > the string) is in a VB6 ActiveX dll, so not in sqlite3.dll > > If you called an sqlite3 API function that says it allocates memory, like > sqlite3_malloc() or sqlite3_mprinft() to produce the string. > > > > >> If the pointer refers to memory obtained from your own allocator > >I suppose this is the case if it is a local variable in this callback > procedure in my VB6 dll. > >In VB6 local variables will go out of scope (cleaned up) once the > procedure is finished. > >So in that case can I use SQLITE_STATIC? > > I guess NO. SQLite needs the value until at least up to the next call to > sqlite3_step(). Calling sqlite3_finalize() or sqlite3_reset() should also > "clear" the "current row". > > > > > >> In all other cases, pass SQLITE_TRANSIENT and, if necessary, dispose > >> of the memory appropriately. > >When is it necessary and what is appropriate? > > You should know where the memory used to store the string in your own code > comes from and how to deal with it. > > As you already stated, a local variable in your callback procedure goes > out of scope automatically. I have no idea how VB6 implements local > variables; in C they are located on the stack, which may be overwritten by > other function calls. > > > On Tue, Dec 15, 2015 at 7:52 AM, Hick Gunter <hick at scigames.at> wrote: > > >> The rules are quite simple: > >> > >> If the pointer refers to static memory (preallocated string constants, > >> global variables that you can guarantee won't change while SQLite uses > >> them) use SQLITE_STATIC > >> > >> If the pointer refers to memory obtained from sqlite3_malloc (directly > >> or indirectly e.g. via sqlite3_mprintf() ) and you won't refer to this > >> object again, pass sqlite3_free. > >> > >> If the pointer refers to memory obtained from your own allocator and > >> you won't refer to this object again, pass your own destructor. > >> > >> In all other cases, pass SQLITE_TRANSIENT and, if necessary, dispose > >> of the memory appropriately. > >> > >> SQLITE_TRANSIENT is safe but slow, because SQLite needs to copy the > string. > >> Passing a destructor function is faster but implies a contract to NOT > >> USE THE POINTER AGAIN yourself. > >> SQLITE_STATIC is fastest but implies a contract that the MEMORY WILL > >> NOT CHANGE. > >> > > > ___________________________________________ > Gunter Hick > Software Engineer > Scientific Games International GmbH > FN 157284 a, HG Wien > Klitschgasse 2-4, A-1130 Vienna, Austria > Tel: +43 1 80100 0 > E-Mail: hick at scigames.at > > This communication (including any attachments) is intended for the use of > the intended recipient(s) only and may contain information that is > confidential, privileged or legally protected. Any unauthorized use or > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please immediately notify the sender > by return e-mail message and delete all copies of the original > communication. Thank you for your cooperation. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
