From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 9DB673858005 for ; Mon, 25 Oct 2021 21:24:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DB673858005 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 19PLNPZc026397 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Oct 2021 17:23:30 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 19PLNPZc026397 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 912251ECEB; Mon, 25 Oct 2021 17:23:25 -0400 (EDT) Message-ID: Date: Mon, 25 Oct 2021 17:23:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH v3 04/28] Add to_location method to DWARF entry classes Content-Language: en-US To: Lancelot SIX , Zoran Zaric Cc: gdb-patches@sourceware.org References: <20211014093235.69756-1-zoran.zaric@amd.com> <20211014093235.69756-5-zoran.zaric@amd.com> <20211022212054.jzoa2vhrdq4pl2yi@ubuntu.lan> From: Simon Marchi In-Reply-To: <20211022212054.jzoa2vhrdq4pl2yi@ubuntu.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 25 Oct 2021 21:23:25 +0000 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:24:36 -0000 > I would be tempted to use the implementation from the standard library > when available (i.e. if compiling in c++14 and later). Something like > that should do it: > > #if __cplusplus >= 201402L > #include > > using std::make_unique; > #else > /* template<...> std::unique_ptr make_unique(...){} */ > #endif > > This is quite similar to what is done in gdbsupport/gdb_string_view.h. > > And to follow what is done in the string_view example, make_unique could > probably be declared in the gdb namespace. I guess this suggestion > would mainly make sense if this code is moved to gdbsupport (as > suggested in the comment). > > One possible limitation of placing this in gdbsupport is that this > implementation does not handle the 'template std::unique_ptr > std::make_unique (std::size_t size)' case used to create arrays. > It would be easy to borrow it from libstdc++ as well if we wanted to > have a fully compliant make_unique implementation. > > Maybe a maintainer has an opinion on the whether this should be moved to > gdbsupport? I think it would be good to have a gdb::make_unique in gdbsupport, as you described (that uses the one from the standard library if __cplusplus >= 201402L). There are surely other spots that could benefit from it. Simon