public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Subject: Re: [RFC] [gdb/build] Require c++17 compiler
Date: Thu, 12 Oct 2023 18:10:57 +0100	[thread overview]
Message-ID: <ae07a953-38c3-497f-b9c2-91d7309f8349@palves.net> (raw)
In-Reply-To: <20231005065449.32643-1-tdevries@suse.de>

On 2023-10-05 07:54, Tom de Vries via Gdb-patches wrote:
> Since gdb 8.0, we've required a c++11 compiler.
> 
> That allowed gdb to be compiled with gcc releases as far back as gcc 4.8,
> using an explicit -std=c++11 to override the default.
> 
> [ Gcc has the following defaults:
> - before gcc 6: c++98, and
> - for gcc 6-10: c++14, and
> - since gcc 11: c++17. ]
> 

Just a comment here:

> There are two arguments in favor of moving to requiring a newer c++ standard:
> - benefits can be had from using newer c++ features.  We're already using some
>   of those features using gdb-specific implementations.

...

> - when developing gdb on modern platforms with system compiler gcc >= 6,
>   people can accidentally use c++14/c++17 features in a patch, only to find out
>   post-commit that it breaks the build on a system with a compiler that only
>   supports c++11, which is inconvenient and takes time to fix.
>   [ This could be partially mitigated by if possible also forcing -std=c++11
>   for such compilers. ]

Whether to force -std=c++11 to avoid this had been discussed back in the C++11
transition as well, and we decided against back then.  The benefit of being able to
conditionally use newer C++ features, which may e.g., be a lot more efficient,
or the making sure our replacements don't deviate from actual standard components
(by actually using them when possible), outweighs the rare breakage concern, IMHO.


  parent reply	other threads:[~2023-10-12 17:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05  6:54 Tom de Vries
2023-10-05 10:33 ` [PATCH RFC] " Lancelot SIX
2023-10-05 12:26   ` Andrew Burgess
2023-10-05 14:26     ` Lancelot SIX
2023-10-05 14:32       ` Simon Marchi
2023-10-05 14:55         ` Lancelot SIX
2023-10-09 14:32           ` Andrew Burgess
2023-10-05 15:55         ` Tom Tromey
2023-10-12 17:30   ` Pedro Alves
2023-10-05 15:31 ` [RFC] [gdb/build] " Tom Tromey
2023-10-10 17:39   ` Tom Tromey
2023-10-10 19:16     ` Simon Marchi
2023-10-12 17:10 ` Pedro Alves [this message]
2023-10-12 17:22 ` Pedro Alves

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=ae07a953-38c3-497f-b9c2-91d7309f8349@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@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).