C++

i've been playing with cppfront for a few minutes now and it's been a surprisingly pleasant experience so far. i'm tempted to try it out at work to see what happens, but i wanna know if anyone tried to use it in production and what your experiences are

for those who haven't heard of it, cppfront is a cpp2 to c++ compiler, a bit like coffeescript for js. cpp2 is herb sutter's proposal of a new and cleaner c++ syntax with better ergonomics, better orthogonality, and better defaults

First release of the checker against Google's style guide in over 2 years. Python 2 and 3.7 are no longer supported. Python 3.12 support was added along with fixed CI for 3.8. See CHANGELOG.rst for a full changelog, including quite a bit of features not mentioned here.

std::array in C++ isn't slower than array in C

https://pvs-studio.com/en/blog/posts/cpp/1164/

@cpp@programming.dev @cppguide @cpp@discuss.tchncs.de

C++ programmer's guide to undefined behavior: part 6 of 11

https://pvs-studio.com/en/blog/posts/cpp/1163/

@cpp @cppguide

I just wanted to have a handy description of computed goto that I could refer to, to reuse this concept without having to read thousands of line trying to make sense out of it.

I created a little side project over the past few days, a new build system for C and C++: https://github.com/blueOkiris/acbs/

I've seen a lot of discourse over C build tools. None of them really seem solid except for (some) Makefiles (some Makefiles are atrocious; you just can't rely on people these days). Bazel, cmake - they're just not straight forward like a clean Makefile is, basically black magic, but setting up a Makefile from scratch is a skill. Many copy the same one over each time. Wouldn't it be nice if that Makefile didn't even need to be copied over?

Building C should be straight forward. Grab the C files and headers I want, set some flags, include some libraries, build, link. Instead project build systems are way way way overcomplicated! Like have you ever tried building any of Google's C projects? Nearly impossible to figure out and integrate with projects.

So I've designed a simplistic build system for C (also C++) that is basically set up to work like a normal Makefile with gcc but where you don't have to set it up each time. The only thing you are required to provide is the name of the binary (although you can override defaults for your project, and yes, not just binaries are possible but libs as well). It also includes things like delta building without needing to configure.

Now there is one thing I haven't added yet - parallel building. It should be as simple as adding separate threads when building files (right now it's a for loop). I know that's something a lot of people will care about, but it's not there yet. It's also really intended to only work with Linux rn, but it could probably pretty easily be adjusted to work with Windows.

Lay your project out like the minimal example, adjust the project layout, and get building! The project itself is actually bootstrapped and built using whatever the latest release is, so it's its own example haha.

It's dead simple and obvious to the point I would claim that if your project can't work with this, your project is wrong and grossly over-complicated in its design, and you should rework the build system. C is simple, and so should the build system you use with it!

So yeah. Check it out when y'all get a chance

I had some fun trying to check if a hash (more like a transformation really) was collision free, so I wrote a quick piece code and then iterated on it so that it was usable.

I might add a quick bench and graphs and try to push it even further just for fun, to explore std::future a bit more (though the shared bit set might be a problem unless you put a shared condition variable on it to allow concurrent read but block concurrent writes?)

I wrote a blog post comparing several range libraries for a case that is doing filter with non-trivial lambda and then reverse.

I have been programming in C++ for a very long time, and like a lot of us, I have an established workflow that hasn't really changed much over time. With the exception of bare-metal programming for embedded systems, though, I have been developing for Windows that entire time. With the recent "enshittification" of Windows 11, I'm starting to realize that it's going to be time to make the switch to Linux in the very near future. I've become very accustomed to (spoiled by?) Visual Studio, though, and I'm wondering about the Linux equivalent of features I probably take for granted.

• Debugging: In VS, I can set breakpoints, step through my code line-by-line, pause and inspect the contents of variable on-the-fly, switch between threads, etc. My understanding of Linux programming is that it's mostly done in a code editor, then compiled on the command line. How exactly do you debug code when your build process is separate from your code editor? Having to compile my code, run it until I find a bug, then open it up in a debugger and start it all over sounds extremely inefficient.
• Build System: I'm aware that cmake exists, and I've used it a bit, but I don't like it. VS lets me just drop a .h and .cpp file into the solution explorer and I'm good-to-go. Is there really no graphical alternative for Linux?

It seems like Linux development is very modular; each piece of the development process exists in its own application, many of which are command-line only. Part of what I like about VS is that it ties this all together into a nice package and allows interoperability between the functions. I can create a new header or source file, add some code, build it, run it, and debug it, all within the same IDE.

This might come across as a rant against Linux programming, but I don't intend it to. I guess what I'm really looking for is suggestions on how to make the transition from a Visual Studio user to a Linux programmer. How can I transition to Linux and still maintain an efficient workflow?

As a note, I am not new to Linux; I have used it extensively. However, the only programming I've done on Linux is bash scripting.