Move ImGuiIO initializers from constructor to struct definition

[Endilll]

A follow-up for #5540.

With some initializers moved to struct definition, I had to replace memset with a bunch of default initializers. No strong opinion on exact syntax. Its just = {} felt like the best fit for this repo that avoids most vexing parse.

[ocornut]

Thanks. Why not using = ImVec2(…) consructs ?
Before suggesting this in #5540 i forgot to consider how it may affect cimgui and other parsing based technology. We would need to get a green light from them before moving onward. (Cc: @sonoro1234)

[Endilll]

I was a bit afraid to initialize ImVec2 data members after you expressed compatibility concerns).

I took a quick look into cimgui code parser, and it seems like it's not able to handle curly braces in data member declaration:
cpp2ffi.lua#L1309.
I don't know what's the contract between you and maintainers of such bespoke parsers, but I hope they don't tie your hands too much).

[sonoro1234]

It is not only that it does not handle curly braces in data member declaration (It could be worked) but the main concern is that it does not handle any initialization in data member declaration as that is not C compatible.

[Endilll]

There're numerous other aspects of imgui.h which are not very compatible with C, which makes me wonder about ImGui's commitment to C compatibility.

[sonoro1234]

There're numerous other aspects of imgui.h which are not very compatible with C, which makes me wonder about ImGui's commitment to C compatibility.

The purpose of cimgui parser is to make an intermediate layer to make it compatible with C. The utility of cimgui is for other languajes that can interop with C but not with C++ so they can use imgui. Previous initialization of data members was done in contructors so that other languajes just needed to call the constructor for that (which was quite simple)

[ocornut]

I’m pretty sure that form of initialization makes no difference to code generation, it ends up in the constructor just the same. It is only a parsing problem ihmo.

[sonoro1234]

I don't know what's the contract between you and maintainers of such bespoke parsers, but I hope they don't tie your hands too much).

There is no such contract!!!.
Just the interest of making imgui easily accesible from other languajes.

[sonoro1234]

I’m pretty sure that form of initialization makes no difference to code generation, it ends up in the constructor just the same. It is only a parsing problem ihmo.

Yes, in cimgui there are only "parsing problems". To face new behaviour, the C constructor instead of just wrapping the C++ constructor should also remember which was the initialization value of members and assign this value inside.

[ocornut]

I’m pretty sure that form of initialization makes no difference to code generation, it ends up in the constructor just the same. It is only a parsing problem ihmo.

Yes, in cimgui there are only "parsing problems". To face new behaviour, the C constructor instead of just wrapping the C++ constructor should also remember which was the initialization value of members and assign this value inside.

No, you only need to call the constructor, as you alreasy do. The parsing problem is just ignoring what is after the = block on each line.

[sonoro1234]

No, you only need to call the constructor, as you alreasy do. The parsing problem is just ignoring what is after the = block on each line.

This is already done. The problem is that member values get uninitialized values then (could be garbage or could be 0 or null values depending on the languaje)

[sonoro1234]

May be you are right. I just checked the Zoom member in cimnodes_r

[sonoro1234]

Calling C constructor calls C++ constructor which initializes struct from C++ struct definition. C struct definition just gives information about memory layout.
So that definitely works!!!

[sonoro1234]

Should be correctly parsed by cimgui now.

[ocornut]

Thank you very much!

[ocornut]

I looked at it and unfortunately I realize I don't think it is a good idea :(

It would have been ideal for a fully public and configuration structure, but right now,

• it tends to push more implementation details in the .h, which becomes more noisy. Now we have stuff like ImS8 BackendUsingLegacyKeyArrays = (ImS8)-1; bool BackendUsingLegacyNavInputArray = true; etc. Even the casual = false / = {} are noise in many places apart from the config options.
• it splits initialization between two locations..

Right now given language support and the contents of ImGuiIO I don't think it is a good idea.
Since 1.87 added a tigher 1<>1 link between one ImGui instance and one ImGuiIO instance, I suppose we could potentially move some more fields to the context so they are not visible in .h but we'd got backward compat to think about it and it's not easy.

I think in the short term it would be more reasonable to drop this idea.
I'll be looking for other opportunities to use this for other structures though, but it's a shame bitfields would pushes us up to 2019.

Sorry for the time taken.

(PS: Fonts wasn't initialized to NULL in your version, easy fix, was detected by static analysis)