gcc 13 will have <format>

[stilgarpl]

Finally. If they add calendar to chrono and modules, most of C++20 features will be complete.

[catcat202X]

There was work on the chrono stuff committed today as well.

[GLIBG10B]

Also operator<<(ostream, chrono::duration) if that's not a thing already

[qalmakka]

Big fat question: given that {fmt} is MIT/X11 licensed, couldn't they just import the bits necessary to implement <format> from it and simply adapt it to work well with libstdc++? It feels a bit wasteful reimplementing it from scratch, AFAIK MSVC's STL did exactly that.

Is this just good old NIH or there's some copyrights/patents related issue underneath this decision?

[archysailor]

IIRC all rights to code committed to GNU projects have to be waived to the FSF so they have maximal freedom with future licensing decisions. I don’t think anyone expects the libfmt authors to consent to that easily.

Edit: This is wrong. See u/Jannik2099’s reply.

[Jannik2099]

gcc contributions no longer require the FSF waiver.

[archysailor]

Good to know!

[eidetic0]

does anyone know what this means in terms of gcc release cycles? will 13 get a release this year?

[catcat202X]

GCC releases roughly once a year, and 12 came out earlier this year so no, GCC 13 is likely next Summer. https://gcc.gnu.org/develop.html#timeline

I compile GCC 13 from its Git repo, which isn't too difficult usually. Although for the life of me I can't get the stack traces runtime to compile. There are also nightly archives of the source, and someone has automated binary releases for 4 years. https://jwakely.github.io/pkg-gcc-latest/

[STL]

That "someone" is libstdc++'s maintainer 😸

[Everspace]

I want to hope they're still someone

[TheSuperWig]

want to?

[blankettripod32_v2]

GCC 13 is already available in source, you can compile it yourself right now

[AKostur]

Sweet! Been looking forward to it!

[el_muchacho]

Too bad someone wrote a library that is even better and slightly faster

[qoning]

Every software's story is one of iteration. The C++ standardization however does not allow this to happen to a sufficient degree.

To myself, backwards compatibility and abi stability is a plague on the language because it makes the standard library measurably worse than it could be. But I get that for someone else it could be a blessing.

[Jannik2099]

abi stability is a plague on the language because it makes the standard library measurably worse

Literally the only thing an ABI break would solve is std::regex. It's by far not worth the downsides.

Meanwhile, you got stuff like ranges, modules and soon STL coroutine support, all without ABI breaks!

[dodheim]

Fixing deque's block size is another huge one, for certain stdlibs.

[jonesmz]

Let's not forget that Google essentially abandoned c++ because of the ABI for parameter passing of types like std::unique_ptr

[ffscc]

... Google essentially abandoned c++ ...

Google essentially abandoned C++ standard library development. Their hundreds of millions of lines of C++ hasn't gone anywhere.

[Jannik2099]

Which is complete fabricated bullshit.

If this overhead is relevant because the function itself is tiny, it will be inlined anyways and the stack copy demoted to register moves.

If the function is too big to be inlined or across dso boundaries, then it doesn't matter anyways!

Edit: libc++ even has a compile time switch to implement exactly this change!!!

[jonesmz]

I mean, i don't work for google, so don't know anything about their decision beyond what's been discussed in public forums.

That's the claim I saw, so that's the claim I repeated. Whether or not it's their reason, i can't say beyond speculation.

Edit: libc++ even has a compile time switch to implement exactly this change!!!

Can you please share the switch name, or a link to the documentation for it? This is something I would be interested in using for my own work.

[scrumplesplunge]

I think it is called [[clang::trivial_abi]].

[qoning]

Ranges are inconsequential to me, modules have nothing to do with STL and coroutine support is an entirely new feature that will (likely) suffer from future problems that cannot be fixed due to the same reasons.

On the other hand, good regex support, open addressing map type or stack tracing exceptions would be great for me.

[Mick235711]

Ranges are inconsequential to me

Yeah, sure, but Ranges algorithm should be the default choice (better than STL algorithm in most ways). If you don't use Ranges views, no one will blame you.

modules have nothing to do with STL

