On Tuesday, 11 July 2017 at 22:46:00 UTC, Steven Schveighoffer
wrote:
On 7/5/17 12:04 PM, crimaniak wrote:
...
Because of the temporary copy likely inside map closes the
connection.
See the bug I reported:
https://github.com/mysql-d/mysql-native/issues/117
Yes, it seems to be the same issue. (BTW, then I tried filter()
just for curiosity and have the same problem).
I work around this in my code by moving the temporary copy. But
I'm sorry to say you likely will not be able to fix map.
I have WEB application (no big recordsets to transfer), so, for
now, I "fix" it inside of my sql wrapper: just load recordset to
an array and give it instead of ResultRange. I don't like it, but
it works and all shit is localized in one place.
I think Nick's comment is interesting, "Seems that using struct
dtors without refcounting should in general be regarded as a
code smell?"
It's a good question. I've also always added ref counting when
wanting to "auto close" a struct's resources. In fact, I can't
really think of a good use of destructors for structs that
isn't for reference counting itself.
I don't think so. There is architecture problem: non-copyable by
nature resource represented by copyable struct. We need
non-copyable class/object semantics here or have to emulate it if
using the struct to have the correct behavior. It's fully o.k. to
get some resources required by _this exact copy_ of struct in the
constructor and then release it in the destructor. For example of
good use of destructors: position in some game, requires
non-fixed space to store itself. We want to make copies of
positions, apply some movies to them and then make copies again
to search in positions tree. Copy constructor will malloc some
space and copy source position data, the destructor will free
this space, and we don't need reference counting here.
