This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] New class allocate_on_obstack
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>
- Date: Thu, 8 Feb 2018 20:58:11 +0000
- Subject: Re: [PATCH] New class allocate_on_obstack
- Authentication-results: sourceware.org; auth=none
- References: <1517996444-8605-1-git-send-email-yao.qi@linaro.org> <874lmsyg0f.fsf@tromey.com> <CAH=s-PPtTkeUhKDmF_dY+x33KYs0fP9HP+58apEdKq+eQyGwvw@mail.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 (齐尧)