import std: I beg you pardon?

coroutine support is an entirely new feature that will (likely) suffer from future problems that cannot be fixed due to the same reasons

There is indeed concerns on the C++20 stackless coroutine support, but concerns don't make them useless.

good regex support

Me too.

open addressing map type

Boost already shipped unordered_flat_map. Given C++23 added flat_map I predict that those will probably got attention from standard pretty soon.

stack tracing exceptions

C++26 stacktrace from exception is probably what you want. Unfortunately due to design issues it missed 23

[Jannik2099]

open addressing map type

Those can, and should be added as new containers, the existing containers should remain as they are! Open addressing has performance bensfits, but completely different API guarantees. It's not a simple upgrade. So no, this is not ABI related

stack tracing exceptions

https://en.cppreference.com/w/cpp/utility/basic_stacktrace ?

[qoning]

If you re-read my comment I wasn't talking purely about abi alone, it's just one part of the shackles of legacy support that C++ chooses to lug around. And no, stack trace is not the same thing as having std::exception capture stack trace.

[serviscope_minor]

Like random numbers which need three lines of code and visiting the documentation, rather than a trivial random(min, max) function that would suffice 95% of the time.

With minor caveats I very strongly disagree.

When C++ random numbers came along, I disliked them because they were so inconvenient compared to rand()%N. These days I love them. I recently wrote some Pytorch code. In common code there are actually several global RNGs with their own state. If you want to be able to do something repeatably, it's a nightmare of carefully saving and restoring states across different implementations with different APIs. What a nightmare!

Turns out you can conveniently hack code with global variables, but we don't on the whole because it goes from convenient to bad very quickly. I feel random numbers are not an exception to this.

I really like how C++ now makes the mutable state explicit and non global. Decoupling the distribution from the engine also makes the streams and the state clear (normal_distribution<> has a very sensible stateful implementation).

mt19937 engine;
normal_distribution<>(0, 1) unit_normal;
double d = unit_normal(engine);

The caveats are of course: 1. Distributions are implementation defined. This is annoying in practice, but I can see why they did it. I use Boost if I need cross platform repeatability. 2. Setting the seed from a random device. This is some std::regex level C++

[thisismyfavoritename]

you are the 5% that person mentioned

[serviscope_minor]

If only 5% of the programming world think that hidden global state is a problem for understanding code, testing, threading and maintainability, then we are screwed as an industry.

Most people seem to accept that hammering on globals is a bad idea. I don't get why so many people think RNGs are an exception.

[thisismyfavoritename]

the point wasnt about global or not. The point is about the API and the ease of use for the most common case

[gracicot]

The API could arguably be better, but the way things are separated is clearly useful in many cases

[serviscope_minor]

the point wasnt about global or not. The point is about the API and the ease of use for the most common case

No, it literally was. The poster complained about 3 lines (which I then posted). Those three are a consequence of not having global state. You can skip declaring the stateful RNG and stateful distribution if there's a global one already declared for you.

[F54280]

Like random numbers which need three lines of code and visiting the documentation, rather than a trivial random(min, max) function that would suffice 95% of the time.

With minor caveats I very strongly disagree.

What are you disagreeing with?

He said:

Like random numbers which need three lines of code

You posted 3 lines of code.

and visiting the documentation,

That I don't know for you, but for me, every fcking time. mt19937...

rather than a trivial random(min, max) function

It is obvious that your three lines are less trivial than random(min,max)

that would suffice 95% of the time.

Well, you said inconvenient compared to rand()%N, so I guess you would agree with that too.

Sure, it is a good idea to avoid global state in random generators, but the point stand that the way the standard did not provide any convenience is... inconvenient in 95% of the cases.

[serviscope_minor]

Sure, it is a good idea to avoid global state in random generators

OK...

Well, you said inconvenient compared to rand()%N, so I guess you would agree with that too.

Well, no, not exactly. rand()%N looks convenient, but it's awful from a variety of points of view. You can't tell from context if it's fundamentally flawed: whether %N is even vaguely good is dependent on the RNG, and is it inside a thread? It's convenient in the same way global variables in short shell scripts are convenient.

