C++

PVS-Studio presents a series of webinars on how to build your own programming language in C++. In the first session, we will go over what’s inside the “black box”. In clear and plain terms, they’ll explain what a lexer, parser, a semantic analyzer, and an evaluator are.

Major new features:

geteilt von: https://programming.dev/post/42846946

Inspired by a comment in this r/cpp thread on how, well, hidden friends don’t seem to be reflectable; this in the context of C++26 reflection.

Following up on the discussion from earlier this month among GCC developers over switching to C++20 by default for the GCC compiler as the default C++ standard when not otherwise set, that change has indeed happened. Merged now is the change defaulting to C++20 (well, the GNU++20 dialect) rather than C++17/GNU++17 when not otherwise specified when compiling C++ code.

Following the recent idea floated to consider C++20 as the default C++ language dialect by the GCC compiler rather than C++17, it was discovered that the GNU Compiler Collection itself has problems building in C++20 model.

Compiler engineer Marek Polacek of Red Hat recently proposed making the C++20 language specification (or rather the GNU++20 dialect) the default C++ version when not otherwise specified.

Qt Creator 18 adds experimental support for Development Containers and many more improvements.

Fil-C is a memory-safe implementation of C and C++ that aims to let C code — complete with pointer arithmetic, unions, and other features that are often cited as a problem for memory-safe languages — run safely, unmodified. Its dedication to being “fanatically compatible” makes it an attractive choice for retrofitting memory-safety into existing applications. Despite the project’s relative youth and single active contributor, Fil-C is capable of compiling an entire memory-safe Linux user space (based on Linux From Scratch), albeit with some modifications to the more complex programs. It also features memory-safe signal handling and a concurrent garbage collector.

Qt 6.10 is now available, with new features and improvements for application developers and device creators!

I've always found C++'s "trend" of handling normal or non-exceptional system errors with exceptions lackluster (and I'm being charitable). Overall trimming things down to (basically) passing around a couple integers and telling the user to check their manual is much better, much less error prone, and much more efficient and deterministic.

cross post from: https://programming.dev/post/37369902

So today I wanted to talk about a very cool example that Dan put together on the flight home from Sofia, while I was unconscious a few seats over: the ability to, at compile time, ingest a JSON file and turn it into a C++ object.

It's not fully finished yet, but it's getting there, and i didn't write documentation beyond the README.md and tests/test.cpp but I'd like some feedback on it.

Herb Sutter just announced that the verdict is in: C++26, the next version of C++, will include compile-time reflection.

Today marks a turning point in C++: A few minutes ago, the C++ committee voted the first seven (7) papers for compile-time reflection into draft C++26 to several sustained rounds of applause in the room.

Let’s take a problem that can only be solved with Reflection and compare what the solution would look like between:

Vcc - the Vulkan Clang Compiler, is a proof-of-concept C and C++ compiler for Vulkan leveraging Clang as a front-end, and Shady our own research IR and compiler. Unlike other shading languages, Vcc aims to stick closely to standard C/C++ languages and merely adds a few new intrinsics to cover GPU features. Vcc is similar to CUDA or Metal in this regard, and aims to bring the advantages of standard host languages to Vulkan shaders.