From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17997 invoked by alias); 26 Jan 2018 20:55:07 -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 17983 invoked by uid 89); 26 Jan 2018 20:55:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.189) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Jan 2018 20:55:04 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway32.websitewelcome.com (Postfix) with ESMTP id A2632B4BD9 for ; Fri, 26 Jan 2018 14:55:01 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id fB1ZePgd4ODN4fB1ZeLny3; Fri, 26 Jan 2018 14:55:01 -0600 Received: from 71-218-90-63.hlrn.qwest.net ([71.218.90.63]:52758 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1efB1Z-003lqH-C5; Fri, 26 Jan 2018 14:55:01 -0600 From: Tom Tromey To: Yao Qi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 4/7] Class-fy partial_die_info References: <1516873114-7449-1-git-send-email-yao.qi@linaro.org> <1516873114-7449-5-git-send-email-yao.qi@linaro.org> <87vafphpw6.fsf@tromey.com> <86lggkcz1x.fsf@gmail.com> Date: Fri, 26 Jan 2018 20:55:00 -0000 In-Reply-To: <86lggkcz1x.fsf@gmail.com> (Yao Qi's message of "Fri, 26 Jan 2018 17:25:30 +0000") Message-ID: <87d11wgx23.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1efB1Z-003lqH-C5 X-Source-Sender: 71-218-90-63.hlrn.qwest.net (pokyo) [71.218.90.63]:52758 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-01/txt/msg00567.txt.bz2 >> std::is_trivially_destructible to enforce the rule that objects on an >> obstack can't really be destroyed. This would eliminate the separate >> XOBNEW, which is maybe a potential source of errors; and would also make >> it harder to accidentally add a destructor to objects allocated this way Yao> but why dtor must be trivial? We can have "operator new" and "operator Yao> delete", the former allocate spaces on obstack and the latter doesn't Yao> de-allocate space. It doesn't matter dtor is trivial or not. I may Yao> miss something here. My thinking was that if something is allocated on an obstack, then presumably the destructor will never be run. So, it's best to avoid confusion by requiring a trivial destructor. I suppose it would be possible to track objects and destroy them, but if that's done, then it sort of eliminates the point of an obstack -- it would be just as convenient at that point to use the ordinary new. Yao> Further, I think IWBN to have a class which has new/delete operator, Yao> and other classes can inherit it. What do you think the patch below? I suppose this makes sense if you know that all objects of a given type must be allocated on an obstack. Tom