Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.

llvm-svn: 179779
This commit is contained in:
Greg Clayton
2013-04-18 18:10:51 +00:00
parent 56f976f6bd
commit e01e07b6e7
132 changed files with 330 additions and 332 deletions

View File

@@ -652,11 +652,11 @@ LLDBSWIGPython_CastPyObjectToSBValue
return sb_ptr;
}
// Currently, SBCommandReturnObjectReleaser wraps an std::auto_ptr to an
// Currently, SBCommandReturnObjectReleaser wraps a unique pointer to an
// lldb_private::CommandReturnObject. This means that the destructor for the
// SB object will deallocate its contained CommandReturnObject. Because that
// object is used as the real return object for Python-based commands, we want
// it to stay around. Thus, we release the auto_ptr before returning from
// it to stay around. Thus, we release the unique pointer before returning from
// LLDBSwigPythonCallCommand, and to guarantee that the release will occur no
// matter how we exit from the function, we have a releaser object whose
// destructor does the right thing for us