search

dearimgui / dear_bindings

C header (and language binding metadata) generator for Dear ImGui
MIT License
221 stars 12 forks source link

ImGuiListClipper constructor is required for initializing/getting the current imgui context #33

Closed zaafar closed 1 year ago

zaafar commented 1 year ago

Constructors/destructors for heap objects are removed from the API, as ensuring the correct allocation/deallocation behaviour across library boundaries can be awkward and so it seemed safer to avoid them. ImGui support zero-clear construction, so data structures can almost always safely be constructed with a simple memset().

So this line isn't true anymore.

ref: https://github.com/ImGuiNET/ImGui.NET/issues/401

i know imgui.net doesn't uses this lib but the issue applies to all binding generators.

EDIT: should prob move this to imgui rather than this repo.

ocornut commented 1 year ago

I have pushed a change for this to core imgui since it is affecting multiple bindings. https://github.com/ocornut/imgui/commit/e95d66faa8e6c0255572632f34fad97a32f680cd

Although it's solvable in this case, I worry that the constraint that every class can be zero-allocated may be occasionally tricky to fullfil everywhere in the future.

zaafar commented 1 year ago

Although it's solvable in this case, I worry that the constraint that every class can be zero-allocated may be occasionally tricky to fullfil everywhere in the future.

Yeah I agree, the workaround/solution to this problem from imgui.net side is not too bad, basically create an object, if it fails, look around and figure out what are you missing.

Thank you for the quick fix, closing this issue.

ShironekoBen commented 1 year ago

Sorry, a little late to the party here, but many thanks @zaafar for the heads up and @ocornut for the rapid fix!

I suspect if the zero initialisation thing becomes too big a problem there are ways we could make it reasonably painless in the bindings case at least (add metadata to types indicating when a constructor/destructor call is required and let people map that to a suitable idiom in the target language), but it might be a little more fiddly to come up with something on the pure C side of things that doesn't either require people to do some magic incantation to construct objects "just in case" they need something special done, or run the risk of code breaking when a constructor comes along after a type has already gone into use.

Fingers crossed we don't need that, though!