C sucks to write and take care of memory, but it’s nice for super efficient code for use on smart watches. Samsung ditched it (tizen- native apps written in C) in favor of wearOS (java?), and their battery life is now less than half what it was.
I haven’t used it in a while, so I don’t remember off the top of my head. I guess the main thing is the syntax is much more natural than C-likes. It can be wordy but the flip side is that it’s easier to read and decipher.
I don’t really think it has a future though. It was released in the 80s and suffers the same constraints from backwards compatibility as any other old language. Also it was intended to run on everything, so they limited the character set, which resulta in round brackets being the only brackets there are, which can lead to ambiguous code where for example you’re not sure if you’re accessing an array or calling a function that has the same name.
I really want a safe language that has actual nice syntax instead of some gibberish with lots of symbols, and Ada is the closest I’ve found, but she’s old and forgotten now.
WearOS is based on Android, which uses Android Runtime (ART) as the application runtime. ART uses Java (or any other JVM-compatible language, such as Kotlin) as the development language, but compiles the app to native code when it’s installed on a client device.
I hate writing code in either language. But at least what C has going for it is that it’s waaaay simpler than C++. Simple can be a really good thing. Sure, all those cool features can save you time, but they can also be gotchas that will cause bugs.
Though it is a balancing act. Too simple and you’ll make mistakes due to how much you have to repeat yourself or using unsafe equivalents (like using preprocessor directives to mimic features that C++ natively supports).
C++20 (or even C++23 if you can find a compiler that supports it) is pretty great if you use smart pointers and concepts rather than malloc and raw templates. This is especially so if you enable all the useful warnings you can find and use a good IDE.
Sadly, most C++ software out there was written in the 2000s and needs to be compatible with the original author’s VAX machine running Linux 2.3, so using modern compilers often becomes a challenge.
Coming from other object oriented languages, C++ does have some weird quirks (like the way it deals with default initialisers) but none of that is impossible to learn. Sadly, it’s bogged down by decades of old, shitty C++ that it needs to support
I suppose you could use good linting tools to ban raw pointers and enforce move()s, but honestly, I would start any new C++ project in Rust instead. Rust has its issues (especially with C++ interop), but until Carbon is ready for production use, I think it’s the best way to handle C++.
It’s the amount of legacy it’s carrying on that drives me crazy. Many of the implicit default implementations are confusing. That’s where all these “rule of 3”, “rule of 7”, “rule of whatever” come from. The way arguments are passed into functions is another issue. From the call-side you (sometimes) cannot tell if you’ll end up with a moved value or a dangling reference. The compiler will not stop you from using it. Even if the compiler has something to tell you, it’ll do it on the most cryptic way possible. I’m grateful we have C++, it paid lots of my bills. But it’s also a pain in the ass.
The most recent C++ thing I worked on (not that recent, like 5 years or so ago) was a fairly new project and the people working on it were really passionate about C++. But it was C++ code that ran as a Python library and was using the official Python C bindings. Not sure why we didn’t use one of the unofficial C++ libraries, but the usage of that C library (and such a fundamental one) held things back. We wrote was was modern C++ (at the time), but big chunks would be a completely different style.
I hate fighting its compiler and having to jump through hoops to get things done that’d be simple in Python.
If I’m gonna use a system programming language, I pick Rust. At least Rust provides clearer compiler errors, a package manager, a decent plugin ecosystem, and memory safety. Its runtime errors are a lot easier to decipher than the infamous “Segmentation fault (core dumped)”.
Don’t overestimate Rust, I’ve dealt with plenty of segfaults using it. Hell, I’ve had a situation where the Rust compiler generated some kind of instruction that wasn’t compatible with my CPU, that sure was fun to debug!
Rust has issues with interoperability with system libraries. It solves this (sort of) through static linking, but static linking is why we’re still receiving daily updates for programs that open WebP files over a week since the library has been fixed on every single platform. Plus, there’s no good way to make a Rust UI that doesn’t look like it came out of a video game. Then there’s the whole async deal, which is great until you need to send anything more complex than an integer between threads.
C++ isn’t exactly resistant to segfaults, but with C++11 things have become orders of magnitude better. C++ versions up to C++23 have improved things even more. If only people actually used those features…
I think a good C++ dev using modern tooling can probably write code that’s just as stable as and even more compatible than Rust code, but many programmers are stuck in their old ways, or on old compilers, or think they don’t need Valgrind because they’re rockstars.
Take a look at SerenityOS if you haven’t already. It’s an OS designed from the ground up, written in modern C++ (as in, the standard build script will compile a compiler because most distros don’t have compilers modern enough to run it). It includes everything from a kernel to a web browser and a Javascript engine. That project kind of redeemed C++ in my eyes.
I think your best bet is a good linter in combination with a CI pipeline that treats all linter warnings as errors. Compilers generally don’t disallow old features.
Last time I set up such a system was for a course several years ago, I don’t know what linters are popular these days. Flint used to be pretty good but it’s no longer maintained. Back then I set up a combination of cppcheck, clang with almost every optional warning, and clang-tidy for formatting. clang-analyze and cppcheck will compliment each other nicely but you do need to play around with their configuration to make informed decisions about conflicting advice every now and then.
Microsoft’s compiler does have warnings about certain risky uses of raw pointers, so using MSVC may be a good idea for safe programming until clang and g++ catch up. On the other hand, MSVC++ is behind on certain other C++ features, so you’ll have to weigh your options here.
There isn’t much documentation I can find on the topic of setting up a linter to enforce modern memory management. Most people asking for information about it seem to get responses from C++ experts telling them raw pointers are fine for and that you shouldn’t be scared of them, but I disagree.
Sadly, no tooling I know of has sufficient detection of pointer footguns (such as smart pointers made out of smart pointers leading to double frees).
Come on. C++ isn’t thaaat bad. It’s actually kind of nice to use coming from C.
I’m reading this and all I can think is “yeah, I too would rather lose a limb than let a necrotic infection spread.”
C sucks to write and take care of memory, but it’s nice for super efficient code for use on smart watches. Samsung ditched it (tizen- native apps written in C) in favor of wearOS (java?), and their battery life is now less than half what it was.
Ruuuuuuust
All this talk of Rust I’m seeing makes me so sad Ada was never given a fair chance.
First time I’m hearing about it. Any fun gimmicks?
I haven’t used it in a while, so I don’t remember off the top of my head. I guess the main thing is the syntax is much more natural than C-likes. It can be wordy but the flip side is that it’s easier to read and decipher.
I don’t really think it has a future though. It was released in the 80s and suffers the same constraints from backwards compatibility as any other old language. Also it was intended to run on everything, so they limited the character set, which resulta in round brackets being the only brackets there are, which can lead to ambiguous code where for example you’re not sure if you’re accessing an array or calling a function that has the same name.
I really want a safe language that has actual nice syntax instead of some gibberish with lots of symbols, and Ada is the closest I’ve found, but she’s old and forgotten now.
Holy hell Java on a Smartwatch?
WearOS is based on Android, which uses Android Runtime (ART) as the application runtime. ART uses Java (or any other JVM-compatible language, such as Kotlin) as the development language, but compiles the app to native code when it’s installed on a client device.
So… Kind of?
I hate writing code in either language. But at least what C has going for it is that it’s waaaay simpler than C++. Simple can be a really good thing. Sure, all those cool features can save you time, but they can also be gotchas that will cause bugs.
Though it is a balancing act. Too simple and you’ll make mistakes due to how much you have to repeat yourself or using unsafe equivalents (like using preprocessor directives to mimic features that C++ natively supports).
deleted by creator
C++20 (or even C++23 if you can find a compiler that supports it) is pretty great if you use smart pointers and concepts rather than malloc and raw templates. This is especially so if you enable all the useful warnings you can find and use a good IDE.
Sadly, most C++ software out there was written in the 2000s and needs to be compatible with the original author’s VAX machine running Linux 2.3, so using modern compilers often becomes a challenge.
Coming from other object oriented languages, C++ does have some weird quirks (like the way it deals with default initialisers) but none of that is impossible to learn. Sadly, it’s bogged down by decades of old, shitty C++ that it needs to support
I suppose you could use good linting tools to ban raw pointers and enforce move()s, but honestly, I would start any new C++ project in Rust instead. Rust has its issues (especially with C++ interop), but until Carbon is ready for production use, I think it’s the best way to handle C++.
It’s the amount of legacy it’s carrying on that drives me crazy. Many of the implicit default implementations are confusing. That’s where all these “rule of 3”, “rule of 7”, “rule of whatever” come from. The way arguments are passed into functions is another issue. From the call-side you (sometimes) cannot tell if you’ll end up with a moved value or a dangling reference. The compiler will not stop you from using it. Even if the compiler has something to tell you, it’ll do it on the most cryptic way possible. I’m grateful we have C++, it paid lots of my bills. But it’s also a pain in the ass.
The most recent C++ thing I worked on (not that recent, like 5 years or so ago) was a fairly new project and the people working on it were really passionate about C++. But it was C++ code that ran as a Python library and was using the official Python C bindings. Not sure why we didn’t use one of the unofficial C++ libraries, but the usage of that C library (and such a fundamental one) held things back. We wrote was was modern C++ (at the time), but big chunks would be a completely different style.
C++ was necessary, and truly great compared to its predecessor. But the world has marched on. Rust is the current benchmark.
Depends on the use case, for HPC c++ is still the benchmark.
Yeah, some of the world marches slower than other parts.
I hate fighting its compiler and having to jump through hoops to get things done that’d be simple in Python.
If I’m gonna use a system programming language, I pick Rust. At least Rust provides clearer compiler errors, a package manager, a decent plugin ecosystem, and memory safety. Its runtime errors are a lot easier to decipher than the infamous “Segmentation fault (core dumped)”.
Don’t overestimate Rust, I’ve dealt with plenty of segfaults using it. Hell, I’ve had a situation where the Rust compiler generated some kind of instruction that wasn’t compatible with my CPU, that sure was fun to debug!
Rust has issues with interoperability with system libraries. It solves this (sort of) through static linking, but static linking is why we’re still receiving daily updates for programs that open WebP files over a week since the library has been fixed on every single platform. Plus, there’s no good way to make a Rust UI that doesn’t look like it came out of a video game. Then there’s the whole async deal, which is great until you need to send anything more complex than an integer between threads.
C++ isn’t exactly resistant to segfaults, but with C++11 things have become orders of magnitude better. C++ versions up to C++23 have improved things even more. If only people actually used those features…
I think a good C++ dev using modern tooling can probably write code that’s just as stable as and even more compatible than Rust code, but many programmers are stuck in their old ways, or on old compilers, or think they don’t need Valgrind because they’re rockstars.
Take a look at SerenityOS if you haven’t already. It’s an OS designed from the ground up, written in modern C++ (as in, the standard build script will compile a compiler because most distros don’t have compilers modern enough to run it). It includes everything from a kernel to a web browser and a Javascript engine. That project kind of redeemed C++ in my eyes.
Is there a way to disable the old c++ features? Or some kind of linter that points them out and suggests the new ways?
I think your best bet is a good linter in combination with a CI pipeline that treats all linter warnings as errors. Compilers generally don’t disallow old features.
Any suggestions for linter?
Last time I set up such a system was for a course several years ago, I don’t know what linters are popular these days. Flint used to be pretty good but it’s no longer maintained. Back then I set up a combination of cppcheck, clang with almost every optional warning, and clang-tidy for formatting. clang-analyze and cppcheck will compliment each other nicely but you do need to play around with their configuration to make informed decisions about conflicting advice every now and then.
Microsoft’s compiler does have warnings about certain risky uses of raw pointers, so using MSVC may be a good idea for safe programming until clang and g++ catch up. On the other hand, MSVC++ is behind on certain other C++ features, so you’ll have to weigh your options here.
There isn’t much documentation I can find on the topic of setting up a linter to enforce modern memory management. Most people asking for information about it seem to get responses from C++ experts telling them raw pointers are fine for and that you shouldn’t be scared of them, but I disagree.
Sadly, no tooling I know of has sufficient detection of pointer footguns (such as smart pointers made out of smart pointers leading to double frees).
deleted by creator
I used COBOL to write a small program, and it’s not so bad either. Bonus is that your standards are lowered so much that Java feels concise.
Laughs in ADA