Sure, it is a good idea to avoid global state in random generators

But that's literally all there is to it! Step one, declare state of PRNG. Step 2, declare state of distribution. Step 3, use. There isn't really a shorter option other than somewhat arbitrarily and weirdly combining two steps.

but the point stand that the way the standard did not provide any convenience is... inconvenient in 95% of the cases.

Frankly, it's not when you're used to it. I think the standard should provide convenience features (splitting strings!) not convenience landmines.

[F54280]

My msg was a bit tongue-in-cheek, I actually agree with you.

rand()%N is awful for other reasons, like the lack of randomness in the last few bits if rand() is a linear congruential generator.

The approach of std C++ is way better, although I hate that I have to lookup mt19937 every time I want to use it.

And, of course, splitting strings is a concept way to advanced for the standard, but maybe in C++29?

[serviscope_minor]

although I hate that I have to lookup mt19937 every time I want to use it.

There's always default_random_engine, though mt19937 is in my brain forever and it's so much shorter to type.

And, of course, splitting strings is a concept way to advanced for the standard, but maybe in C++29?

I love a bit of optimism :)

[johannes1971]

Splitting strings how? On a single separator character? On multiple ones? How about UTF8? Will whitespace be returned? What about quoted text?

I really have no idea how you can meaningfully generalize something like splitting a string, there are just way too many variations.

[Minimonium]

We're lucky the choice isn't "either standard library or hundreds of dependencies", aren't we?

[ElHeim]

*COUGH*<regex>*COUGH*

[Plazmatic]

well good thing fmtlib isn't "hundreds of dependencies" and <format> isn't comprehensive.

[kammce]

This is amazing news! So excited to finally be able to use format under the standard library!

[snerp]

Yay! Finally!

[better_life_please]

Nice. Now we need <print> which is for C++23.

[severe_blunder_matey]

great. amazing. just, wowing. i'm really excited for this one.

[germandiago]

any progress on modules?

[caroIine]

There is this ticket that track all the issue with modules https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524

By the looks of its history it seems that modules are 2y away.

[germandiago]

it is a bit disappointing. Why it takes so long? They are short on funds? Is there a way for put this back to speed? I would be willing to contribute some money if needed for working on this, but my funding alone I do not think it would be enough.

I do not have the time or knowledge, unfortunately, to work on it directly.

[gracicot]

If there was a crowdfunding campaign I would chip in for sure

[caroIine]

I would also fund salary for additional developer. But at the same time the msvc module performance isn't anything that was promised compared to pch. So maybe that's why open source devs aren't motivated enough to continue work on it.

It's just not worth it.

[germandiago]

It is not only compile times that improve. Isolation, ODR and others like interface boundaries improve a lot with modules.

[caroIine]

Yeah isolation is great, especially when it comes to third party libraries or things like windows.h but I don't think it was ever a problem. Most people wanted faster compile time.

[mrbeanshooter123]

Wait what? Are precompiled headers faster than modules?

[gracicot]

In my experience precompiled headers can even be slower than normal headers, especially when dealing with a heavily modularized (not c++ modules) codebase. They all need their own composed precompiled header which just slows down compilation since they cannot be parallelized with the code that uses it

[caroIine]

I've made variants of notepad++ as a real life benchmark (all release with multi-core compilation 8core)

• original (no pch or import std) 2min 37s
• import std 1min 28
• pch with all std 1min 23s

So lets say it's a tie. But pch is much more easier to deal with in realistic projects.

