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++).
An arbitrary C++ project cannot most likely be compiled to WebAssembly out of the box. Emscripten needs to be a supported compile target from day one, not an afterthought. Talking from experience.
I am using C++ for sioyek which is a PDF reader designed for reading research papers and textbooks: https://sioyek.info/
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).
This is the exact kind of tool I would have loved to have had during my math undergrad. And as a fellow developer, I applaud you for taking on the challenge of working with PDFs, especially in non-trivial ways, on arbitrary PDFs no-less. Anytime a client/employer mentions anything involving programmatic PDF manipulation/access, I try my best to convince them it's probably not a good idea, but if I have to, I do a little prayer that I can find a straightforward solution with an existing library - otherwise, lower level PDF munging quickly ventures into a flavor of tech-cowboy hell.
Starting a new side project, no platform-specific functionality needed. Tried out a few relatively "new" languages (more like new to me) and experienced severe frustration from bugs and spotty documentation, lack of proper IDE/debugger support.
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!
Swift/XCode (guess I had unrealistically high expectations, the whole experience was just downright infuriating), Seed 7 (somewhat exotic, I liked it but had some build problems on Mac), Groovy, FreePascal/Lazarus,
D+VScode (almost), Python+VSCode. Embarrassing perhaps, but I ended up doing my prototype in PHP, debugging on my Mac was not fun but its awesome documentation kept on saving the day.
I haven't, it was on my list but I eventually ran out of time an patience. Definitely planning to try it out at some point as I keep on reading great things about it.
FWIW, CMake and Conan (or vcpkg) together are easing the pain of using C++ as a language for new projects -- lots of libraries can easily be added to the project like it's done in newer toolchains (cargo for rust, pip for python, pub for dart, etc)
Quant trading system/framework. Other languages - scripting in bash, awk, plotting in gnuplot, optionally python matplotlib, data fetching in sql, kdb.
I'm using C++ for my game engine and games I'm making with it. The biggest pain is the toolchain and build process. With that said, I'm happy with my (modern) CMake + Conan + Ninja setup which took some time to create, but it's good and works for my usage.
trading systems. things that might be a pain to do in C++ and are not performance critical is offloaded to python or bash. usually no direct calls to DB in C++, preload data ahead of time, or SIGUSR1 to read updated data if needed
I've started using C++ for the REST backend for a mobile app recently.
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.
Performance wasn't the only reason for switching, but doing sqlite through dart is quite slow even using the batch API due to the copying to the isolate, and in any case I'd be limited to a single thread using dart which I expect would limit me later on.
At that time, I hadn't invested much time into the dart version, but it was looking unlikely that I'd be able to scale it as well as I wanted on the server-side, and the little I gained in development time from shared code by using dart didn't feel significant enough to warrant the performance hit.
Sure, but my dart implementation was much slower to start than I'd like for iterative development and also was consuming a chunk of memory.
My current version (admittedly still very early in development) starts in under a second and occupies 300MB after doing some unrepresentatively large transfers (200k records when the application will be doing more like 200 at once). The downside is that compile times are a bit higher.
I could have used something else, but like I said, I'm very familiar with C++ as it's what I've used day-in, day-out for the the last 15 years.
restinio is a pretty good library - the code I'm writing in C++ isn't much more verbose than the flutter code, in fact in some places it's got less boilerplate as it's heavily templated, so e.g. json_dto just requires a single definition to support JSON serialisation and deserialisation.
> "Don't know your use case, but C++ for a REST api seems extreme overkill"
It used to be the other way around: spinning up a VM for handling a simple HTTP request, wasting many megabytes of storage, memory and burning needless CPU cycles on bloated abstractions along the way? That used to be the very definition of "overkill".
Unless you want to serve thousands of requests per second on the toaster you just installed NetBSD on. In that case a well written C++ socket multiplexer is a good choice.
Remember that network latency only affects, well, latency. Throughput is another matter.
> Don't know your use case, but C++ for a REST api seems extreme overkill. Any performance benefits would most likely be nullified by network latency
It seems you're mistakenly confusing the time a request takes to be fulfilled with performance.
In the server, performance means throughput. If means nothing if a task handler stays ages waiting for IO. What matters is that once a task is ready to run, the code that needs to run is as lean as you'd like.
This means you can handle more requests with less hardware.
I have no idea how we reached a time when people think it's a good idea to download over 100MB worth of dependencies just to have a service that can handle a HTTP request, and multicore computers packed to the rim with RAM just to be able to handle a few tens of HTTP requests per second.
Latency can still matter on servers, it’s just that the trade off is less obvious given that requests may spend time in a queue waiting to be serviced, and the depth of that queue will depend on throughput more than latency.
I am using C++ for processing and currently Qt for GUI (only the CEF component of it, thinking about changing it to native WebView2). CMake for building, nlohmann for json. Still need a connection with server APIs (auth, data sync).
Not sure yet what to use for local data storage, sqlite seems like a pretty rigid solution.
I use C++ for audio processing software, although I prefer doing it in normal C because C++ is too messy and abstracted. That being said, C is a bit too messy and abstracted too, with too much "taken care of" by the compiler.
The new M-PAGES software by NGS is written in C++, with a bit of python tooling as well.
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.
Me. On every project that I need to compile for AIX. Not my favorite language by far, but it's pretty nearly the best choice on the platform, if you want cross platform code and don't want to fall into Java.
Go (AKA Golang) has been famous for its portability. The docs seem to indicate Go has had AIX support since version 1.12 [0]. I haven't used it personally, though, so I don't know how good it is.
AIX is a pretty decent Unix, all things considered. It had a ton of proprietary configuration, but "smit" made it super easy to administer. I was briefly a sysadmin of an HP-UX environment, and it was not fun.
We are using c++ mainly because Qt/QML exists. I guess if a Rust gui toolkit exists that is comparable to Qt/QML (looking at you https://slint-ui.com/), then future project would have to be re-evaluated.
My plan is to use Tauri in Rust likely with just the view in TypeScript (will probably move state into Rust). No, it isn't Qt/QML and HTML/JS/CSS aren't as snappy or memory efficient, but with work they can be made reasonable and bonus is styling is endless.
I am not using it, but I ran a C++ shop for 25 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.
It was mostly desktop (Mac/Win). Towards the end, we did some embedded stuff.
Our code could have been used for embedded, in some cases, though.
The deal was that C++ is fast. Optimization was a big deal. We had some fairly hairy algorithms. Even our deBayering (demosaic) stuff was crazy complex. C++ helped us to abstract the complexity, while enjoying some serious performance.
198 comments
[ 0.21 ms ] story [ 211 ms ] threadA 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++).
Why so? Using Emscripten You can always compile C++/C to WebAssembly (for execution in web browsers).
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).
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!
Laravel DB migrations are very convenient, and very DB agnostic.
What are your favorite features?
Game Engine, Tools and Games.
I am also starting to use Zig.
Tech stack : clang, simple handmade build scripts.
Also, all the performance critical stuff on my production servers is C++ with JNI or pybind wrappers.
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.
At that time, I hadn't invested much time into the dart version, but it was looking unlikely that I'd be able to scale it as well as I wanted on the server-side, and the little I gained in development time from shared code by using dart didn't feel significant enough to warrant the performance hit.
My current version (admittedly still very early in development) starts in under a second and occupies 300MB after doing some unrepresentatively large transfers (200k records when the application will be doing more like 200 at once). The downside is that compile times are a bit higher.
I could have used something else, but like I said, I'm very familiar with C++ as it's what I've used day-in, day-out for the the last 15 years.
restinio is a pretty good library - the code I'm writing in C++ isn't much more verbose than the flutter code, in fact in some places it's got less boilerplate as it's heavily templated, so e.g. json_dto just requires a single definition to support JSON serialisation and deserialisation.
It used to be the other way around: spinning up a VM for handling a simple HTTP request, wasting many megabytes of storage, memory and burning needless CPU cycles on bloated abstractions along the way? That used to be the very definition of "overkill".
Remember that network latency only affects, well, latency. Throughput is another matter.
It seems you're mistakenly confusing the time a request takes to be fulfilled with performance.
In the server, performance means throughput. If means nothing if a task handler stays ages waiting for IO. What matters is that once a task is ready to run, the code that needs to run is as lean as you'd like.
This means you can handle more requests with less hardware.
I have no idea how we reached a time when people think it's a good idea to download over 100MB worth of dependencies just to have a service that can handle a HTTP request, and multicore computers packed to the rim with RAM just to be able to handle a few tens of HTTP requests per second.
The live-replication work has been abandoned and the author is working on this instead: https://github.com/superfly/litefs
https://github.com/0xf00ff00f/windmap
Uses CMake, Qt6, CUDA and OpenGL. Here's a short video showing how it currently looks like:
https://twitter.com/0xf00ff00f/status/1557920480564334594
Not sure yet what to use for local data storage, sqlite seems like a pretty rigid solution.
can be quite flexible once you tackle C++ intricacies.
If I were to do something that needed speed I might consider this
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.
[0] https://go.dev/blog/ports
I'm hoping mrustc or the gcc frontend become viable too.
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.
Can you remind me: Was your end target platform embedded or desktop? If embedded, I cannot see any other way except C/C++.
Our code could have been used for embedded, in some cases, though.
The deal was that C++ is fast. Optimization was a big deal. We had some fairly hairy algorithms. Even our deBayering (demosaic) stuff was crazy complex. C++ helped us to abstract the complexity, while enjoying some serious performance.