The change in syntax from assignments to initializations is because assignment statements aren't supported in constexpr functions until C++14, and there's no reason to require that.

Would it be worth changing the example constructors in imconfig.h as well?

Would it be worth changing the example constructors in imconfig.h as well?

Maybe. I think a lot of users would feed ImVec4 to an __m128 or so, which wouldn't work as constexpr, and could be confusing.

This change actually lets us save 400 KB of machine code in our .exe file because a bunch of Dear ImgUi-related calculations can be moved from runtime to compile-time.

Can you clarify which compiler/settings and which sorts of constructs it would make a difference?
I'm surprised that this would make the slightest difference in terms of optimization, since this is a simple inline function every compilation unit can see (admittedly I am not well acquainted in the effects of this, but similar to const I don't see how it can an effect on code generation in that situation).

(In my tests with VS15 both debug and release exe for example_win32_directx11.exe were identical.)

EDIT To clarify I am not pushing against this at all, but I want to really understand the effects it has on code generation.

To clarify I am not pushing against this at all, but I want to really understand the effects it has on code generation.

I made some tests, with e.g. a large table initialized with ImVec2() entries and could notice a difference. What was your use case?
So if I am understanding this correct, dear imgui core codebase isn't so much affected the 400 KB you mentioned don't come from your example demo but in your app, right?

That's a good enough reason for merging so I'll merge either way, but curious to understand this well.

Merged 71f98dd + similar change for other structures 5854da1 + updated imconfig comment (best to have it as an "example", users are free to remove it if it gets in the way of low-level math stuff?).

To clarify I am not pushing against this at all, but I want to really understand the effects it has on code generation.

I made some tests, with e.g. a large table initialized with ImVec2() entries and could notice a difference. What was your use case? So if I am understanding this correct, dear imgui core codebase isn't so much affected the 400 KB you mentioned don't come from your example demo but in your app, right?

That's a good enough reason for merging so I'll merge either way, but curious to understand this well.

We have an IMGUI_COLOR(name, argb) macro that declares a named ImVec4 constant based on a 32-bit ARGB color constant. The macro calls a function that does the uint32_t-to-float[4] color conversion. Without the ability to make the conversion function constexpr, the compiler will generate assembly code to initialize each of these at program startup. The conversion function needs to return type ImVec4, and it can't do that unless the ImVec4 constructor is constexpr as well.

Combined with the rule that const variables are implicitly static in C++, and how many files were #includeing this header, it multiplied out to 400 KB. Now that I think about that issue, refactoring this with extern would've reduced the size to maybe 10 KB.

An aside for both @Myriachan and @ocornut ... it's currently a little confusing as to whether trivial/defaulted/empty ctors are a good thing.

struct S { string s_; S(const string& s) : s_(s) {}; };

Done like this, the compiler will likely inline that constructor into every translation unit where it's needed, and I chose string because it's a sneakily complex constructor: https://gcc.godbolt.org/z/jWcrxaonG vs https://gcc.godbolt.org/z/sf8Ph3hG7

All too often we forget this applies for a defaulted/empty constructor too: https://gcc.godbolt.org/z/MMc8vYoeT (compare f1 vs f2 implementation).

Here you're trading code size for branch avoidance, and you're really in amongst the weeds of compiler optimization flags and behaviors. Are they building -Os or -On? Whole program optimization? Is this a hot- or cold-path branch?

That's a really, really hard generalized library solve and constexpr - or ideally, '20s consteval - is a great alternative.