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@stripped>
