Follow-up to my own message.

I should have looked further in the first place. I see now what the
motivation behind the vector pointer and the del_vector flag was.

The constructors for NAME_cus_[value|field|equal]_list(...bool i1, bool
i2,...) uses this to store the value of the bool flags in the
vector<bool> which it creates dynamically.

The alternative, of course, would be to add an instance of vector<bool>,
not just a pointer, as member to NAME_cus_[value|field|equal]_list. The
downside of this is that it would force an implicit copy construction
(i.e. memory allocation) in the constructor [value|field|
equal]_list(..., vector<bool>,...), at the benefit of a 'safer'
interface signature. I can see the design tradeoff that the authors
must have faced.

A possible way out is to make all the data members of the
NAME_cus_[value|field|equal]_list classes static. At cursory glance,
these objects appear to be used only as return values and their primary
purpose appears to be consumption by operator<<, so that they act as
transient intermediaries in strictly sequential constructions, i.e.
they're singletons (only one instance exists at a time) which would
safely permit static members. But I'm not sure I'm not missing
something again here.

Thanks,

Wolfram


--
Wolfram Arnold <wolfram (AT) arnold (DOT) name>


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Thu, May 19, 2005 at 02:31:49AM -0700, Wolfram Arnold wrote:
What version are you using? There are bugs with the equal_list() feature
that Mark Merendino has already found and fixed. Have you patched your
copy of mysql++-1.7.35 with the patch I sent to the list on May 10?

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Wolfram Arnold wrote:
That breaks in the face of threads.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris,

Yes, that's it. I should have looked. Thanks for pointing it out, and
never mind.

I did fix an additional glitch, namely that the member accessors don't
check the index is valid for the vector provided, resulting in a
segfault if the vector is shorter than the number of elements in the
SSQL.

I'll submit when the next release comes out, I guess. I'm a bit wary of
releasing a patch that depends on a patch, with no intermediate check-in
to version control. (I read the post about hosting subversions
somewhere publicly visible--that would be great to have.) Suggestions?

Wolfram

On Thu, 2005-05-19 at 09:15 -0400, Chris Frey wrote:
Wolfram Arnold <wolfram (AT) arnold (DOT) name>


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Wolfram Arnold wrote:
There has been explicit support for building thread-aware versions of
MySQL++ for the past several releases. No audit has been made to ensure
that it is thread-safe in all situations, but if there are any they will
be considered bugs, not limitations.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Wolfram Arnold wrote:

I run a private repository here, so the complete history will still be
recorded. And when I decide on how to get this thing hosted, I hope to
replay the entire history into the public repository.

If you have a patch for a bug, by all means, let me have it.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw