Hi Vadim,
I agree we should make it legal usage if it isn't already.
Regarding realloc() instead of delete / new, I don't care much either way.
If we wanted to make a change for performance reasons, it would be good to
have some way (benchmarks or what not) to demonstrate that performance is
really affected by such change and in the direction we expect.
Thanks,
Aleksander
On Wed, Feb 25, 2015 at 4:43 PM, Vadim Zeitlin <[email protected]> wrote:
> Hello,
>
> I'd just like to check if I'm not missing something obvious here: I
> thought it was perfectly fine to execute the same statement more than once
> with different parameter values, e.g. do something like this:
>
> int f;
> statement st = (sql.prepare << "insert into t(f) values(:f)",
> use(f));
> for (f = 0; f < 10; f++)
> st.execute(true);
>
> And, in fact, this does work fine in the sense that the expected values are
> inserted in the database.
>
> However currently if any values requiring memory allocation are used, e.g.
> strings, but also dates and even long longs in some backends, there are
> also plenty of memory leaks, at least in the ODBC backend where I
> definitely see them, but also, apparently, in some of the other ones from
> examining the code. They happen because the code in
> whatever_use_type_backend::pre_use() happily overwrites buf_ with the
> new allocation without freeing the old one, and if execute(true) is called
> more than once, pre_use() is also called more than once.
>
> So the first question is whether this is really allowed or is this a
> misuse of the SOCI API. I hope it it legal and then the memory leaks need
> to be fixed. AFAICS there are 2 ways of doing it: either do as MySQL,
> PostgreSQL and SQLite backends do and just call clean_up() in post_use(),
> or be a bit smarter and reallocate the buffer if it's already allocated
> instead of always allocating the new one. This would, of course, mean
> switching to realloc() from new[] currently being used, but could be
> noticeably more efficient when a lot of execute() calls are done in a loop.
>
> What do you think?
> VZ
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
