Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC 16 has been released

gcc.gnu.org

Post reply on HN
Print view View original

51–54 of 54 posts

Re: GCC 16 has been released

#51

Post by gpderetta »

gavinray wrote: post #11

I want to point out an implemented feature that people SHOULD be adopting but that I doubt will be picked up: P2590R2, Explicit lifetime management (PR106658) This is for "std::start_lifetime_as ". If you have not heard of this before, it's the non-UB way to type-pun a pointer into a structured type. Nearly all zero-copy code that deals with external I/O buffers looks something like: std::unique_ptr buffer = stream->…

Well, ignoring alignment restrictions, it depends on the implementation of read. If it is truly opaque, as far as the compiler is concerned, the kernel (or the network card or whatever) is truly constructing a Foo in that buffer, making the cast perfectly legitimate.

start_lifetime_as is useful when the buffer lifetime is transparent to the compiler and it can mess up aliasing assumptions.

Re: GCC 16 has been released

#52

Post by denotational »

leni536 wrote: post #48
denotational wrote: post #38

Earlier quoted context omitted.

If the type is an implicit-lifetime type, then you can legally create an unsigned char array, and then reinterpret_cast a pointer to that to a pointer to the type. See https://eel.is/c++draft/intro.object#def:object,implicit_cre... . https://eel.is/c++draft/intro.object#15 is an example showing this with malloc; the subsequent paragraph further permits it to work with an unsigned char array.

1. You still need std::launder in that case. 2. It doesn't initialize the object that is implicitly created, even if the storage has initialized chars.

The paper that introduced the implicit lifetime mechanism suggests that std::launder is not required: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p05....

Re: GCC 16 has been released

#54

Post by SAI_Peregrinus »

jabl wrote: post #18
cogman10 wrote: post #14

Earlier quoted context omitted.

Yup. OpenJDK is one of the best success stories of this. Up until Java 9, they would release once features were complete. But that meant there were years between the 7 and 8 release and even more years between the 8 and 9 release. The industry had gotten into the habit of always running old versions of Java (my company was on 6 for an uncomfortable amount of time. But others have had it worse). More frequent smaller…

The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.

And this is why I prefer a "hybrid" version scheme between CalVer & SemVer: A series number to allow LTS releases, a period, a hyphenated datestamp, optional "flag" letters "B" for breaking changes, "S" for security fixes, "F" for new features (more than one can be present, always in that order), and if more than one release is made on the same day the second & subsequent releases get a period followed by a release number starting from 1.

E.g. 3.2026-05-01FS for a first release of the day with a new feature & security fix to release series 3, 2.2026-05-01S backporting the security fix to release series 2 (LTS, say), 3.2026-05-02 for a "bug fixes & performance improvements" release, 3.2026-05-02S.1 for a security fix to the "bug fixes & performance improvements" release.

Like SemVer, this lets users know when there are breaking changes to an API or such, which releases contain security fixes, which releases have new features, and allows multiple simultaneous release versions for LTS support. Like CalVer it lets users know how recent a release is, and makes it pretty easy to figure out what the release schedule was historically (and likely still is) by comparing versions.

Post reply on HN