On Wed, 2019-12-18 at 10:59 -0500, David Malcolm wrote: > On Wed, 2019-12-04 at 09:29 -0700, Martin Sebor wrote: > > On 11/15/19 6:22 PM, David Malcolm wrote: > > > This patch adds a class auto_delete_vec<T>, a subclass of auto_vec > > > <T *> > > > that deletes all of its elements on destruction; it's used in many > > > places later in the kit. > > > > > > This is a crude way for a vec to "own" the objects it points to > > > and clean up automatically (essentially a workaround for not being > > > able > > > to use unique_ptr, due to C++98). > > > > > > gcc/ChangeLog: > > > * vec.c (class selftest::count_dtor): New class. > > > (selftest::test_auto_delete_vec): New test. > > > (selftest::vec_c_tests): Call it. > > > * vec.h (class auto_delete_vec): New class template. > > > (auto_delete_vec<T>::~auto_delete_vec): New dtor. > > > > Because of slicing, unless preventing the elements from being > > deleted in the class dtor is meant to be a feature, it seems that > > using a wrapper class rather than public derivation from auto_vec > > might be a safer solution. > > > > It might be worth mentioning in a comment that the class isn't > > safe to copy or assign (each copy would wind up delete the same > > pointers), in addition to making its copy ctor and copy assignment > > operator inaccessible or deleted. > > > > Martin > > In the version of the patch in the v4 kit: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01035.html > I added: > private: > DISABLE_COPY_AND_ASSIGN(auto_delete_vec<T>); > to the class. > > Does that satisfy your concerns about slicing? (and, indeed, about > copying and assigning) I think this can and should go forward at this point.
jeff
