From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87349 invoked by alias); 8 Feb 2018 20:58:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 87338 invoked by uid 89); 8 Feb 2018 20:58:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Lack X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 20:58:14 +0000 Received: by mail-qt0-f180.google.com with SMTP id s39so7986526qth.7 for ; Thu, 08 Feb 2018 12:58:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BS15FqJJFi2Bq96+cwJtiVG3bb0vP9o6ywnZUtdosYY=; b=MRcEvkuv1TTfpJvXZhW9nS663YNqV/k+yGn1WpJ/ym6wY/aAfBxQ5lc9Irlmn0gfEN QJn3ag7ybolEFIq6vZsRtW3EjgeKesCVv0QhAP93RNt8w/XSsLifOi2ZxvR6dgAFzTQh tM4H+HwVPLdGVCFegtbkxRbZqwYjhkbQI3WI8gQzhMUtLKrFqgd7O7QWVY81yyUgcbUM NwXsZ0MXYsRS+DJrlxtB3a4K7f10wixEiOikGH02aAsoXyW44uz2mZOAQKrGu3pF8ZO4 rrJhTAtm/XuKC1r5zSOVr+su+49JM4mBAMQxAKLeU7mm3uBcUcX7pT0vABx/v6+BehOD kxGQ== X-Gm-Message-State: APf1xPD+uYOxrTDvuK/0/B0Wqn8LaQ6OpZjJUtsTmEGlhqOL73wl9hBa 1iAM0yWmMXLYehgvEN9bn8irFoedkWe8dHM2Bi6YPg== X-Google-Smtp-Source: AH8x226OTzN4XbXoY9Nb48ZxsST5u37XZmcs9nIGPYl1/7ELR8LMH/xP+YqV3dTZ6PJqz3yiMK6ciSHubnHgBvKTulQ= X-Received: by 10.200.81.203 with SMTP id d11mr796034qtn.272.1518123492284; Thu, 08 Feb 2018 12:58:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.153.232 with HTTP; Thu, 8 Feb 2018 12:58:11 -0800 (PST) In-Reply-To: References: <1517996444-8605-1-git-send-email-yao.qi@linaro.org> <874lmsyg0f.fsf@tromey.com> From: Yao Qi Date: Thu, 08 Feb 2018 20:58:00 -0000 Message-ID: Subject: Re: [PATCH] New class allocate_on_obstack To: Tom Tromey Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00140.txt.bz2 On Wed, Feb 7, 2018 at 5:34 PM, Yao Qi wrote: > On Wed, Feb 7, 2018 at 3:29 PM, Tom Tromey wrote: >>>>>>> "Yao" =3D=3D Yao Qi 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 sp= ace. >> >> 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 for these classes, and dwarf2_per_objfile is not trivially destructible. Classes inherit allocate_on_obstack don't have to be is_trivially_destructi= ble, 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. --=20 Yao (=E9=BD=90=E5=B0=A7)