Anyway here they are:
Qt desktop app written in C++:https://github.com/thebigG/Tasker
Simple GPIO front-end for linux GPIO driver(could definitely use some improvement) written in C++ and uses boost:https://github.com/thebigG/simple_gpio
WebApp I JUST started working on(This will be a frontend for a YOCTO/FPGA project I'm working on; guitar pedals), and yes it uses good old C++ and runs on the browser:
https://github.com/thebigG/wPedals
And while I'm at it, might as well mention my custom plugins for Godot Game Engine(C++):https://github.com/thebigG/godot-3.x-modules
I have found that C++ is the best compromise for me between performance and elegance ifI do say so myself.
I would love to be able to use something like Rust, but the RTOS options and library support are not quite there yet.
With more powerful embedded processors becoming available, Micropython is an option for some projects.
Cpp still has the (huge) advantage of maturity. Rust is great but still half-backed. Things like thread-local-storage, custom allocators and async are either unstable or incredibly rough around the edges.
Finally, my experience has been that third-party libraries in cpp are fewer but of greater quality than the ones in rust. There are many many libraries available in rust due to the amazing dependency system. But the average quality is quite poor.
In cpp you tend to be conservative when adding dependencies which means you have a much better understanding of the code you run. Or, you write your own code that’s usually custom made for your purpose, which generally end up as being more performant.
I'm using restinio for the REST layer (sadly deprecated a couple of months ago, but it still seemed like the best option in terms of clean interface) and sqlite for the DB layer.
I've architected it all so I have a purely insert-only and order-independent DB on the write-side, so litestream was seeming like a good fit for single-writer, multiple readers, but now that's been abandoned, I'll wait until litefs stabilises, or roll my own to do what I need.
I originally started the REST side in dart so I could share code with the flutter client app, but I soon realised that performance wasn't where I wanted it to be and that the backend queries were all very different to client side anyway, so it seemed easier just to create the REST side in C++. I should add that my normal work has been predominantly C++ for many years so it's more familiar to me than learning something else and also being able to hit the sqlite layer directly without another abstraction layer seems beneficial.
I was planning to use litestream to distribute the sqlite DB to multiple readers, but now that's deprecated, I'll probably look into doing my own in C++ later on if his new focus on litefs doesn't work out for me.
I model most the C++ code around Rust's semantics for things like option<T> and result<T, E>. Currently working on replacing my boost::intrusive_ptr usage with an equivalent which is non-nullable, to be combined with option<T>. Even with value semantics, RAII, and hefty TMP for type-rich APIs, C++ still bites in many ways. It's still so easy to have UB compile, including anything from iterator slip ups to interdependent static globals in different TUs with undefined ctor/dtor orders.
The (side) project I have put most effort into in the last year is k8deployer, a helm like utility that can deploy simple and complex applications in kubernetes with minimal effort. https://github.com/jgaa/k8deployer
In these projects I don't use other languages. C++ is the only language where I easily get into "flow".
https://github.com/0xf00ff00f/windmap
Uses CMake, Qt6, CUDA and OpenGL. Here's a short video showing how it currently looks like:
I started a project (https://github.com/tedmiddleton/mainframe) last year to make a dataframe in C++ because I was running into some performance limits in Pandas. I’m not sure how useful a C++ dataframe is - but I imagine it as being an alternative to going all the way to Hadoop and spark if you’ve outgrown pandas.
It’s about velocity and experience. Language rarely matters ( and when it does, you can use what’s appropriate ). For us, C++ checks all the boxes.
So, I figured, better the devil you know. And of course: choice of compilers, choice of FOSS libraries, my own libraries and workarounds to various well-known annoyances and, well, debuggers!
I'm also using it for an animation tool[1]. I've been using 3Blue1Brown's Manim (written in Python) which is amazing, but it lacks real-time editing and proper 3D blending. It also lacks audio synchronization, 3D texture support, and some more complex features that I'd like to add :)
I mostly write system tools and cloud-focused tools. For the former I use C++, for the latter it's Go.
The portability of C++ just can't be beat. At worst you have to restrict yourself to a certain earlier C++ version (e.g. C++14), but the pure "access" you get to the system is unbeatable.
E.g. you need to call exactly these low level functions in exactly this order? C or C++ is all there is.
And manual memory management is a terrible way to live your life, so C++ it is. (the modern kind, the one where you never write `new` or `delete`, basically ever)
Go seems like it tries to be a systems language, but it's failing at it. The portability is just fundamentally misdesigned. +build comments based on OS name are a known antipattern, and just are neither backwards nor forwards compatible.
Even the stdlib has different function signatures depending on the OS, so you can't a portable use of select(2).
Go is great for tying together parts, though. Read some stuff from GCS, stuff it into PostgreSQL, publish a message on Cloud PubSub, and update a load balancer certificate. I sure wouldn't want to do that in C++ for a small tool.
I should learn Rust. I hear good things. But in order to replace Go it'd need great Cloud support, and that seems to be lacking. And to replace C++ I'd need to actually be able to build and run stuff, even on my Debian oldstable. Too many modern languages require you to upgrade your entire OS in order to get a build environment, and that's a showstopper for me in some installations.
If I can't run my tool in that older environment, then it's not solving my problem.
But maybe it's fine. Like I said, I should learn Rust.
To me the choice was between C# or C++, but I ultimately chose C++, because while C# is much faster to code in, when there is a problem, coding directly against the OS, I have much more control in what actually happens and in what dependencies I really have.
Edit:
I also must confess that I'm enamored with the idea of having a comparatively tiny executable without any other runtime dependencies than itself and the OS.
For build system I use meson, and cross compile the Windows targets. It works from Windows XP through Windows 10. (If you have any 32-bit version of Windows, you get the "32 bit XP" version. If you have 64 bit but it's older than Vista, you also get the "32 bit version".)
Also using it for hobby projects like a custom shell. Modern C++ is a great language and while I'm also using other languages like Rust for hobby projects I still feel the most comfortable writing C++.
Where is C++:
- the programming language
- core library
- media layer with ffmpeg
Then use new lang to build UI layer, IDE, tools and games
The shared library has few dependencies outside of LLVM so that it can be as portable as possible, and the runtime hooks are all C and only depend on c stdlib so maximum portability, even to embedded systems.
Video game stuff still frequently uses C++, and also to support consoles, handhelds, quest/etc, C++ just makes sense because it's supported EVERYWHERE (though the compiler doesn't need to run everywhere, so that's more a concern for the runtime).
We're using conan which is FANTASTIC and finally a good package manager for C++, and C++17 (will upgrade to C++19 soon, but still not quite stable/widely supported enough for my taste).
In my world, this whole "C++ is no longer a viable option" meme is just not true. We all hope that Rust or what google is working on might replace C++ but when we discuss it we're talking on the order of 10+ years.
We used it for image pipeline implementation. I can't see using any other language for that (except, maybe C). We did try some other languages, over the years, but nothing could hold a candle to C++.
Glad I'm not using it for UI stuff, though. I consider it to be an "advanced engine" tool. Not something that should be used in everyday stuff.
Also, all the performance critical stuff on my production servers is C++ with JNI or pybind wrappers.
tried Rust for a few times, finally gave up due to the learning curve and still young ecosystem, it's hard to learn multiple languages and become good with them, I will pinpoint on c++ for other new projects as it seems can do all I wanted.
C++ for the low-level machine learning (Kaldi/ONNX) & rendering (Filament) components, Dart for the service/model/view layers and Kotlin/Swift for hooking things up to native APIs.
I can't claim to be a C++ expert but I've found that working with RAII, staying away from templates and being slow to incorporate newer (>C++11) features keeps things reasonably sane. The standard library is definitely painful to use in places (streams, chrono, etc) but all things considered, I still prefer it to Rust.
The other language that gets used a lot is Python for tooling and similar.
This is to replace the original PAGES software, which was written in Fortran. M-PAGES is able to process GNSS baselines using all the new satellite systems, as opposed to only GPS.
Edit - my understanding is they chose that language for good extensibility.
Lead engineer picked the language and he’s very much an early 2000s C++ guy, for better or worse. That said, when the choice was made two years ago, Rust had almost zero adoption in our organization. It’s more popular now, but we aren’t restarting the project from scratch.
Bought some books.
- Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
- C++ Concurrency in Action
- C++ High Performance: Master the art of optimizing the functioning of your C++ code
If anyone has any recommendations would love to hear them.
A good deal of stuff where I need complicated algorithms and want performance but don’t care too much about integrating with web stacks (which is always a chore in C++).
Game Engine, Tools and Games.
I am also starting to use Zig.
Tech stack : clang, simple handmade build scripts.
At home: I work either on personal embedded-focused C++ lib, or on various embedded projects in C++, used to have some .py scripts but getting rid of them, and moving all to C++
In the end, everything is in C++ :)
Per Github it's 90% C++ and 8% C.
It's probably not ready for use yet, but give it six months or so: https://github.com/eightbrains/uitk
Salt spreader. Micros running C++ and a UI on an RPI with Qt/C++ for the controller.
Heat gun. Micros running C++.
Afib detector. Micro running C++.
Flavor dispenser for a large coffee company. Micos running C++, UI on custom Linux SOM with UI in C++ / Qt
Medical imaging device Qt / C++
-- Bjarne Stroustrup, inventor of C++
Here's a couple recent ones:
- https://github.com/celtera/avendish
- https://www.youtube.com/watch?v=fMQvsqTDm3k
- most of the stuff in https://github.com/ossia and https://github.com/jcelerier/
When I pick up new languages and I did that for a bit with Rust, I read a bit then code a bit and found https://github.com/rust-lang/rustlings very helpful. Is there an equivalent for C++? What would be the top resource to get started on modern C++? Thanks in advance.
Usually combined with some sort of visual scripting for the higher level logic
can be quite flexible once you tackle C++ intricacies.
If I were to do something that needed speed I might consider this
C++ is currently the only language, but there will be a Julia frontend. I'm using C++ because I am working with LLVM.
The core game logic is implemented as a function that gets called at 60Hz with user input and is responsible for producing the RGB buffer. Around that sits a little harness that takes care of grabbing inputs and sending the visual output to the display.
I've also written a separate version of the hosting harness for WASM & webgl. When working on the game proper it's just a faster turnaround to compile and test things in the browser. It'll also make it easy to get feedback from people since I can just point them to a URL. I already had most of this code lying around from a previous project so it didn't take much time to whip up the web frontend.
All of the code for the game logic and the two harnesses is in C++.
Not sure yet what to use for local data storage, sqlite seems like a pretty rigid solution.
I used to use C for some performance critical backend projects a while back but I explicitly avoid C++ because I don't think it is constrained enough and tends to lead to writing code that has side effects. I prefer the "simplicity" of C if I'm going to have a lower level language where I need to memory manage myself.
With that said, the projects I used to use C in are now mostly Go. It has acceptable performance for my use cases and has better memory management and easier concurrency.
One thing I struggle with is I think C++ still has some of the best libraries for certain tasks, especially around GUIs and games. But neither of those are things I work in regularly.
Algorithms that process millions of data points in parallel using multi-threading is a defining characteristic of the code. It is able to process many queries against large relational tables about 10x faster than Postgres without needing to create separate indexes. https://www.youtube.com/watch?v=OVICKCkWMZE
I do mostly games and graphical demos on a wide range of exotic and retro hardware, which always has a C compiler, but not always a compiler that supports C++. Also, i feel like i have more control over every bit and clock cycle in C than in C++, although i know it’s technically possible to use C++11 on a Commodore 64.
On projects where i can use C++ i use the following tools: CMake, Clion (IDE), Catch2 testing framework. Often ImGUI for quick debugging UIs.
I don't have the energy to resolve these issues myself. I guess at least my first version will be in c++.
I always wanted to learn C++ and never got the chance to use it for work, so I started reading the most significant books and resources suggested by [0], including learning how modern projects do things - on this, Jason Turner's template comes handy.
In the beginning it was tough, and at times it still is, however I am getting more and more familiar with the way things are done.
At first I chose Meson for "simplicity" but it took me a while to realise that Cmake is actually pretty easy as well, so I switched to Cmake and started using Conan.
My project setup is slowly converging to [1] - I couldn't just use it without having any knowledge about c++.
I am happy that someone packaged a lot of good and modern practices in such a repo. (I know they are good because the approach is quite common with other languages/technologies too).
There is way more to learn than with other languages, but it's interesting. Plus, i watched one or two videos from the creator of the language, and I like his philosophy of "freedom", which I believe is one of the main issues nowadays with c++, as most developers just want a prepackaged set of tools and APIs to develop and deliver fast, without thinking too much - c++ clearly doesn't get along with this type of developer.
The project consists of:
- C++20 with Clang - clang-format - clang-tidy - project_options with dev mode and other sanitizers on - Cmake/ninja - Conan - lots of nice things provided by the
- catch2 - qt6 - TOML for internal configuration - Sqlite3 for DB
- github/actions for CI/CD
I still haven't use Valgrind, still an amateur afterall:)
[0]: https://github.com/rigtorp/awesome-modern-cpp [1]: https://github.com/cpp-best-practices/gui_starter_template
Before praising, I'll give a bit of my programming background. Early 80's Waterloo Basic on some Commodore Vic20's and 64's, a couple years of C on the Icon but it really sucked because books and software were hard to find and expensive. My brother bought a Hyperion with an early Dos on it and it truly sucked as well for the same reasons Software and Docs were expensive and hard to find. My first real practical PC was an i386 with if I recall correctly 32MB of RAM and I had something like 40GB of hard-drive? I was lucky to get my hands on a Visual Basic and an Microsoft Windows 3.1 Platform SDK which came with the programmer's workbench a TUI IDE for C/C++/MASM with MFC Foundation classes. I was lucky to be introduced to Turbo C++ as well with OWL. Object-Oriented Assembly with TASM came out which was very cool, but masochistic. Very confusing times.
The confusion stopped because when I got hired for a coding job, I was dictated my toolset. They gave us different environments SCO UNIX, SUN OS, Windows for Workgroups(WFWG) 3.11 and some C++ tools for all of them. We built a gui that was consistent on all of them and needed to send/receive stuff. Sprinkle some SQL in there of course. Sprinkle some OOAD diagrams, UML wasn't around yet, but similar notions and diagrams were available for inspiration to communicate with the team.
Later Rational Rose for C++ and Ada was surfacing with some UML and code-generation supporting round-trip engineering. Most of the places I worked at couldn't care less to pay for these kinds of tools since they were simply exclusively priced, but IMHO the Return on Investment was there.
I was privileged enough to have participated in a project that forced me to learn Ada and Java and still required some sprinklings of C/C++/Unix and JNI. The important privilege was to use Rational Rose with a team and everybody was on-board with it. Rose was wonderful and useful to the entire team. Different coding languages in these cases helped to separate the concerns and capabilities. It also helped crystallize the number/type of arguments that should be passed through these different apis & coding languages and to make sure everybody was on same page. After this experience, I also learned to appreciate Ada's strengths. I was annoyed by the overwhelming amount of Ada language terms and the noisy documentation, but the examples were aplenty to get the job done. You had to be patient with the Ada compiler (gnat), but if you could get it to compile, odds are the binary would run and behave as expected most of the time. Most of the bugs we would surface would come from the Java side because Java was more free-style like C/C++. You could compile successfully lots of weird expressions in Java/C/C++ and run-time errors would surface that you would need to take much more time to debug the java/c/C++ for. The ada code was good.
Later on, I would share that Ada is better than java/C/C++/C# but nobody would care much about that and they would be on their merry way doing stuff in their comfort zone languages. At some point in time Ada my hammer for everything even web servers.
Here's the thing, without official credentials and talking to ada employers about ada until I'm blue in the face got me nowhere because of the lack of official credentials the doors were closed. Suffice to say my motivation to continue with Ada waned off.
Other gigs...noise here.
My coding career went idle, went bust. Low-esteem for quite a while. Went to China taught English. The kids over there treated me like a superstar. On my time off, I would play with linux, python, c++, and golang. After 3 years, I returned to Canada, and forced myself to try to market myself as a coder and linux afficionado again. I got a few nibbles here and there. other gigs...noise here...
I finally got some work doing a web site and doing an optical storage appliance using golang and c++ where arose in Linux and Windows. Those gigs dried up.
Finally I was given a gig doing tape storage and I had the freedom to write helper tools in whatever language I deemed best. I chose golang at first, because it could do stuff in parallel easier than anything else I've experienced in other languages. Golang channels are very sweet. I discovered rust in 2017. It had easy parallelism and channels as well, but faster and safer to use. After 3 months attempting to learn and apply rust to re-write the existing golang tools, I had enough confidence to say I could complete the rewrite and gain some performance and reliability advantages from that migration. Contrary to the popular belief that golang projects build faster than rust, I was able to integrate and build all my rust projects in a rust workspace and it built faster(2'ish minutes) than the current golang build (30+ minutes duration). It's true if I were to build all my rust projects individually as separate projects, it would have taken a touch more than 30+ minutes but that is no longer the case with the "rust workspace" paradigm. To help frame this, if I were to re-write these tools in c++, I would possibly get buggier runtimes and the build time would be roughly the equivalent to the rust workspace build time. The runtime performance of an equivalent C++ would be similar to the rust yes, but I would be wasting more time debugging c++ runtime issues that wouldn't have a chance to surface in rust because of all the rust compiler checks and memory ownership it does.
So with all that said and done, NO JOKE, Rust is truly a better tool than C++ to build anything with. It has enough infrastructure to get gui's done with gtk4 or qt on windows, macos and linux on x86_64 or arm64 hardware. Riscv64 support is already there which speaks volumes about rust. If I were to build a gui for riscv64, I wouldn't hesitate to use rust. Sure more painful at compile-time, but it saves you immense time having to debug run-time errors including the worst ones, the intermittent ones that you have to iron out in golang, C++, C#, and java.
Rust is not just trendy, it's the real thing. It's like Ada, but only better. Ada lovers don't flame me. I have my reasons for hating Ada and Ada employers. They're stuck up on credentials and security clearances. I lucked out finding an understanding employer that appreciates my kitchen sink of IT/Tech/Software Developer skills, regardless of my lack of credentials and they benefited from them. I wish everyone here health, happiness and prosperity. I truly believe you'll find it sooner if you get out of your comfort zone and learn and use Rust and linux wherever you can.
Cheers :)
Other libraries used:
* MuPDF for PDF rendering
* Qt5 for UI
* sqlite for database
I also recently added a plugin system which is language neutral, but I wrote a python wrapper around it (see and example here: https://sioyek.info/#extensible).