[v4] Introduce gdb::unique_ptr

From: Pedro Alves <palves@redhat.com>

  On 10/16/2016 08:13 AM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> For managing malloc pointers, this adds a gdb::unique_malloc_ptr<T>
> Pedro> "specialization" with a custom xfree deleter.
> 
> I found something surprising while using this patch: it can't be used in
> a .y file, due to the malloc->xmalloc renaming done in the .y.c rule.
> I puzzled over the error about "unique_xmalloc_ptr" for a while until I
> remembered this.

Oh, I saw that too, when I tried to use it to manage the result of
ui_file_xstrdup in c-exp.y, I think, but then added added ui_file_as_string
instead, and then I completely forgot about that!  FWIW, I also puzzled
over the error for a while...

> One option would be to fix up that renaming, maybe something like:
> 
> -	     -e 's/\([^x]\)malloc/\1xmalloc/g' \
> -	     -e 's/\([^x_]\)malloc/\1xmalloc/g' \
> 
> Another would be to rename the class unique_xmalloc_ptr after all.

Guess renaming makes sense anyway.  I renamed it, and forced-pushed this
along with the rest of the series (meanwhile split into smaller pieces
and a few more patches added; it's now at 32 patches...) to the
users/palves/cxx-eliminate-cleanups branch.

While splitting up the series, I noticed that it'd be nice to 
support implicit construction from NULL, since that works in C++11,
so I tweaked the patch accordingly.  The problem was that the
not-a-type-based nullptr emulation wouldn't trigger because it
would require two conversions, because I had used a separate class...
Inlining that in auto_ptr_base makes things work, and, ends up
looking simpler even...

So here's v4.  WDTY?

From f35cf129b55e331c1edd3dfd4bf633a9bd649418 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Mon, 17 Oct 2016 14:11:23 +0100
Subject: [PATCH] Introduce gdb::unique_ptr

New in v4:

  - implict construction from NULL allowed too now, for:

     gdb::unique_ptr<foo> func (....)
     {
        return NULL;
     }

  - Rename unique_malloc_ptr to unique_xmalloc_ptr.

New in v3:

  - Comment typos fixed.  Detail things moved to detail namespace.

New in v2:

  - considering a move to C++11, it no longer makes much sense to add
    a base class just for the one instance of the safe bool idiom.
    That's now inlined into unique_ptr directly.

  - added missing </<=/>/>= comparison operators.

  - simplified the implementation even further, by removing the "ref"
    class, and adding converting contructors instead.  This actually
    fixes this use case:

      unique_ptr<Derived> func_returning_unique_ptr (.....);
      ...
      unique_ptr<Base> ptr = func_returning_unique_ptr (.....);

    Looks like GCC's std::auto_ptr is buggy in that respect, because
    that doesn't actually work with std::auto_ptr, despite the
    comments indicating otherwise, and I was copying the comment/bug.

  - comments updated/rewritten throughout, including the git commit
    log, to hopefully clarify things.

  I think that the code looks clearer and less "magic" now.

I'd like to get this in soon to unblock Tromey's C++ series, and more.
We can move along with the C++11 discussion / plan in parallel.

Any objections?

I'll be more than happy to remove this when we finally make C++11 a
requirement.  But I don't want to rush that.  We should make sure that
the buildbot's buildslaves are ready, for example.

~~~

Many make_cleanup uses in the code base are best eliminated by using a
"owning" smart pointer to manage ownership of the resource
automatically.

The question is _which_ smart pointer.

GDB currently supports building with a C++03 compiler.  We have
std::auto_ptr in C++03, but, as is collective wisdom by now, that's
too easy to misuse, and has therefore been deprecated in C++11 and
finally removed in C++17.

It'd be nice to be able to use std::unique_ptr instead, which is the
modern, safe std::auto_ptr replacement in C++11.

In addition to extra safety -- moving (i.e., transfer of ownership of
the managed pointer between smart pointers) must be explicit --
std::unique_ptr has (among others) one nice feature that std::auto_ptr
doesn't --- ability to specify a custom deleter as template parameter.
In gdb's context, that allows easily creating a smart pointer for
memory allocated with xmalloc -- the smart pointer then knows to
release with xfree instead of delete.  This is particularly
interesting when managing objects allocated in C libraries, and also,
for C++-fying parts of GDB that interact with other parts that still
return objects allocated with xmalloc.

Since std::unique_ptr's API is quite nice, and eventually we'd like to
move to C++11, this patch adds a C++03-compatible smart pointer that
exposes the subset of the std::unique_ptr API that we're interested
in.  An advantage is that whenever we start requiring C++11, we won't
have to learn a new API.  Meanwhile, this allows continuing to support
building with a C++03 compiler.

Since C++03 doesn't support rvalue references (boost gets close to
emulating them, but it's not fully transparent to user code), the
C++03 std::unique_ptr emulation here doesn't try hard to prevent
accidentally moving, which is where most of complication of a more
thorough emulation would be.  Instead, we rely on the fact that GDB
will be usually compiled with a C++11 compiler, and use the real
std::unique_ptr in that case to catch such accidental moves.  IOW, the
goal here is to allow code that would be correct using std::unique_ptr
to be equally correct in C++03 mode, and, just as efficient.

The C++03 version was originally based on GCC 7.0's std::auto_ptr and
then heavily customized to behave more like C++11's std::unique_ptr:

   - Support for custom (stateless) deleters.  (Support for stateful
     deleters could be added, if necessary.)

   - unique_ptr<T[]> partial specialization (auto_ptr<T> does not know
     to use delete[]).

   - Support for all of 'ptr != NULL', 'ptr == NULL' and 'if (ptr)'
     using the safe bool idiom.

   - Assignment from NULL.

   - Allow using all of 'ptr != NULL', 'ptr == NULL' and 'if (ptr)'
     using the safe bool idiom to emulate C++11's explicit bool
     conversion.

   - Variable names un-uglified (ie., no leading __ prefix everywhere).

   - Formatting made to follow GDB's coding conventions, including
     comment style.

   - Initialization and assignment from NULL (std::unique_ptr allows
    "ptr = nullptr" instead, while std::auto_ptr allows neither.)

   - Converting "move" constructors done differently in order to truly
     support:

      unique_ptr<Derived> func_returning_unique_ptr (.....);
      ...
      unique_ptr<Base> ptr = func_returning_unique_ptr (.....);

At this point, it no longer shares much at all with the original file,
but, that's the history.

See comments in the code to find out more.

I thought of putting the "emulation" / shim in the "std" namespace, so
that when we start requiring C++11 at some point, no actual changes to
users of the smart pointer throughout would be necessary.  Putting
things in the std namespace is technically undefined, however in
practice it doesn't cause any issue with any compiler.  However,
thinking that people might be confused with seeing std::unique_ptr and
thinking that we're actually requiring C++11 already, I put the new
types in the "gdb" namespace instead.

For managing xmalloc pointers, this adds a gdb::unique_xmalloc_ptr<T>
"specialization" with a custom xfree deleter.

No actual use of any smart pointer is introduced in this patch.
That'll be done in following patches.

Tested (along with the rest of the series) on:

 - NetBSD 5.1 (gcc70 on the compile farm), w/ gcc 4.1.3
 - x86-64 Fedora 23, gcc 5.3.1 (gnu++03)
 - x86-64 Fedora 23, and gcc 7.0 (gnu++14)

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <palves@redhat.com>

	* common/common-defs.h: Include "gdb_unique_ptr.h".
	* common/gdb_unique_ptr.h: New.
---
 gdb/common/common-defs.h    |   3 +
 gdb/common/gdb_unique_ptr.h | 360 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 363 insertions(+)
 create mode 100644 gdb/common/gdb_unique_ptr.h

[v4] Introduce gdb::unique_ptr

Commit Message

Comments

Patch