Re: [PATCH] New class allocate_on_obstack

[Yao Qi <qiyaoltc@gmail.com>]

On Wed, Feb 7, 2018 at 5:34 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On Wed, Feb 7, 2018 at 3:29 PM, Tom Tromey <tom@tromey.com> wrote:
>>>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:
>>
>> Yao> This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
>> Yao> inherit it, so that dwarf2_per_objfile is automatically allocated on
>> Yao> obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.
>>
>> I still think it should be restricted to types with a trivial
>> destructor.  Otherwise, someday, the lack of actual destruction is going
>> to cause a bug.
>>
>
> Can you give me some clues on how to do the restriction?  I think I need to
> use std::enable_if and std::is_trivially_destructible, but don't know how to put
> them into the code.
>

I somehow managed to write static_assert std::is_trivially_destructible<T>
for these classes, and dwarf2_per_objfile is not trivially destructible.
Classes inherit allocate_on_obstack don't have to be is_trivially_destructible,
IMO.

> Lack of destruction causes a bug in any case.  If object is allocated on heap,
> and don't do "delete p", the dtor isn't called and memory is leaked.  I
> expect use "delete p" no matter where the object is allocated (on heap or
> on obstack).

We can still let dwarf2_per_objfile inherit allocate_on_obstack or allocate
dwarf2_per_objfile on obstack, but is still better to use "delete" to call dtor.

-- 
Yao (齐尧)