0.9.11 plan

Moderators: MattKingUSA, khz, muldjord, deva

User avatar
Glocke
Established Member
Posts: 18
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Post by Glocke »

Yes, the unique_ptr would delete the event as the unique_ptr's scope is left.

The initial problem was, that the Win32-API returns an owning-pointer and the X11-API a non owning-pointer, right?. Is there a reason to let the Window API hold the event any further (X11 case)?
Just a guy
User avatar
deva
Established Member
Posts: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

The underlying APIs are vastly different so this was the most intuitive way to make it.
I think we should do a more thorough redesign when we start implementing the MacOSX backend and leave it with shared_ptr for now?
User avatar
Glocke
Established Member
Posts: 18
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Post by Glocke »

deva wrote:The underlying APIs are vastly different so this was the most intuitive way to make it.
I think we should do a more thorough redesign when we start implementing the MacOSX backend and leave it with shared_ptr for now?
Well, so we should redesign that to have some common API. But: Using a shared_ptr cannot solve this problem!

Because the API returns a pointer to the first element of a vector, the resource is still owned by the API instance. Furthermore, the last shared_ptr - that goes of out scope - deletes the resource. Hence, your shared_ptr instance cannot know whether it's the last shared_ptr instance holding this resource. It does not even know whether you called the X11 or Win32 API (the code is using polymorphism if I understood it correctly).

So we have the following cases:
1. The X11 API is called, which returns an owning resource. The shared_ptr releases it correctly (as a unique_ptr would do, too). Everthing's fine
2. The Win32 API is called, which returns a non-owning resource. The shared_ptr also releases it (like a unique_ptr would do xD) because from it's point of view, it's the last shared_ptr holding this resource. The Win32 API might crash when trying to double free the resource.

Feel free to question this :)

Hence, we have to redesign the API-handling asap (imho). So the initial question is about return pointer or object. If we return a pointer, we should use unique_ptr. Idk the exact size of the event, but if it's small, I'd return the actual object (no ptr, no reference). So we copy it on return. The Win32 API can still hold its internal stuff, and the call for X11 will delete the owning-ptr after copying the resource.
Just a guy
User avatar
deva
Established Member
Posts: 285
Joined: Sun Oct 23, 2016 10:15 am
Has thanked: 3 times
Been thanked: 31 times
Contact:

Re: 0.9.11 plan

Post by deva »

The win32 Events are stored as shared_ptr inside the vector so I think it should work as intended.

Returning a copy of the object will destroy the polymorphic type so that won't work out-of-the-box. But something like that would definitely be nice.
Perhaps a single event type with a union inside?
User avatar
Glocke
Established Member
Posts: 18
Joined: Mon Oct 24, 2016 4:54 pm

Re: 0.9.11 plan

Post by Glocke »

deva wrote:The win32 Events are stored as shared_ptr inside the vector
Really :shock: ... wtf
deva wrote:Returning a copy of the object will destroy the polymorphic type so that won't work out-of-the-box. But something like that would definitely be nice.
Perhaps a single event type with a union inside?
The event is polymorphic, too? Omg, we should wrap this entire mess and provide a common event that we can handle easily.
Just a guy
Post Reply