I'm using ComPtr (Microsoft::WRL) to manage some DirectX11 resources.
How can I manually release it?
The "ReleaseAndGetAddressOf" method if I understand correctly, only frees the pointer and not the resource itself (which is returned), and I'm not sure about the "Reset" method.
The only alternatives I could think of are manually calling the pointer destructor, or after obtaining the raw pointer from "ReleaseAndGetAddressOf" calling "Release" on that, which I would like to avoid.
The source code for WRL is provided, have a look at include/winrt/wrl/client.h. The embedded COM pointer (ptr_ member) is released by the InternalRelease() function. Making any of the following a way to release the pointer suitable candidates:
the destructor. The reason to use ComPtr<>
assigning nullptr
using ReleaseAndGetAddressOf(), the long way around
calling Reset()
So assigning nullptr or calling Reset() are a good fit, take your pick. Or don't use it at all if you just want to manage the interface pointer yourself, it certainly isn't required to use ComPtr.
You can assign a null pointer.
Related
I'm using a smart pointer or a ComPtr. I'm using it with my directX application and I haven't seen other people call the release function in their code using the ComPtr. So does the smart pointer release the data that the smart pointer is referring to or do I need to do it manually? I don't know if this makes since so tell me if it doesn't and I will respond with better detail.
You should never call AddRef or Release on a ComPtr, and by default you can't. You have to use hacky patterns like comPtr.Get()->Release to do it, and you are mostly like going to cause problems.
The purpose of Microsoft::WRL::ComPtr is to make COM pointer cleanup automatic, both in normal code and when handling C++ exceptions. Making a copy of a ComPtr to another ComPtr automatically increase the ref-count, and each time a ComPtr variable goes out of scope it automatically decreases the ref-count. This greatly simplifies error-handling and cleanup which is why the code you are looking at isn't awash in calls to Release.
There are special methods Attach and Detach for 'transferring ownership' so that the ref-count is not changed, but they are for special use cases. There are also some tricks you can do with Swap as well that are very useful for robust coding.
If you want to explicitly 'release' a ComPtr variable, you can assign null to it or better yet use Reset.
Like with all smart-pointers you should think about the lifetime of your pointer to decide how to use it. If a function or class is going to 'own' the object pointed to, then use of a smart-pointer is the right way to do it. If the function is just going to work with the object and then return without any change in lifetime, the function should take a raw pointer instead with you using the Get method on the ComPtr when calling it. Otherwise your program wastes a lot of time needlessly increasing and decreasing the ref-count when the ownership of the object was not actually in question.
Another option is to pass the smart-pointer parameter as const ComPtr& which avoids the ref-count cycling, but it has the side-effect of forcing the caller to use ComPtr when the raw pointer is more agnostic to the caller's object lifetime policy and therefore more flexible.
I've got a write-up of how to use ComPtr on the DirectX Tool Kit wiki. You can also see MSDN.
For non-COM objects, std::unique_ptr is a great option. You can also use std::shared_ptr and std::weak_ptr but there are a lot of performance implications and edge-cases to worry about in the shared case, so sticking to ComPtr for COM and std::unique_ptr for heap-allocated objects with a single-owner is best practice.
You should not normally need to call AddRef or Release through the smart pointer - the entire point of ComPtr is that it calls those for you.
You might still need to call them if you're converting a smart pointer to a "manually managed" (normal) pointer.
Can someone explain clearly what is the difference between
.Release()
and
->Release() on a CComPtr ?
To be precise how the memory management happens in either case?
The operator-> function of CComPtr yields a raw interface pointer to the object being managed. (but see below)
So, calling ->Release() will release the object (i.e. decrement its internal reference count).
The .Release() function will call ->Release(), and make the smart pointer stop managing the raw interface pointer.
The latter is usually what you want to do. If you call ->Release() then smart pointer doesn't know this , and when the smart pointer's destructor runs, it will call ->Release() again which is bad (double release).
According to this page, recent versions of ATL actually have operator-> return a proxy class which hides AddRef and Release, so you should get a compilation error if you try ->Release(), instead of getting a double delete.
Obviously, working with Direct X, we are heavily working with pointers, but the question I couldn't find on MSDN is: does Direct X create memory with "new" internally?
Example:
ID2D1GeometrySink * pSink;
path->Open(&pSink); // did this command use "new" internally?
In MSDN, they only used pSink = NULL, to create multiple sinks from the same variable. So will be there any memory leak?
As DirectX uses COM it must follow COM rules of maintaining memory.
So if a method returns an interface pointer, a caller is responsible for releasing this pointer.
In general, we never know nature of the returned pointer. In this particular case we don't know whether ID2D1GeometrySink allocated within this method, or this is a precreated object. All what you need to know about managing returned pointer is that you should call Release when you don't need this pointer.
Also I would suggest to use wrappers that call Release in destructor, I mean classes like CComPtr and others. In this case you don't need to call AddRef / Release yourself.
There are a few questions here.
Yes, the call to path->Open allocates resources for your sink. pSink is a pointer but you pass &pSink to the Open method - a pointer to the pointer. The call obtains a geometry sink and sets your pSink variable to point to that sink. It can do this because you have passed the address of your pointer rather than the value of the pointer.
Will it leak memory?
Yes, if you don't release the sink when you are done with it. The examples are clear on this, calling SafeRelease(&pSink); when finished with the object.
I want to use C++11 Smart Pointers in new projects, and encounter a problem. Many current projects still use raw pointers as parameters in their interface and have no interface for smart pointers, e.g. QMainWindow::setCentralWidget.
To keep type consistent, I have to pass the stored pointer from get() like this segment:
QMainWindow win;
std::shared_ptr<QWidget> scrollArea{ std::make_shared<QScrollArea>() };
// QScrollArea is a derived class of QWidget.
win.setCentralWidget(scrollArea.get());
But I can't make sure whether other methods in Qt execute operator delete on the stored pointer of scrollArea.
Will it cause memory leak or other problems if some methods in Qt do that?
I've checked the latest C++ Standard CD and found nothing on that. Seems it's an undefined behavior.
If doing this is an undefined behavior and dangerous, is there a safe way to use smart pointer(s) with the interface for raw pointer(s)?
There's no such way in the general case. For each "legacy" interface you want to use, you must read its documentation to see how it interacts with ownership (which is what std smart pointers encapsulate). A single object can only be managed by one ownership scheme.
With Qt in particular, it's definitely not safe to mix smart pointers and Qt management. Qt's parent/child relationship between QObjects includes ownership semantics (children are deleted when their parent is), so you cannot safely mix this with any other ownership scheme (such as std smart pointers).
Note that the Qt docs you link to explicitly state that "QMainWindow takes ownership of the widget pointer and deletes it at the appropriate time."
Unfortunately, if you are using an interface that uses raw pointers, you will need to consult the documentation to determine if the method does or does not take ownership of the provided pointer.
If the function takes ownership, then you must invoke .release() to transfer the ownership to the function. If the function does not take ownership, then you would pass the object with .get().
Will it cause memory leak or other problems if some methods in Qt do that?
It won't introduce a memory leak, since the memory is afterall released. However, since both QT and the shared_ptr would call delete on that memory, you would likely get some nice heap corruption (UB in general).
is there a safe way to use smart pointer(s) with the interface for raw pointer(s)?
Sure. Don't have unrelated entities manage the same memory. For that it is adavantegous to use unique_ptr instead of shared_ptr when possible. With unique_ptr you could call .release() to release the memory from the control of the smartpointer, thus giving you the ability to give control over to QT.
Of course you need check the documentation to see when you have to manage memory yourself and when QT will do it for you.
I don't think you should be doing any deleting with the QWidget.
http://qt-project.org/doc/qt-4.8/qmainwindow.html#setCentralWidget
Note: QMainWindow takes ownership of the widget pointer and deletes it
at the appropriate time.
If you have to use smart pointers, you can use a weak_ptr which won't own or destroy it.
If you are using an interface which takes raw pointers, you already have the problem that you must know who is responsible for the lifetime of those pointers.
Adding shared_ptr into the mix doesn't change this.
If the interface will possibly delete the object, then you cannot use std::shared_ptr safetly. std::shared_ptr must control the lifetime of its objects and there's no way around this (without adding another level of indirection)
You can however get some use out of std::unique_ptr. If an interface will not delete a pointer, you can safetly pass in ptr.get(). If an interface takes ownership of the lifetime of that object, pass in ptr.release() and you give up controlling the lifetime yourself.
All in, you can get some usefulness out of smart pointers even with a legacy codebase, but you've got to be a little careful.
But I can't make sure whether other methods in Qt execute operator delete on the stored pointer of scrollArea.
If the widget has a parent, then the QT's memory management will release that object. In that case you must not use a smart pointer, because your application will try to release it twice, and that is an undefined behaviour.
I have some intermittent segmentation faults in a Qt application. I think the problem is related to our (bad) use of QSharedPointer. The Qt Documentation states :
QSharedPointer::QSharedPointer ( T * ptr ) :
Creates a QSharedPointer that points to ptr. The pointer ptr becomes managed by this QSharedPointer and must not be passed to another QSharedPointer object or deleted outside this object.
I think we are doing both must not... :/
Is there a OOP way to enforce that the pointer managed by QSharedPointer cannot be deleted or passed to another QSharedPointer?
The best solution will be to have a compiler error.
The normal pattern is to put the new statement inside the smart pointer's constructor, like this:
QSharedPointer<Obj> p (new Obj(2));
That way you never have a reference to the naked pointer itself.
If you refactor your code so that all new operator are in lines like these, all your problems will be solved.
Well, an OOP-esque way would be to create the raw pointer as a private member in a wrapper class, and only perform actions on the pointer through methods that act on the shared pointer. kind of silly though, isn't it?
Or you could make your class with the raw pointer a base class to your other classes and make the raw pointer a private member in the class. In this regard, you're more or less creating an abstract class that does nothing. Your derivative classes must instead do all the work, and since they can't access the raw pointer, compilation will fail... this doesn't stop someone from just copying the raw pointer value out of the shared pointer, though.
In the end, I think your best policy is to manuall change all of the functions in question to use either a shared pointer or else a raw pointer. You can copy one shared pointer to another safely, so why no just go that way?
Edit:
I might add that regardless of whether or not you're using shared pointers, it sounds like you're having ownership issues. If a pointer was created in one scope, it should be deleted in that scope, unless the function that it is passed to contractually takes ownership of the pointer. Using a shared pointer in this scenario will only caused different bugs, eventually. It sounds like you have design issues deeper than just the sharing of pointers.
I'm not familiar with the particular Qt implementation of a shared pointer, but as a general guideline : attempting to mix raw pointers with managed pointers usually ends in blood. Once you 'trust' a shared pointer implementation in taking ownership of your dynamically allocated data, you should under no circumstances try to manage the object lifetime yourself (for example by deleting the provided pointer).
Is there a OOP way to enforce that the pointer managed by QSharedPointer cannot be deleted ?
I guess you could imagine some weird technique where the pointed type would have a private destructor and declare QSharedPointer as friend (which would effectively prevent any 'outside deletion' from compiling), but I wouldn't bet that anything good can come out of this (and note that it will make your type absolutely unusable unless new'ed and transfered to a QSharedPointer).
Is there a OOP way to enforce that the pointer managed by QSharedPointer cannot be passed to another QSharedPointer?
I can't think of any, and that is another reason why you should avoid manipulating the raw pointer once it's ownership has been transferred to a QSharedPointer.
Check your code for all .data() usage and make sure what they return is neither stored nor deleted. I don't think a hard compiler error would be good, because sometimes it's okay to pass the raw pointer, e.g. to a function that doesn't store nor delete passed pointers. (Especially when using 3rd-party code, you cannot always change everything to use shared pointers, and often you want it to work with both, raw and shared ptrs).
One could mark QSharedPointer::data() as deprecated (by patching Qt), to get a compile time warning.