Default struct values / constructors?

[pdoane]

There are not many struct inputs to ImGui, but default values would be helpful (e.g. ImFontConfig).

The comments have the default values made by the C++ constructor, so maybe it's possible to parse/extract?

[ShironekoBen]

That's a nice idea, definitely, but I'm not sure the comments are consistent enough to make parsing them reliable.
Do you actually need the values themselves, or would exposing the ImFontConfig() constructor be enough for your use-case?

I'm thinking that might be possible with some in-place new shenanigans - something like:

void ImFontConfig_Construct(ImFontConfig* config)
{
    new (config) ImFontConfig();
}

[pdoane]

The values are better as they can go directly into the struct definition but exposing the constructor works and future-proofs things.

[ocornut]

I’m also not against making comments more consistent. In theory would be using more default value at member declaration site (now that the library requires c++11), but when i tried using those assignments i found it often led to assigning half in headers and the other half requires constructor code either way, so its not easy applicable consistently and it doesn’t feel nice to have that split. I also don’t think we can assign default values for bitfield variables.

Enforcing a constructor call seems like the robust and easier thing to do, and people would naturally understand it, and possibly if constructor bames are standardized some bindings may automate or wrap the call in a way that’s more natural to the language?

[ocornut]

Someone stumbled on exactly this today:
ocornut/imgui#7993
They are using cimgui but i noticed dear bindings is missing a ImFontConfig_Construct().
And I was thinking opening an issue and realized there was one.

Structures that could require constructing on user-side:

• ImFontConfig
• ImFontGlyphRangesBuilder (*)
• ImGuiListClipper (*)
• ImGuiSelectionBasicStorage
• ImGuiSelectionExternalStorage (*)
• ImGuiStorage (*)
• ImGuiTextBuffer
• ImGuiTextFilter (*)
• ImGuiWindowClass

(*) technically can currently be zero-initialized but it could be considered a bit brittle / not future proof.
I had to work on my side to specifically ensure that ImGuiListClipper would still work zero-initialized but I feel it may be better to just add a constructor.

Nothing else AFAIK needs to be constructed by users.
It may be good to just generate all the _construct()/_destruct() functions.

[ZimM-LostPolygon]

Yup. I've hit this exact issue with ImFontConfig, as its one of the few widely-used structs that can't be zero-initialized. dear_bindings already supports _construct()/_destruct() generation, but only for structs that are explicitly marked as by-value, and it just returns the constructed value then. For non-by-value structs, it'll have to use C++ placement new to initialize in-place instead