From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>,
"Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: brobecker@adacore.com, gdb-patches@sourceware.org,
jan.kratochvil@redhat.com, simon.marchi@ericsson.com
Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr
Date: Wed, 12 Oct 2016 10:12:00 -0000 [thread overview]
Message-ID: <444c7c47-f23b-bb95-aa36-dbb1544142f3@redhat.com> (raw)
In-Reply-To: <83insxc3rv.fsf@gnu.org>
On 10/12/2016 10:31 AM, Eli Zaretskii wrote:
>> From: "Metzger, Markus T" <markus.t.metzger@intel.com>
>> CC: "brobecker@adacore.com" <brobecker@adacore.com>,
>> "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, "Jan Kratochvil
>> (jan.kratochvil@redhat.com)" <jan.kratochvil@redhat.com>, Simon Marchi
>> <simon.marchi@ericsson.com>
>> Date: Wed, 12 Oct 2016 08:11:44 +0000
>>
>> I think we got hung up on the perceived requirement of having to build
>> your own GCC. The discussion got a bit too abstract and mentioning GCC 6
>> as the first to default to C++11 may have been confusing in the heat of the
>> discussion as "GCC 6 defaults to C++11" may have been misread as "C++11
>> requires GCC 6".
>
> I don't think that's what happened. In my interpretation, there are
> simply several issues intertwined in this discussion (which probably
> adds to confusion):
>
> . Should we start using C++11 features in GDB?
I would hope that no one would suggest that we shouldn't use
C++11 features just because they like C++03 better than C++11.
That would make no sense.
In my mind, the only reason you'd not use C++11 over C++03
is simply because you couldn't because you don't have a
compiler that supports it. IMO, at this point, the number
of systems that don't have a C++11 compiler handy AND where
you'd absolutely need to build a new GDB is sufficiently small that
the desire to use C++11 features overwhelms the inconvenience
of having to build a new compiler first, on those specific cases.
Many of the larger projects around the free software community
require C++11 nowadays. It's quite likely that even on older
systems you'll have arranged to set up a newer compiler that
supports C++11, because it is dependency on the programs that
you'll likely want to debug with gdb.
Alternatives to GDB, like lldb, already require a C++11
compiler anyway, so C++11 alone won't be a reason that
would cause people to try alternatives on those systems.
But even if we don't _require_ C++11, IMO, yes, we should
still use select C++11 features when available, in implementation
details of gdb's general utilities, when they add extra safety or
efficiency that is simply not possible in C++03.
TBC, I would reject patches that added:
#if cxx11
...
#else
...
#endif
sprinkled around the codebase in non-utility code.
> . Should we document these decisions and also decide to abide by
> them for some reasonably long stretch of time?
Sure, we should document the decisions. But I see no point in locking
ourselves to past decisions on a timed basis. Past decisions should
be reevaluated simply when they longer make sense. I.e.,
apply past reasoning to current reality and see if the same answer
comes out.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-10-12 10:12 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 16:46 [PATCH 0/3] More cleanup elimination / gdb::unique_ptr Pedro Alves
2016-10-10 16:46 ` [PATCH 1/3] Introduce gdb::unique_ptr Pedro Alves
2016-10-10 17:49 ` Simon Marchi
2016-10-10 18:03 ` Pedro Alves
2016-10-11 6:48 ` Metzger, Markus T
2016-10-11 10:23 ` Pedro Alves
2016-10-11 10:53 ` Andreas Schwab
2016-10-11 11:17 ` Metzger, Markus T
2016-10-11 11:43 ` Pedro Alves
2016-10-11 13:58 ` Yao Qi
2016-10-11 14:05 ` Trevor Saunders
2016-10-11 12:16 ` Joel Brobecker
2016-10-11 13:46 ` Pedro Alves
2016-10-11 14:47 ` Joel Brobecker
2016-10-11 15:17 ` Eli Zaretskii
2016-10-11 16:24 ` Pedro Alves
2016-10-11 16:58 ` Eli Zaretskii
2016-10-11 17:41 ` Pedro Alves
2016-10-11 18:37 ` Eli Zaretskii
2016-10-11 19:19 ` Pedro Alves
2016-10-11 20:47 ` Eli Zaretskii
2016-10-11 21:32 ` Pedro Alves
2016-10-12 6:34 ` Eli Zaretskii
2016-10-12 8:11 ` Metzger, Markus T
2016-10-12 9:31 ` Eli Zaretskii
2016-10-12 10:12 ` Pedro Alves [this message]
2016-10-12 11:05 ` Eli Zaretskii
2016-10-12 11:25 ` Pedro Alves
2016-10-12 11:45 ` Eli Zaretskii
2016-10-13 12:12 ` Pedro Alves
2016-10-12 10:28 ` Pedro Alves
2016-10-12 11:07 ` Eli Zaretskii
2016-10-12 11:19 ` Pedro Alves
2016-10-12 11:41 ` Eli Zaretskii
2016-10-12 11:55 ` Pedro Alves
2016-10-13 0:38 ` [PATCH] Enable C++11 starting with gcc 4.8 (was: Re: [PATCH 1/3] Introduce gdb::unique_ptr) Pedro Alves
2016-10-13 0:45 ` [PATCH 2/2] gdb: Enable C++11 if available Pedro Alves
2016-10-13 0:45 ` [PATCH 1/2] gdb: Import AX_CXX_COMPILE_STDCXX from the GNU Autoconf Archive Pedro Alves
2016-10-12 9:37 ` [PATCH 1/3] Introduce gdb::unique_ptr Pedro Alves
2016-10-12 10:51 ` Eli Zaretskii
2016-10-12 11:15 ` Pedro Alves
2016-10-12 11:40 ` Eli Zaretskii
2016-10-12 11:45 ` Jan Kratochvil
2016-10-12 11:56 ` Luis Machado
2016-10-12 12:03 ` Eli Zaretskii
2016-10-13 9:07 ` Jan Kratochvil
2016-10-13 10:07 ` Eli Zaretskii
2016-10-13 10:27 ` Pedro Alves
2016-10-13 13:22 ` Eli Zaretskii
2016-10-13 13:36 ` Pedro Alves
2016-10-13 13:59 ` Eli Zaretskii
2016-10-13 14:04 ` Pedro Alves
2016-10-13 15:06 ` Joel Brobecker
2016-10-13 10:46 ` Jan Kratochvil
2016-10-13 11:15 ` Pedro Alves
2016-10-13 13:28 ` Eli Zaretskii
2016-10-13 13:42 ` Pedro Alves
2016-10-13 14:07 ` Eli Zaretskii
2016-10-11 19:23 ` Simon Marchi
2016-10-11 20:54 ` Eli Zaretskii
2016-10-11 21:28 ` Simon Marchi
2016-10-12 6:23 ` Eli Zaretskii
2016-10-11 21:16 ` Jan Kratochvil
2016-10-11 17:15 ` Luis Machado
2016-10-11 18:21 ` Pedro Alves
2016-10-10 16:46 ` [PATCH 3/3] 'struct parse_expression *' -> gdb::unique_ptr<expression> Pedro Alves
2016-10-10 16:58 ` [PATCH 0/3] More cleanup elimination / gdb::unique_ptr Pedro Alves
2016-10-16 7:05 ` Tom Tromey
2016-10-17 13:57 ` Pedro Alves
2016-10-17 14:07 ` Tom Tromey
2016-10-17 14:59 ` Pedro Alves
2016-10-20 13:46 ` 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=444c7c47-f23b-bb95-aa36-dbb1544142f3@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=markus.t.metzger@intel.com \
--cc=simon.marchi@ericsson.com \
/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