public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Richard Biener <rguenther@suse.de>,
	gcc-patches@gcc.gnu.org,  Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz
Date: Wed, 8 Mar 2023 00:51:59 +0300 (MSK)	[thread overview]
Message-ID: <bcb84d2b-e045-f2ba-723a-834ee072b2f4@ispras.ru> (raw)
In-Reply-To: <CACb0b4k3W9k1GoXs+EjmeQgFi9QiL2kgLBWhwaromkCUv34hsw@mail.gmail.com>


On Tue, 7 Mar 2023, Jonathan Wakely wrote:

> > Shouldn't this use the idiom suggested in ansidecl.h, i.e.
> >
> >   private:
> >     DISABLE_COPY_AND_ASSIGN (auto_mpfr);
> 
> 
> Why? A macro like that (or a base class like boost::noncopyable) has
> some value in a code base that wants to work for both C++03 and C++11
> (or later). But in GCC we know we have C++11 now, so we can just
> delete members. I don't see what the macro adds.

Evidently it's possible to forget to delete one of the members, as
showcased in this very thread.

The idiom is also slightly easier to read.

Alexander

  reply	other threads:[~2023-03-07 21:52 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 10:11 Richard Biener
2023-03-06 10:44 ` Jonathan Wakely
2023-03-06 11:01   ` Richard Biener
2023-03-06 11:03     ` Jonathan Wakely
2023-03-06 11:10     ` Jakub Jelinek
2023-03-06 11:29       ` Richard Biener
2023-03-07 18:51         ` Bernhard Reutner-Fischer
2023-03-07 19:03           ` Jakub Jelinek
2023-04-02 15:05         ` [PATCH 0/3] Fix mpfr and mpz memory leaks Bernhard Reutner-Fischer
2023-04-02 15:05         ` [PATCH 1/3] go: Fix memory leak in Integer_expression Bernhard Reutner-Fischer
2023-04-02 15:05         ` [PATCH 2/3] rust: Fix memory leak in compile_{integer,float}_literal Bernhard Reutner-Fischer
2023-04-02 15:05         ` [PATCH 3/3] Fortran: Fix mpz and mpfr memory leaks Bernhard Reutner-Fischer
2023-04-03 19:50           ` Harald Anlauf
2023-04-03 19:50             ` Harald Anlauf
2023-04-03 21:42             ` Bernhard Reutner-Fischer
2023-04-17 19:47               ` ping " Bernhard Reutner-Fischer
2023-04-17 22:18                 ` Steve Kargl
2023-05-08  6:00                   ` Bernhard Reutner-Fischer
2023-03-07 19:15     ` [PATCH] [RFC] RAII auto_mpfr and autp_mpz Alexander Monakov
2023-03-07 21:35       ` Jonathan Wakely
2023-03-07 21:51         ` Alexander Monakov [this message]
2023-03-07 21:54           ` Jonathan Wakely
2023-03-07 21:59             ` Marek Polacek
2023-03-08  7:25           ` Richard Biener
2023-03-08 10:13             ` Jonathan Wakely
2023-03-08 10:33               ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcb84d2b-e045-f2ba-723a-834ee072b2f4@ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jwakely@redhat.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).