New C++ features in GCC 15
7 comments
·April 25, 2025tlb
pjmlp
Nothing new unfortunely, when C++11 brought fresh wind into C++ and everyone raced to support it, I thought the compiler portability issues would eventually be a thing of the past.
Instead, even when the ecosystem has been reduced to three major compilers, and derived forks from two of them, it has hardly changed when writing portable code.
There are other examples, like supporting C++23 std in C++20 mode, not all of them support it.
pjmlp
For me one of the big improvements is the modules support, GCC is now joining clang and MSVC, kudos to the team.
LorenDB
#embed should make it fairly easy to write an installer from scratch. You'll still have to handle things like registry keys on Windows manually, but the barrier to entry for developing installers will be much lower.
pjmlp
At least on Windows you could already do that with resource files, even if not as easy as #embed.
And although even Microsoft teams themselves aren't that great following their employers advice, the use of the registry should be minimized to the keys that are really required by the system, everything else should be in manifest files, or local configuration.
Depending on how much you would like to depend on MSI, MSIX, or do your own thing, running a .reg script might also do the job if the entries are rather simple.
ashvardanian
`#embed`, finally! Fixing UB in range-based `for` loops is also a good one!
null
> Fix for range-based for loops
Oh man, having different compilers in c++20 mode handle things differently is going to cause more grief, not less.
Reminder: Prior to c++23 the following is broken:
That's because the lifetime of the vector isn't extended through the life of the for loop. That is, the vector is destructed right after identity returns, and the for loop ends up trying to iterate through a vector that's been destructed.But now gcc in c++20 with -frange-for-ext-temps mode will extend the lifetime of the vector and the above code will work, and people will write code like that, and it'll break mysteriously on other c++20 compilers. The usual way it breaks is that the for loop does nothing because in destructing the vector it sets the begin and end pointers to null, so it's a subtle kind of breakage.
BTW clang with -Wall doesn't complain about the above broken code.