OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
binutils-gdb/gdb/common/gdb_unique_ptr.h

46 lines
1.3 KiB
C
Raw Normal View History

Delete gdb::unique_ptr/gdb::move Now that we require C++11 and all uses of gdb::unique_ptr and gdb::move are gone, let's remove their definitions... With my lazy hat on, I repurposed the header for "generally useful unique_ptr specializations", and left gdb::unique_xmalloc_ptr in there. Not sure whether we it'd be better move it out of the gdb namespace or leave it be. I left it because it's less work and avoids disrupting yet-unmerged patches that use it. gdb/ChangeLog: 2016-11-15 Pedro Alves <palves@redhat.com> * common/common-defs.h: Update comment. * common/gdb_unique_ptr.h: Update header comment and copyright year. (gdb::unique_ptr, gdb::move): Delete.
2016-11-15 20:54:21 +01:00
/* std::unique_ptr specializations for GDB.
Introduce gdb::unique_ptr 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 to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - 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: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
2016-10-18 12:42:35 +02:00
update copyright year range in GDB files This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2017-01-01 07:50:51 +01:00
Copyright (C) 2016-2017 Free Software Foundation, Inc.
Introduce gdb::unique_ptr 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 to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - 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: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
2016-10-18 12:42:35 +02:00
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#ifndef GDB_UNIQUE_PTR_H
#define GDB_UNIQUE_PTR_H 1
#include <memory>
namespace gdb
{
Delete gdb::unique_ptr/gdb::move Now that we require C++11 and all uses of gdb::unique_ptr and gdb::move are gone, let's remove their definitions... With my lazy hat on, I repurposed the header for "generally useful unique_ptr specializations", and left gdb::unique_xmalloc_ptr in there. Not sure whether we it'd be better move it out of the gdb namespace or leave it be. I left it because it's less work and avoids disrupting yet-unmerged patches that use it. gdb/ChangeLog: 2016-11-15 Pedro Alves <palves@redhat.com> * common/common-defs.h: Update comment. * common/gdb_unique_ptr.h: Update header comment and copyright year. (gdb::unique_ptr, gdb::move): Delete.
2016-11-15 20:54:21 +01:00
/* Define gdb::unique_xmalloc_ptr, a std::unique_ptr that manages
Introduce gdb::unique_ptr 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 to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - 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: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
2016-10-18 12:42:35 +02:00
xmalloc'ed memory. */
Delete gdb::unique_ptr/gdb::move Now that we require C++11 and all uses of gdb::unique_ptr and gdb::move are gone, let's remove their definitions... With my lazy hat on, I repurposed the header for "generally useful unique_ptr specializations", and left gdb::unique_xmalloc_ptr in there. Not sure whether we it'd be better move it out of the gdb namespace or leave it be. I left it because it's less work and avoids disrupting yet-unmerged patches that use it. gdb/ChangeLog: 2016-11-15 Pedro Alves <palves@redhat.com> * common/common-defs.h: Update comment. * common/gdb_unique_ptr.h: Update header comment and copyright year. (gdb::unique_ptr, gdb::move): Delete.
2016-11-15 20:54:21 +01:00
/* The deleter for std::unique_xmalloc_ptr. Uses xfree. */
Introduce gdb::unique_ptr 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 to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - 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: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
2016-10-18 12:42:35 +02:00
template <typename T>
struct xfree_deleter
{
void operator() (T *ptr) const { xfree (ptr); }
};
Delete gdb::unique_ptr/gdb::move Now that we require C++11 and all uses of gdb::unique_ptr and gdb::move are gone, let's remove their definitions... With my lazy hat on, I repurposed the header for "generally useful unique_ptr specializations", and left gdb::unique_xmalloc_ptr in there. Not sure whether we it'd be better move it out of the gdb namespace or leave it be. I left it because it's less work and avoids disrupting yet-unmerged patches that use it. gdb/ChangeLog: 2016-11-15 Pedro Alves <palves@redhat.com> * common/common-defs.h: Update comment. * common/gdb_unique_ptr.h: Update header comment and copyright year. (gdb::unique_ptr, gdb::move): Delete.
2016-11-15 20:54:21 +01:00
/* Import the standard unique_ptr to our namespace with a custom
deleter. */
Introduce gdb::unique_ptr 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 to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - 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: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
2016-10-18 12:42:35 +02:00
template<typename T> using unique_xmalloc_ptr
= std::unique_ptr<T, xfree_deleter<T>>;
} /* namespace gdb */
#endif /* GDB_UNIQUE_PTR_H */