P2590R2, Explicit lifetime management (PR106658)
Nearly all zero-copy code that deals with external I/O buffers looks something like:
std::unique_ptr<char[]> buffer = stream->read();
if (buffer[0] == FOO)
processFoo(reinterpret_cast<Foo*>(buffer.get())); // undefined behavior
else
processBar(reinterpret_cast<Bar*>(buffer.get())); // undefined behaviour
The "start_lifetime_as" facility does one additional thing beyond providing a tidy standard name for the memory laundering incantation. Semantically it doesn't touch the memory whereas the no-op memmove intrinsically does. In practice, this makes little difference, since the compiler could see that the memmove was a no-op and optimized accordingly.
You're allowed to access any type via a char buffer. But the converse is not true (quoting https://eel.is/c++draft/expr#basic.lval-11):
> An object of dynamic type Tobj is type-accessible through a glvalue of type Tref if Tref is similar ([conv.qual]) to: Tobj, a type that is the signed or unsigned type corresponding to Tobj, or a char, unsigned char, or std :: byte type. If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.
The dynamic type of a char buffer is, well, a char buffer, and can only be accessed via things that are the same type as a char buffer up to signedness and cv-qualification. The actual strict aliasing rules are not commutative!
Malloc returns a buffer and then you cast it to the type you want. Similarly for all memory allocators.
Punning the same region of char buffer as two different types is a bit different.
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 releases has gotten companies more into the habit of updating frequently which also, very helpfully, gives devs new features frequently.
SM was a monstrous Java app that papered over the (horrifying) fact that everything on a Wellfleet router was configured with SNMP (full-body shiver). Oh, there was a CLI, but even a hard-core CLI pilot like myself couldn't face stuff like "set wflplnterfaceEntry.2.192.168.10.10.3 1" all day long.
Wellfleet clearly employed no software engineers, only monkeys that hammered on keyboards and piled cruft upon cruft to the SM codebase. The end result was that every release of Wellfleet device code (down to point releases) relied on a particular version of SM, which, of course, relied on a particular version of Java.
Now, since virtually no site over a certain size could count on every device running the same version of code, you had to be able to switch between a couple of versions of Java to run a given version of SM. And, as a consultant to Wellfleet shops, I had to be able to run all of them. I got really good at multibooting Windows, but in the end I had a 'Wellfleet' laptop modified a bit so I could easily pop it open and swap disks, each one for a different version of SM running on a different version of Java.
Good times...it was not.
It used to be slower and I've spent way too much time working around C++ bugs in GCC 2.95
(The fact that I remember the problematic version is telling :)
-static-libstdc++ -static-libgcc
?But:
> GCC can now output diagnostics in HTML form via -fdiagnostics-add-output=experimental-html
I wonder what drove the decision to remove JSON output and add HTML output?
A big difference between the 2 is also the license. GCC uses the GPL while LLVM uses Apache License, hence the projects don't share code.
No
Hopefully they fixed those issues. We all need stability and things-to-work.