From: Simon Marchi <simon.marchi@polymtl.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Pedro Alves <palves@redhat.com>,
brobecker@adacore.com, markus.t.metzger@intel.com,
gdb-patches@sourceware.org
Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr
Date: Tue, 11 Oct 2016 19:23:00 -0000 [thread overview]
Message-ID: <4aba16c0ae13533cd9e93f0f2823b042@simark.ca> (raw)
In-Reply-To: <831szmd977.fsf@gnu.org>
On 2016-10-11 14:36, Eli Zaretskii wrote:
>> First, it's not true that these C++ changes have not been planned.
>> They've been part of the plan ever since the very beginning. See
>> here, step 5 of the original version of the plan I originally
>> circulated in 2014:
>>
>> https://sourceware.org/gdb/wiki/cxx-conversion?action=recall&rev=1
>>
>> Current version is here:
>>
>> https://sourceware.org/gdb/wiki/cxx-conversion#Transition_plan
>>
>> Note the not-done-yet bullet points in step 8 (step 5 in rev 1).
>> That's exactly what's going on right now.
>
> Where does it say that we should require C++11? Or any specific
> version of the C++ standard, for that matter? AFAIR, this was never
> discussed.
I don't think anybody has seriously suggested requiring C++11 any time
soon, other than in a very hypothetical formulation. I can see why
there are some misunderstanding, especially for those who haven't
followed closely the C++ conversion. Let me try to state what I
understand from the situation.
C++03 has been around for long enough that we can safely migrate to that
(whereas it has value or not is another debate, although I think Pedro
showed clearly that it has), without leaving many users behind. C++11
comes with some nice features in its standard library, such as
std::unique_ptr. std::unique_ptr has some improvements over the old
std::auto_ptr, which was too easy to misuse. However, I think we all
agree that C++11 would be a too aggressive change, and will still be for
some time.
What Pedro chose to do is to create gdb::unique_ptr, our home-made
version of std::unique_ptr. When building with a C++03 compiler, the
hand-written version of the code is chosen and it works (see the #if
__cplusplus >= 201103). However, it's possible to misuse it, the same
way as it was possible to misuse std::auto_ptr (because of missing
features in C++03 vs C++11 IIUC). If you happen to build with a C++11
compiler, instead of choosing the hand-written version, gdb::unique_ptr
is more or less an alias for std::unique_ptr. So if there is a place in
the code that is misusing it, the build will fail and either buildbot or
another developer will let us know promptly.
So it's not that the code is built in a way which requires C++11, it's
built in a way that if you use C++11, you get the benefits of the newer
checking mechanisms, while still being able to build with a C++03
compiler. IMO it's the best of both worlds. Actually, it's the same
idea as gnulib, where we fill the gaps of the lacking platforms, rather
than choosing a low common denominator.
The warning analogy was perhaps not clearly expressed but I think it was
good. Let's say somebody with an old compiler wrote this code:
void foo()
{
int a;
global = a;
}
The old compiler doesn't have a warning to tell you that "a" is being
used without being initialized, so it accepts it. When another
developer, with a newer compiler, tries to build gdb, he/she gets an
error, and is able to report the bug. With unique_ptr, it's similar.
Somebody with an old compiler gets less compiler checking. The
difference is that we need to write a bit of code (this patch) to bridge
the gap, whereas with warnings it comes for free.
next prev parent reply other threads:[~2016-10-11 19:23 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 3/3] 'struct parse_expression *' -> gdb::unique_ptr<expression> 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
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 [this message]
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: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=4aba16c0ae13533cd9e93f0f2823b042@simark.ca \
--to=simon.marchi@polymtl.ca \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=palves@redhat.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