41–50 of 158 posts
I tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer.
Earlier quoted context omitted.
Smart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by exit, too.
This would seem to be a very micro optimization, though. If you are in a tight loop, sure, but otherwise I would say that smart pointers are a rather low price to pay. And if you are in a tight loop it may be better to try to avoid memory allocations altogether and try to reuse objects instead. In any case the price of smart pointers is orders of magnitude smaller than the price of what passes as 'modern' software de…
Earlier quoted context omitted.
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
> In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
In fact probably yet another reason why Apple and Google aren't in an hurry to improve clang to latest ISO, and other companies in clang ecosystem even less.
Earlier quoted context omitted.
Smart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by exit, too.
unique_ptr has zero overhead
Earlier quoted context omitted.
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
> In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
It is not uncommon that older/senior developers hold an undeserved grudge against STL. STL was far from mature in the 90s, sometimes even rather bad (at least in Windows/Visual Studio). But that is simply not the case anymore. Modern STL is well-written and highly optimized IMHO. Sure, it is not as "complete" as standard libraries in Python, Go, etc. It is rather a different kind of beast than those standard librarie…
Earlier quoted context omitted.
This feels like Stockholm syndrome to me. 1. I’m amazed that you call Java ugly and verbose but recommend C++. Apart from files not needing to be classes in C++, they feel similarly verbose to me with C++ slightly winning on ugliness. 2. I basically don’t believe that memory management is not hard. The reason is that plenty of programs written in ‘modern’ or ‘safe’ C++ in the style you recommend continue to have plen…
> 1. I’m amazed that you call Java ugly and verbose but recommend C++. Apart from files not needing to be classes in C++, they feel similarly verbose to me with C++ slightly winning on ugliness. I've always found java much much more verbose. here's e.g. hello world in javafx: package helloworld; import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.sce…
Since Java 10,
var root = new StackPane();"You can write reasonably fast software in almost any decent language (with a few exceptions)." - this is entirely wrong statement.
I don't think it's so cut and dry.
What the software actually attempts to do probably also matters a lot for what "reasonably fast" is. Would i write a distributed file system, a web server, or a database engine, or some OS component in pure Python? Probably not (assuming CPython, something like PyPy might make it more viable). But at the same time, Go might be a decent option for any/all of those, despite generally being a bit slower than C/C++/Rust.
That said, Python, Lua or anything else that's often touted as a decent language despite being on the slower side could be a good choice for glue code (just look at machine learning, number crunching and other domains where Python is pretty common), maybe creating various scripts (e.g. for setup/automation of common tasks without having to do everything in Bash), or maybe developing CLIs/TUIs or libraries to act as front ends for more complex bits of other software.
What probably also matters a lot for system software is C interop, or just how well the software can integrate with the system libraries etc., unless we're talking about something that's fully statically linked. Of course, this doesn't necessarily have that much to do with speed, just another factor to consider.
Also, while on the topic of other things that matter, the speed of development is also one such thing - not everyone has excellent knowledge of the intricacies of working with lower level languages and frameworks for them. Surely system software shouldn't necessarily be restricted to a select few developers, so anything with fewer footguns could be worthy of consideration!
In short, use whatever works for you, but "reasonably fast software" isn't all too restrictive of a target so in the modern day most languages can indeed find their place in the grand scheme of things. There's very little preventing you from writing most of your software in Python and writing the 10% of performance intensive code in something else.
Of course, limitations apply - for example, writing GUI software with Electron will usually be done for ease of development rather than performance (just look at how much resources Microsoft allots to getting Visual Studio Code to perform well vs something like Brackets/Atom which are really sluggish in comparison). Admittedly, GUI software isn't always the first thing that people think of when talking about "system software", but i feel like that disclaimer is a must anyways, there's lots of nuance to everything out there.
Earlier quoted context omitted.
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
> In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
I have yet to see more than "print and bail out" in catch blocks. In embedded there is nobody who can read your cry for help and especially in fail-op systems this is just not an option.
Herbceptions are just not there yet and until then we help ourselves with things like "expected" for example.
Earlier quoted context omitted.
> In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
Are there any usable linters around to enforce such rules?