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.
I almost exclusively use C++ for my projects. Especially modern C++. When it makes sense(especially for dev tools), I use Python since for those I'm not so worried about distribution and long-term robustness.
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:
I know this is a bit of a loaded question in the C/C++ world. But really depends on the project. Most cases it seems I go with CMake just because that's what everybody seems to use most of the time. But I do long for the day that modules get fully implemented in all compilers and we get some kind of standardized solution that's akin to Cargo/npm/maven... One day. I try my best to keep things simple.
I ended up adopting vcpkg because I started using restinio and the examples all used vcpkg to fetch their dependencies.
It was pretty painless to set up on multiple Linux machines, but both times I've tried on Windows, it's been incredibly painful where I've had to walk through each dependency manually, installing each package manually specifying x64-windows in the triplet, and having different CMake errors on each machine.
This surprised me as vcpkg is actually a Microsoft invention, and seems to be widely praised for reducing configuration woes.
I got things set up and working eventually, at which point I could forget about it, but I definitely plan to get rid of CMake from my build process when I have some time.
C++ is still often the best or only way to write performant code on embedded platforms, while having a rich library ecosystem available. Hence, my first choice for a new embedded project is almost always C++.
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.
Came here to write pretty much exactly what you said.
I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun.
But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature.
Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.
> Modern C++ is getting a little better all the time.
Honestly, this is the reason I haven't moved anything to Rust, despite seriously considering it in the past. I would ditch C++03 in a heartbeat, but C++14 and beyond are very usable.
C++ could certainly be better - I'm hopeful about Carbon - but it's good enough and improving fast enough that if you're already a C++ expert, I think you're pretty happy.
Constexpr all the things is kind of a super-power of C++. Zig has an even more powerful comptime feature, but that's an aside.
(Bonus points: Declare a static constexpr value in a compilation unit... and use it somewhere at runtime to get the moral equivalent of consteval for the values you care about.)
Compile time typing is awesome (in Nim its `{.compileTime.}`). Combine it with compile time "duck typing" and you can write some powerful but still simple code. I hope the style becomes more common!
Last time I looked, RTIC was the most complete RTOS implementation, but it lacked some functionality related to timeout actions in the network stack that I needed (and was provided by FreeRTOS).
Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
Tock is probably closer to a true RTOS in the sense that tasks have stacks. Maybe also hubris. RTIC, embassy, and probably a few others do ISR preemptive task scheduling and synchronization. This is super cool and probably enough for most people. Until you need time slicing probably. Threads have pros and cons like anything else, the biggest cons tend to be…
Stack sizing is hard.
Stack swapping kills caches.
Stack overflows can be very infrequent and hard to debug.
Thread priority doesnt always do what you think.
Even with threads not every RTOS does time slicing.
So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.
Nah, the RTOS side in Rust is still in its infancy. Hubris is pretty cool but really only supports two families of chips (and requires an MPU iirc).
Rust's ecosystem still struggles with no_std, so the majority of crates won't work. Worse (for me) is that using Rust with arrays (not heap allocated vec's) is still a pain.
You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it.
Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity).
Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper
The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.
It's smallish, but there's an embedded channel on Nim's discord thats active as well as the forums. Checkout https://github.com/embeddednim/ too, I've been working to get more projects there. Someone recently added a wrapper for the rpi pico's I've wanted to try :)
Real question: You specifically wrote <<C++ is still often the best or only way to write performant code on embedded platforms>>. To be clear, I am not an embedded systems programmer (nor an HN troll!): Does C also qualify? I heard that sometimes embedded engineers are forced to choose C where the C++ compiler is poor or does not exist. Can you please also share your platform(s) and compiler(s)? I am curious to learn more from an industry insider!
Maybe 10-15 years ago, C was the best option for some microprocessors. These days, good C++ support is pretty universal.
There is always a compiler available from the manufacturer, and often a gcc target.
The AVR family of processors, for example, are supported by the manufacturer's IAR compiler, the ImageCraft ICCAVR compiler, AVR-GCC and several others. IAR produces the fastest / most compact code in many scenarios, but costs $thousands. The ICCAVR compiler and IDE is much cheaper and preferred by many developers. Personally, I tend to avoid pushing the limits of a processor, so the GCC toolchain is most often good enough.
Context: I write rust professionally I have no plan of coming back to cpp.
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.
> There are many many libraries available in rust due to the amazing dependency system. But the average quality is quite poor.
The main problem with Rust is that it is thread safe, and that makes code and libraries very hard to write. Thread safety is a lot stricter than memory safety, and since it is easy to write single threaded memory safe modern C++ it gets hard to shift to Rust.
But if you want thread safety or mostly do data processing scripts then Rust is far superior, just that for many applications enforced thread safety is an anti feature since it makes your code way too hard to work with. If they could make ergonomic thread safe libraries for everything then great, but I really doubt it will ever happen as it is very hard to do.
This is a common misconception. Not all rust code is thread safe. You can use and implement types like Rc which are !sync. What rust enforces by default is concurrency safety. For instance iterator invalidation is something which can occur on a single thread, but rust prevents it from occurring. Of course rust can enforce thread safety as well, but you're allowed to write code which is not thread safe. Contrast this with c++ where it's hard to know the context in which your code will be run so you may end up preemptively making it thread safe, like in the case of std::shared_ptr.
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.
> "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".
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.
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.
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.
This year I wrote the latest compiler for jank[1] to be in C++. Originally, this new version was being written in Rust, which I prefer, but I ran into a serious limitation. In the C++ world, we have Cling[2], so I can easily JIT compile arbitrary C++ code and link it to my running process. This is exactly what I need for jank's REPL and JIT capabilities. In the Rust world, such a thing doesn't exist and trying to use rustc as a crate is not well supported at all, all on top of the ABI instability issues.
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.
I'm using C++ for most of my projects, because I like it. It's also what I do for a living. The latest new open source project I initiated is a dns server, nsblast, using rocksdb for storage. https://github.com/jgaa/nsblast
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".
Just about any project you do in Unreal is a C++ project and Unreal is used all over the place - in games but also in industrial design and architecture for demos and visualization.
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.
All our infrastructure technology, services, and almost all “applications” we have built are written in C++. That’s millions of lines of code and span everything from IR, distributed storage and computation, ads serving, relational and columnar datastores, caching and much more.
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.
Above, you wrote <<velocity>>. Most people would say that C++ has lower velocity than other higher order languages, like C#, Java, Python, Ruby, etc. You also include the term <<experience>> which is a curious combination. In my professional experience, language "experience" dominates most discussions about what langauge to use for a new project. After all, programmers are humans who have biases from their (programming) langauge experience. (Zero trolling on the last sentence!)
Velocity is about familiarity, about expressiveness, about being able to quickly translating what you want to accomplish to code. It’s also about, for me anyway, not being constrained by inherent limits of the language or runtimes. Like I said, checks all the boxes.
As for experience, I have been writing C since the very early nineties and moved on to c++ soon thereafter.
Again, all that is, for the most part anyway, not specific to this language.
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!
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.
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'm using C++ for a minecraft clone that I've been tinkering on for the past year[0]. I also plan on using embedded lua for scripting, and I'm using RML UI for game HUDs, ImGui for development tools, and OpenGL for graphics. I use premake for my build system but plan on switching to CMake.
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 like premake, but almost every library I try to use already uses CMake or make. It just becomes a hassle translating their CMake scripts into premake or manually including the appropriate source code in the build.
Yeah, it's one of my two main languages for new projects.
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.
Learn Rust. Ignore the foamers who claim Rust is a gift from the divine. Rust is a harsh mistress, however, as it really forces you think about how your program uses memory. That's the "learning curve" everyone talks about, but if you're already steeped in C/C++ and understand how to use memory in those languages, the curve isn't so bad.
I'm doing a (free) backup system (just a hobby, won't be big and professional like dropbox) for PC, Mac and Linux. This has been brewing since april, and is starting to get ready.
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".)
I assume this is a command-line application? c++ does have a cross-platform GUI problem, unless you pay for the Qt license that is, which is itself a heavy ecosystem to master.
No, it's a GUI application. There are ways of making the GUI parts cross platform, like webview and such. But the GUI parts in this application are native to the OS. "Only" the core functionality is shared between platforms.
This is also something I have been battling with in the past. All the cross GUI platforms have their quirks and problems and varying OS dependencies you are then married to. Since this is my own personal project, I decided cut the knot differently and just do the GUI parts native.
So far, I have found it be incredibly liberating. Instead of trying to instinctively shoe-horn functionality into something that will fit on all platforms, the code itself becomes much clearer when all the really "abstract" or "logic" code is completely separate from the platform code.
This is of course best practice anyway, but the decision to split this way made separation incredibly obvious. When the "logic" parts code cannot communicate with OS resources, you aren't tempted to put stuff where it doesn't belong.
Very interesting. May I ask was what your approach is wrt the Mac GUI: are you going to use XCode's GUI builder or rather build a fully programmatic GUI (that is creating View Controllers, etc. by hand in Objective-C++ )?
Have no direct experience myself but I intuitively find the latter approach more appealing. I have seen examples of it here and there.
then i will have to know how to do GUI natively on mac, windows and gtk/linux, not easy to do them all.
for GUI(not gaming GUI like imgui, I just do normal GUI with widgets) cross platform I "shamelessly" do electron, for non-GUI I'm all the way with c++.
Scientific simulations. Meson as the build system, vcpkg as package manager.
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++.
If your memories of C++ are mostly wrangling null-terminated (you hope) char** or writing impenetrable iterator types, things have gotten a lot better!
I am (new as in 3-4 years old) - a shared library compiler for a text language, CLI for easy access to compiler and a visual editor for a graph/node-based representation of the text language, used for audio programming primarily in games - built on LLVM (For the compiler) and JUCE (for the graphics).
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.
If C++ is all you know you really should diversify a bit, learn something very different, like a lisp or Haskell. You probably won't come away doing everything in that new language, but it will certainly expand your way of looking at things.
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.
I recently decided to leave go and back to c++ for a microservice project, with the new coroutine and async in modern c++, I failed to see anything Go can that c++ can not do, plus the latter has no GC and is just more performant. I will stick to c++ for other future projects.
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.
Quant trading system/framework. Other languages - scripting in bash, awk, plotting in gnuplot, optionally python matplotlib, data fetching in sql, kdb.
In terms of LoC, I'm probably at 25% C++, 65% Dart (Flutter) and 10% Kotlin/Swift. Probably not enough to qualify as "main language", but enough that I'm writing it multiple times a week.
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.
Should have been clearer - Rust wins when it comes to the standard library, but I dislike the syntax and prefer C++ the language.
I think the relative ubiquity of C makes transitioning to C++ a lot easier. If you wiped my memory of the last 20 years of programming and forced me to learn both C++ and Rust from scratch, maybe I'd think differently.
IMO the C++11 and later features can make it easier to use, less error-prone, and slightly more like Rust. Avoiding them entirely is probably a mistake.
I would concur, having used c++ as my daily driver since before the 98 standard, I prefer the new way to the old on mostly everything. Clang-tidy has modernization checks to help with stuff like that. I don't go trying to use the new features on purpose, but when I do something that has a new way, I do it. Pass by value, move don't copy. Auto wherever I can, but decorate the type on the rhs.
Oh, I definitely don't avoid them entirely (I'm very liberal when it comes to unique_ptr in particular). It's more about not jumping headfirst into new features that I don't fully grok (or more importantly, when I don't really understand why you might prefer new feature X over old feature Y).
strongly agree. c++ without shared_ptr and unique_ptr is not a language i want to use. although the primary reason i like c++ is templates, so the grandparent poster and i would probably have nearly opposite ideas of what the good subset of c++ is.
All of the recent high-scale data infrastructure projects I've been involved in are written in C++17 or C++20. Mostly fast-twitch analytical database engines and related data processing systems. This is still the go-to language for that kind of systems software, no other programming language is as feature-rich and expressive for that purpose.
The other language that gets used a lot is Python for tooling and similar.
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.
We’re using C++ for a new blob storage service at work. 95% C++; build is configured with buck (bazel) and there is a small amount of Python and shell scripting.
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.
effective c++ is a bit out of date but still very good. i read it while learning c++ 'properly' last year and found it very helpful, but it helps to have some knowledge of modern c++ to know what is still relevant. there isn't much overlap with effective modern c++.
I even found the other assortment of videos super interesting when I was first learning about C++. I found a lot of the best ones by setting the view count to 'most watched'.
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.
My last big project Kalendar (https://invent.kde.org/pim/kalendar) is written in C++, mostly because i could reuse tons of library for all the low level spec implementation and because QML is a great UI language.
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.
Working on robotics apps in C++ at work (with some .py glue)
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++
Exactly, and the Rust version will "mysteriously" turn out to have fewer security vulnerabilities, scale beyond 1 CPU core, and have a nicer CLI interface :-)
No, the point is that Rust makes it much easier to add parallelism than C++:
1) Global state is discouraged by the Rust compiler: You have to explicitly put code which modifies global state inside unsafe blocks, to alert you that you have to manually ensure thread-safety for that state. gcc, for example, is infamously reliant on global state, to the point where it's impossible to have two targets within the same binary.
2) The compiler prevents you from sharing non-thread-safe data structures across thread boundaries (again, unless you explicitly use unsafe blocks). As a result, if the compiler accepts your code, you can be reasonably sure that the third-party library you're using to compress your data in parallel is also thread-safe and doesn't trigger concurrency bugs. Anecdote: Recently I wanted to use LLVM's new JIT infrastructure – which was re-designed with the explicit goal of being thread-safe! It worked fine when single-threaded, but resulted in weird errors when running in two threads in parallel. It turned out that the optimization passes used by the JIT weren't thread-safe after all... Of course, this wasn't documented anywhere. I guess I could count myself lucky that I discovered this problem so quickly, instead of hard-to-debug errors in production. Rust, in contrast, would've rejected that program outright.
Not my project, though I'm a user of it and a big fan, is Typesense (https://github.com/typesense/typesense), an extremely fast and lightweight search engine.
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)
I've been writing a cross-platform UI toolkit, currently macOS, Windows, and Linux. Eventually I'd like to compile for wasm/Canvas, android, and iOS. C++ was sort of designed for this kind of thing, it is performant, and it interfaces with the OS well. Eventually I'd like to have at least Python, Swift, and Rust bindings, because I really like using Swift, but none of the UI parts are available outside macOS.
What's it like using C++ for something like an afib detector? I imagine you can't use much of the STL, _or_ you toss in your own custom allocators to everything.
There is nothing wrong with using the STL in a medical device. Its certainly preferable to worrying about malloc and free. If you can get away with it stick with std::array for buffers. If you need resizable buffers you can create std::vectors with reserved capacity.
All the algorithm stuff in the STL is nice to use. You have do thorough testing anyhow, its better to use something that has a lot of eyes on it like the STL vs rolling your own.
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.
I am a developer who has never worked on C++ but want to get into it full time, I did C in college, Java for the first few years in my career then Python and now exclusively Go.
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.
Several low level embedded C++ projects here, but most of our new projects are in Rust. It's becoming increasingly hard to justify using C++, despite how much it has improved over the years.
I'm working on loop modeling and optimization software in C++:
https://github.com/JuliaSIMD/LoopModels/
This project was started in November of last year, and is still undergoing rapid development.
C++ is currently the only language, but there will be a Julia frontend.
I'm using C++ because I am working with LLVM.
I just recently started on a new project to get more into hardware. It's a version of Tetris that runs on an RP2040-based board, with a 32x64 RGB led matrix as display.
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++.
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.
This doesn't answer your question. I don't have an answer to your question. But I thought some people may find it interesting why I don't have an answer:
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.
Your last paragraph: I agree with C++ w/ GUIs if you need crazy performance -- oil and gas exploration, medical imaging, etc. If your user is internal / big-corpo, then Java Swing or C#/XAML is totally underrated and boosts developer productivity by many-X. Ugly UI is fine in these cases. I know this from experience. Have you used any of these and what is your experience?
I've been at it for 20 years and I've tried a TON of stuff.
.NET is a perfectly reasonable -- dare I say enjoyable -- way to go if your systems are already configured to support it and you control the hardware you are running on.
The .NET toolchain for compiling and installing .NET apps if you're not already in the Windows ecosystem was -- last time I tried, which admittedly was a while ago -- very clunky compared to C/C++ tooling.
Qt is very good (but VERY expensive if you're not Open Source) for C/C++ and I've used GTK for Linux.
Java is pretty good at GUI but then you're taking on Java's other quircks / bloat. similar to .NET but worse.
I've also tried Flutter and Electron. Both have their pros and cons. But writing the low-level code in something like Go, compiling to a shared library, and linking it with Flutter is a workflow I somewhat like for desktop. That's what I'm doing for some of my newer apps.
But the reason I left that comment is my experience with C/C++ in GUI development has been the most positive so far (usually using Qt). C/C++ have just been around so ridiculously long and had so many tools written for them. But take it with a huge grain of salt since I'm in an industry where more times than not the primary GUI is in a web browser so I don't deal with non-browser GUIs every day.
This is a great reply. Thank you for the interesting feedback about a huge number of GUI toolkits. I /thought/ I was experienced with GUI frameworks until I read this post!
I also have a "soft spot" (personal preference) for Qt. Part of that is C++, part of that is small company "makes it big". Their documentation is absolutely first class. They only need to add more screenshots to improve the docs. (Facepalm... really, I should do that myself via PRs on their open source repo!) They should also allow people to submit sample code to demo each class -- or do it themselves. Yes, I know it is a huge burden, but it would serious lower the barrier for entry. So much of enterprise GUI programming is write sample code, inspect GUI, repeat. Modern GUIs are so incredibly complex that nothing can replace a set of tiny demos you can run and test / try different GUI features.
My Didgets project https://didgets.com/ is written entirely in C++. It is a general-purpose data management system where performance is one of its key features.
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'm building https://codeperfect95.com in C++, but it's more like C with C++ conveniences. I use instance methods, some weird template/con/destructor magic macros, auto, lambdas. Besides that it's pretty much all C. I use normal structs with all public fields, I never use the class keyword. Basically the Handmade Hero/Jonathan Blow style of programming. I'm pretty convinced that a more ergonomic C (which I use the C++ conveniences for) would pretty much be the perfect language.
I primarily use C, but C++ when the platform/compiler supports it.
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.
If started last year counts as new then I am using it for work aiming at low latency processing of data so seems a good fit, but to be honest it's my default language choice as well. The tech stack also has a number of typescript services and python for tooling, there is a service in golang too but it's a minor part.
I work for a Fortune 500 on a pretty large app, and we use C++ as the core language for all the platforms we support with the UI layer being written in whatever makes sense (Swift -> iOS/Mac, Kotlin -> Android) Its not new new but its been this way for about 5 years now.
we use it for redpanda https://github.com/redpanda-data/redpanda - other langs are go for k8s integration, python (dev prod tooling), ... js for ui that's mostly it.
I'm currently considering c++ for a terminal emulator project. I explored rust first, but some crucial libraries don't have rust port or have a rust port, but with bugs.
I don't have the energy to resolve these issues myself. I guess at least my first version will be in c++.
The company I work for use C++ for pretty much everything that isn’t web front end. We start new projects in C++ all the time. Recent examples are real-time disruption management for large airlines/rail companies (pairing/rostering).
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.
I started a project last year that is primarily written in c++. Its a database and web platform. C++ is the primary language, but a few things are written in go.
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 started a few months ago a personal home finance manager which includes other nice things - in Flutter (!!!). Then I decided to switch to Python and Qt because Flutter for desktop is still not a thing, and finally to c++ and qt6, because on my Mac a simple app took a lot of time to boot (> 5 seconds) and an idle window, not hello world, was using 70MB of ram. Blame it on pyinstaller or whatever other reason, well, it's then that I decided that for my own hobby project without (paid) deadlines I don't have to follow trends like Electron or easier alternatives like PySide just to "deliver something". I want to provide a low-memory low-cpu usage alternative and possibly something I can also install on mobile as well.
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:)
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.
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).