-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UniqueHandle Constructor should be explicit #67
Comments
I hit this bug too when migrating legacy code. In the end I decided not to use the Unique variants. I would actually argue that the |
Imho, the RAII-less vk::Handles are not idiomatic for C++ and very alien to use. Most C++ programmers (really embracing the language and not using it as C with classes) would expect wrapper classes like Unique*. But they have to be implemented with care. Look at std::unique_ptr for example, it has an explicit constructor too for the same reason. |
@spfuetzner I agree with you, but in terms of overhead it's quite large. What would be wrong with using |
With the current system, unless you nest your dependencies, it's not clear the order that they would be destroyed. For example, creating several |
@ioquatix std::unique_ptr would be hard to implement without extra allocation per object (very bad). It's template parameter has to be the dereferenced-pointer-type. In 32-bit this would not be possible because Vk* are integers, not pointers. Your second question: |
I did not know this was guaranteed by C++? |
This is very basic stuff. Maybe you mean something different, then you should show some example code. |
struct Renderer {
vk::UniqueDevice _device;
vk::UniqueOtherStuff _other_stuff;
Renderer() {
_device = ...;
}
void render_something() {
_other_stuff = ...;
}
~Renderer() {
// What is order of destruction? How guarantee _device destroyed last?
}
} |
Ah, found this: http://stackoverflow.com/questions/7241385/why-the-destructor-in-c-de-allocated-memory-in-reverse-order-of-how-they-were But yeah, I'm still not convinced that it would work in the example I gave. I'll have to try it out. |
_other_stuff is destroyed first because it is declared last. This is guaranteed by the language rules. This is also the order of initialization, no matter in what order the members are in the initialization list. Also resetting the UniqueHandle or calling operator= makes no difference. For a minimal example using vkhpp and UniqueHandles, see my small project here: |
Before implementing UniqueHandle we tried to utilize std::unique_ptr. Unfortunately one compiler produced errors when using the pointer typedef in the Deleter in combination with operator-> in the handle and thus we had to 'invent' the wheel again. Long term we should get rid of our own class and use std::unique_ptr instead. |
... in order to prevent premature or multiple destruction. For example:
The text was updated successfully, but these errors were encountered: