On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor <mse...@gmail.com> wrote:
On 4/27/21 1:58 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
PR 90904 notes that auto_vec is unsafe to copy and assign because
the class manages its own memory but doesn't define (or delete)
either special function. Since I first ran into the problem,
auto_vec has grown a move ctor and move assignment from
a dynamically-allocated vec but still no copy ctor or copy
assignment operator.
The attached patch adds the two special functions to auto_vec along
with a few simple tests. It makes auto_vec safe to use in containers
that expect copyable and assignable element types and passes bootstrap
and regression testing on x86_64-linux.
The question is whether we want such uses to appear since those
can be quite inefficient? Thus the option is to delete those
operators?
I would strongly prefer the generic vector class to have the properties
expected of any other generic container: copyable and assignable. If
we also want another vector type with this restriction I suggest to add
another "noncopyable" type and make that property explicit in its name.
I can submit one in a followup patch if you think we need one.
I'm not sure (and not strictly against the copy and assign). Looking
around
I see that vec<> does not do deep copying. Making auto_vec<> do it
might be surprising (I added the move capability to match how vec<>
is used - as "reference" to a vector)
The vec base classes are special: they have no ctors at all (because
of their use in unions). That's something we might have to live with
but it's not a model to follow in ordinary containers.
I don't think we have to live with it anymore, now that we're writing C++11.
The auto_vec class was introduced to fill the need for a conventional
sequence container with a ctor and dtor. The missing copy ctor and
assignment operators were an oversight, not a deliberate feature.
This change fixes that oversight.
The revised patch also adds a copy ctor/assignment to the auto_vec
primary template (that's also missing it). In addition, it adds
a new class called auto_vec_ncopy that disables copying and
assignment as you prefer.
Hmm, adding another class doesn't really help with the confusion richi
mentions. And many uses of auto_vec will pass them as vec, which will
still do a shallow copy. I think it's probably better to disable the
copy special members for auto_vec until we fix vec<>.
Jason