> I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable

The author talks about the code bloat, beacause of "an API that encourages custom formatter specification to live in a template". But at the end he mentions the standard solution to this problem:

> A preferable interface (I use, but also others AFAIK) is to check the type in a template (no choice there), and dispatch the formatting routine to somewhere that lives in a single translation unit.

So what prevents you from doing this with <format>? As I understand, the implementations of parse() and format() of std::formatter don't depend on the template parameters and can delegate to non-template functions residing in one CPP file. You can also provide additional wformat_parse_context/wformat_context overloads if you need wchar_t support.

He says in a different line they he doesn't use the STL, which does make sense for gamedev.

In my corner of the C++ world though, I am so, so excited for <format> in 6 years or however long it will take us to move to C++20.

{fmt} doesn't encourage "custom formatter specification to live in a template". On the contrary, if you look at the docs in https://fmt.dev/latest/api.html#formatting-user-defined-type..., none of the examples is parameterized. One even demonstrates how to define your formatting code in a source file. And if your formatters are so big that they meaningfully impact build speed you are doing something wrong. fmt/core.h is heavily optimized for build speed so you can just use it as a type-safe replacement for *printf. That said, implementations of std::format (especially Microsoft's) may not be as optimized for build speed yet. This will likely improve now that the ABI can be stabilized.

For me the compile time increases are a killer, even if the api is considerably nicer.

For reference, from Tokei from Unreal Engine reports lines of code (no empty lines)

Just C++ 11,375,669

Total (of everything) 31,379,114

That’s fairly representative of just the tooling side of things for a AAA engine. That’s not counting the logic of the game itself.

it's partly because of the engine code. there's even bigger stuff, especially especially if it's a company with any legacy codebase that's 10-20 years old or whatever (e.g. EA / Frostbite.) one i worked on took hours to compile the first time on a machine with 128gb of ram and a threadripper. the onboarding doc suggests getting some coffee at that point haha

a big part of working on them as a generalist ends up being the ability to know how to even navigate something like that (especially since they're often haphazardly documented)

(part of it is that most of the games "fork" the engine rather than using it as a standalone thing)

it's probably not everyone on the team building that whole thing each time, but yea. hundreds of solutions and millions of LOC isn't unusual

*i just did a quick check with unreal's source, it's ~20 million LoC (assuming I didn't mess up the filtering somehow)

If you've got a 10M+ LOC project and you're not doing some kind of distributed build you're throwing money and time away.

Isn't that average for any C++ software development?

I would have thought maybe 1M LOC at most, but 10M?

Why on earth is anyone normally compiling more than one or two files at a time? Why do a full build each time you change a function?

TBF, I have yet to see a C++ compiler where the union type punning trick doesn't work, there would be a lot of broken code if real-world compilers would change the current behaviour no matter what the standard says.

Of course now that std::bit_cast exists it's the safe thing to do (but then there's still C code that's compiled in C++ mode which was even recommended by Microsoft because the Visual Studio team couldn't be bothered to keep their C compiler in shape until a little while ago).

For those of us who aren't very familiar with what heavy physics simulations might involve, how would std::is_constant_evaluated() help?

It's not just the random initialization order that didn't make it from C99 into C++, other features also don't work, most notably:

...no chaining of designated initializers:

   const bla_t bla = { .a.b.c = 23 };

...and no array indexing:

   const blub_t blub = {
       .arr = {
           [4] = 23,
           [2] = 1
       }
   };

...all those limitations taken together, and the C++ designated initialization feature is pretty much useless except for the most trivial structs - while in C99, designated initialization really shines with complex, nested structs.

The funny thing is that none of those limitations would be required. Clang had supported full C99 designated init in C++ mode just fine for many years before C++20 appeared.

C++ isn’t C and has different structure semantics. Members are initialized in the order defined, which means you can write

    struct foo {
       int a = 0;
       int b = a+1;
    }
 

If the compiler just did the initialization in the order of declaration, regardless of the order in the initialization list this would not do what you expect: struct obj { int a; int b; }

     int ival = 0;

     auto o = obj {.b = ++ival, .a = ival};

o.a would not equal o.b.

I would like to have the initialization syntax of C because then one could reorder elements (say for packing reasons) and the designated initialization would “just work”…except it wouldn’t.

C++ designated initialization does buy you two things: 1- documentation, but more importantly 2- if you do reorder a struct or class data members the compiler will warn you that your initialization lists are now invalid rather than silently failing. I don’t know how to even find them all in a large code base any other way!

Contrary to C, in C++ initialization order of data members matters and can have side effects, that is why.

Destructors will execute in the reverse of declaration order, so if initialization order doesnt match declaration order, and some members depend on each other somehow, things will break. At the very least, it could be surprising. Not a problem in C where destructors don't exist.

I think, as usual this was the compromise that the committee was able to agree on above all objections. There is stills the possibility that the rules are relaxed if there is agreement. But somebody has to do the work to push it through standardization.

I also thought that the behaviour as standardized was useless, but recently I started writing more minimalist code eschewing constructors where aggregate initialisation would suffice, and I haven't really missed the ability to reorder initializers or skip them.

Initialization in C++ is already a mess. Making one of the core behaviours (members are initialized in declaration order) work subtly different for this case would make it even more difficult for the programmer to build a correct mental model.

From what I can tell, the snippet you posted would compile fine in C++20 mode.

  struct S {
    int A;
    int B = A;
    int C;
  };

  int i = 0;
  S s = {.C = i++, .A = ++i};

What would you expect code like this to do?

If you can use GCC to target all platforms, you can build with -std=gnu++XX to use C-like initializers.

I assume “code outside the lambda runs first, then code inside the lambda maybe runs later, maybe runs multiple times, maybe doesn’t run at all”.

It can especially create problems when the lambda captures a variable by reference which gets mutated and/or deallocated before the lambda runs, and the developer didn’t plan for mutation or deallocation.

Or (a problem with lambdas, but not “non-linearizing”), if the lambda captures a variable by value (copies the value) and mutates it, and the developer expected the mutation to persist outside the lambda.

It saves writing lots of boilerplate. If you implement it for a type, you automatically get: <, >, <=, >=, ==, !=

read cppreference.com

But the sort answer is all the other operators are automatically generated from that one if it is defined. So it makes the code simpler. And for many types <=> isn't much more complicated than the others

> a 32 bit signed induction variable and the compiler could reason about that variable but only if it also could assume no wrapping.

(Amateur C programmer silly question) I think I understand it as if we increment the variable (i+10) and use it in an if condition. With UB the compiler could skip that code altogether and assume it will never be reached?

more or less agree, although this issue isn't even really unique to C++. in practice it's still worth it imo, since debugging callback heavy stuff isn't exactly fun either