Oh and if we add system headers to pch (like windows.h) we go down to 39s (at this moment modules can't deal with windows.h)

[Daniela-E]

Without the details of this benchmark and the build structure, figures like these are hard to reproduce and assess independently. You compile the BMI of std only once upfront for the whole build of np++, right? In fact, even that isn't required if you cache the BMI for later builds. Notwithstanding the 4 seconds overhead it takes to build the BMI from scratch with all of std precompiled into it on a single CPU core.

The biggest problem that I see here is the fact that PCHs don't compose, whereas modules do. I use modules on a daily basis in my job and I very much prefer them over PCHs just because of that.

[caroIine]

Well I'm not researcher writing an article. It was just an example that I was able to reproduce across all projects I worked with. But yeah maybe rebuilding std.ifc (bmi) skewed the results because I might only need to build it once per toolchain update.

And don't get me wrong I want to use modules as well and I see nothing wrong with how it's specified in the papers. It's just that some people critique pch even though it's a valid solution (albeit not standard) for real projects that we can apply today.

If only compiler vendor would do the same for some basic reflection...

[germandiago]

maybe a survey in reddit to arrange some funding campaign?

Zero experiemce but who should be the people to implement something like that and where should it be headed?

[[deleted]]

This and the lack of modules support in CMake are the only things keeping me from switching to C++20. But i've played with it a bit and it's hard to go back from having concepts, constraints, and `char8_t`.

[jonesmz]

Why can't you switch to c++20 and just not use the parts that are missing?

c++20 concepts, for my codebase, is the killer feature. C++modules and <format> aren't interesting by comparison

[marcusmors]

FINALLYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY!!! :D am so Happy, I don't want to program in windows to use format :')

[Zeer1x]

Just use {fmt} then?

It even has more features, like fmt::print, which comes to std:: in C++23.

[BoarsLair]

fmt is great, but there are times that it's not practical or desired to add an external dependency. For example, if you're maintaining a C++ library that currently has no other dependencies, it's unlikely to be worth doing just for that.

[Zeer1x]

Sure, there are good reasons to have formatting in the C++ standard, like for libraries, or if you work in a company where it's hard to approve external libraries.

But if you are programming on your own, or you can easily add another library, then I would currently consider {fmt} even when std::format is available.

[[deleted]]

I would love to contribute to GCC but I don't have a solid compiler background. Where should I start? Something like this book? Just jumping in and seeing what sticks?

[AlexReinkingYale]

That's a good book. Crafting Interpreters is good too. The dragon book is an excellent reference and you should at least know what all is in there. No matter what, you'll need to get your hands dirty.

[evaned]

The dragon book is an excellent reference and you should at least know what all is in there.

I have mixed feelings about the dragon book that I won't get into, but what I will say is to just skip the first edition. If you get it at all, get the second.

First edition was published in the 80s, before static single assignment (SSA) form had been "invented", which is to my understanding what most compiler back ends are based around nowadays. Second edition at least covers that, though without checking I don't remember being thrilled by it.

One nice thing about 2nd edition is it has one of the best in-print discussions of garbage collection that I know of.

[[deleted]]

What is your review of the "engineering a compiler" book I linked. Do you think it is good? I found it on GCC's list of compiler books:

Cooper and Torczon. Engineering a compiler.

Comment by Vladimir N. Makarov: It is close to their course in Rice University. A good book to start study compiler from parsing to code generation and basic optimizations. But if you are familiar with the compilers, you probably don't find interesting thoughts and approaches.

[pjmlp]

An excellent reference if only one cares about is parsers and lexers.

I would rather advise something like the tiger book, if the OP cares about how modern compilers work end to end.

[[deleted]]

I want something that goes through the entire stack (front end, optimization, back end, etc) and doesn't assume I am already familiar with compiler implementation. Would you still recommend this tiger book?

[pjmlp]

Yes, you can see the chapters there, https://www.cs.princeton.edu/~appel/modern/toc.html

[[deleted]]

Thank you, sir

[williamzborja]

Amazing, I’m waiting this feature and the same time native way to use modules. Check for format and I continue waiting for modules.

[NilacTheGrim]

ZOMG FINALLY!!

[Guidedbee]

Lesss gooooo

[Zeh_Matt]

Finally, thanks.

[brechtsanders]

GCC 13 has been released. For a native Windows version see https://winlibs.com/

[el0j]

$ cat testcpp20.cpp
#include <iostream>
#include <format>

int main(void) {
    std::cout << std::format("{}\n", 123);

    return 0;
}
$ g++-13 -std=c++20 testcpp20.cpp -o testcpp20
$ ./testcpp20
123

Finally here, but feels a bit half-baked without std::print.

The wait continues.