As someone familiar with nearly a dozen scripting languages, I keep trying for something low level like C++, but it seems like these languages are impenetrable at times. It's hard enough to learn the machine stuff and manual memory management, but having the syntax change more often than a toddler's favorite color just makes it all seem impossible.
I think that Ken Thompson nailed it on C++: https://en.wikiquote.org/wiki/Ken_Thompson#%22Coders_At_Work...
Also Linus Torvalds is a huge detractor of C++: http://harmful.cat-v.org/software/c++/linus
But in the end everyone should pick whatever programming language feel comfortable with. Sometimes if you're pursuing a career in certain directions (e.g: game development) you have literally no choice but to knee down and learn whatever the industry is pushing to use.
The clang++ compiler, much more modern and built on the LLVM inftrastrucure, has much better error reporting. Occasionally, in desperation, I've compiled something with clang++ just to see the error message in cases where g++ was just too unhelpful.
Linux Torvalds has not looked at C++ since the '90s. C++ is a wholly different language now. The experience coding in it now much more fun, and it is easy now to write code that works the first time it is run (as is also seen with Rust).
Take TypeScript, for example: if you bugger up a type definition or function call in one file, you'll have to wade through the errors of everything depending on it. Oftentimes you can go from 30 errors to just 2 or 3 with one simple change.
The alternative is they fail at the first error but you don't get the root cause and end up fixing shit one by one if the problem isn't obvious.
Especially with a new project in an unfamiliar language - start small and compile small, incremental changes. You won't end up with something you can't fix, which can't be said for installing dozens of dependencies up front and hoping for the best.
Programmers like really neat logical explanations for everything, but the real world is much messier. People do not acquire human language skills by learning a formal grammar, learning all the edge cases, and then finally speaking: they attempt to communicate as best they understand, and then refine their knowledge over time.
The same works with computer languages. Not just C++. You don't generally learn every single detail before you do meaningful work. You just kinda try stuff and figure things out. Sure, you may practice specific skills, but that's just not the primary method of learning. And even in those cases, you don't necessarily learn everything before you return to practicing what you've learned: it's a process where the two activities feed into each other.
You mostly just go "damn I wish there was a better way to do X" and then find out there's a paper someone wrote, and then you pay attention to its progress. Or you just keep doing what you're doing, and at some point, a blog post comes out that's a summary of what's new, and you go "ooh that sounds interesting, I should look into that." But for every feature like that, there's also features which you go "ehh I don't need to care." And that's generally fine.
> having the syntax change more often than a toddler's favorite color
No real syntax is different here, this is a function call like any other. And C++ changes on a three year timescale. Many scripting languages release new versions far faster. It's just stuff that's less familiar to you, and so it seems harder, but it's learnable.
> It's hard enough to learn the machine stuff and manual memory management
This is the bigger struggle with learning, moreso than "syntax changes." If you haven't done lower level stuff before, you also have to recon with that while learning. That does make things harder the first time you learn a new paradigm, just like if you'd never used a functional language before, you'd be learning about those concepts as well as the syntax and specific language semantics.
Every new Standard has some features few people will use. Those are easy to identify and ignore if they don't solve a problem you have.
Isn’t this the epitome of C++, though? It literally is the LTS language
I never said you had to. The question that was asked is "how hard is it to" not "should I."
> A professional computer language should always have a ”LTS” mode where you can compile a decade old code without modifications. Otherwise the language is a toy.
I don't personally feel that this is a useful distinction because it means the vast majority of language implementations are a "toy." Heck, C++ might be one of the few non-dead languages where this is true! You can add new things while staying backwards compatible. "I want to keep up with the language" and "I want ten year old code to work" isn't inherently at odds.
- No standard / user friendly tooling: there is no package manager, getting dependencies "as easy as copying a header from this github repo" is messy, is a liability, generates toil, etc.
- The language is very complex, i.e. there are 7 different ways just to declare a variable (I'm not even discussing templates, optionals and what not) and more often than not C++ projects spans years or decades, there is a natural mix of styles from people across different generations on what is "modern" and it's a sore to my eyes. At every release rarely things are removed from the language, but there is always something added.
At every company, the subset of what features are reasonable to use, understood and well maintained can change drastically. That might be a company problem, not a language one, but it's something sistematic enough that I would say it's a language thing.
- Every language has its gotchas, but with beginners interested in using fancy features of the language, the surface area is just too big.
I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec. What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?
Even though C++ is the language programmed the most in my career and I can appreciate how nice it is at the right conditions, I've come to accept that the tenets of the language, the way the TSC sees it (stability, backward compatibility, performance) no longer resonate with me and I come to appreciate the consistency, simplicity and ease of use of other projects, there is a bigger world out there and the pond of C++ issues is a place I would rather leave behind.
This isn't relevant. The standard is for compiler writers and library writers who use advanced meta-programming.
"What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?"
That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier.
It is. It is a metric of how ungodly complex the language is. You can infer by this that having a comprehensive mental model of the language is difficult, do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB, but this flies under the radar of a lot of developers. You don't need to be a compiler engineer to make good use of such information.
"That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier."
True, but it takes time to be proeficient with the changesets, for the projects to be transitioned to newer versions, if they are at all, and then to map what is valid in which version if there are reworks everywhere (e.g. I'm involved with some that are still c++14, "Do we have structured bindings available here? Oh, no, too bad.").
I appreciate thing gettings better/easier, but c++ seems to be all over the place (just checked the compiler support for c++20 and there is still partial support for some features in major compilers, even though work on c++23 has already started).
"do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB"
And most of these things were present in the first revision of the C++ standard or even in C.
"You don't need to be a compiler engineer to make good use of such information."
Why do you think that a programmer has to learn C++ by reading the standard? One does need to have a good mental model of what's happening but it's enough to have a much much simpler mental model than the standard.
"and then to map what is valid in which version"
That's where skills acquired 5-10 years ago are most relevant)
"Why do you think that a programmer has to learn C++ by reading the standard?"
If your application seg faults due to an ill type deduction caused by `auto`, why did it fail? What kind of type deductions auto covers? Experience by trial and error will hardly help you here.
End user developers will acquire that knowledge probably by reading digested material from experts either focused on language tidbits or working closely to the standard (Effective C++, Effective Modern C++, blogs, etc.), the root source is still the spec, the more complex the spec is, by transitivity, the more complex is anything that comes out of it.
I guess the bottomline is that we agree the language is complex and I'll leave it at that.
Yeah, that's why so many languages don't have spec at all.
And C++ is explicitly a multi-paradigm language so there can be affordances for multiple approaches. You can even use it as an OOP language if you want!
As far as syntax changes go, mostly they are in the direction of simplification and/or unification intended to make programming easier in the long run. So, for example, you can now in many cases write template generics without the elaborate template syntax.
But the C++ is also pretty unwilling to break old code, so old syntax and obsolete semantics are still available should you so choose. This is confusing to people who come to the language later on.
(Note that above I wrote “intended to make programming easier”. The case I cited of generics does make some things easier for me, but of course de gustibus and all that.)
You can write an incorrect program in any language. Some kind of self-discipline is important and necessary.
Try: "g++ -std=c++20 lb.cc && ./a.out iodhuamplrnc words".
#include <array>
#include <bit> // popcount
#include <iostream>
#include <utility>
#include <string_view>
#include <vector>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
struct Word {
std::string_view str;
unsigned bits{};
static unsigned index(unsigned c) { return c - 'a'; }; // 'a'..'z' -> 0..25; others -> >25
Word(std::string_view s, unsigned accept, long long sides) : str(s) {
long long prev_side{-1}, side; // Values are 0..3. First letter gets a free pass.
for (char c: s) {
const auto ix = index(c);
if (ix < 26 && (accept & (1u << ix)) && (side = ((sides >> 2*ix) & 0x3)) != prev_side) {
bits |= (1u << ix), prev_side = side;
} else { str = {}; return; }}}
};
int main(int ac, char** av) {
auto usage = [av](){ std::cerr << "usage: " << av[0] << " abcdefghijkl [<wordlist>]\n"; };
if (!(ac == 2 || ac == 3)) { return usage(), 1; }
const std::array prefixes = { "", "/usr/share/dict/", "/usr/share/dict/american-english-" };
const auto name = (ac == 3) ? av[2] : prefixes.back() + std::string{"large"};
std::string_view file;
for (auto pfx = 0u; pfx != prefixes.size(); ++pfx) {
int fd = ::open((prefixes[pfx] + name).c_str(), O_RDONLY);
std::size_t file_size = ::lseek(fd, 0, SEEK_END);
void const* addr = ::mmap(nullptr, file_size, PROT_READ, MAP_SHARED, fd, 0);
if (addr != MAP_FAILED) { file = {static_cast<char const*>(addr), file_size}; break; }
}
if (file.empty()) { return std::cerr << av[0] << ": cannot read " << name << '\n', 3; }
auto target_sum = 0u; auto sides_sum = 0ll;
for (unsigned i{}, ix{}; i < 12 && (ix = Word::index(av[1][i])) < 26; ++i)
{ target_sum |= (1u << ix), sides_sum |= (i/3ll << 2*ix); }
if (std::popcount(target_sum) != 12 || av[1][12] != '\0') { return usage(), 3; }
const auto target = target_sum; const auto sides = sides_sum;
const auto candidates = [target,sides,file] { std::array<std::vector<Word>, 26> candidates;
for (std::string_view in = file, next; !(next = in.substr(0, in.find('\n'))).empty();
in.remove_prefix(next.size() + (next.size() < in.size()))) { // Skip past '\n' if present
if (const Word word{next, target, sides}; word.str.size() >= 3)
{ candidates.at(Word::index(word.str.front())).push_back(word); }
}
return candidates;
}();
std::array<std::vector<std::array<std::string_view, 2>>, 100> answers; // radix sort by length
for (auto const& firsts: candidates) for (const auto first: firsts) {
for (const auto second: candidates.at(Word::index(first.str.back()))) {
if ((first.bits | second.bits) == target) {
answers.at(first.str.size() + second.str.size()).push_back({first.str, second.str}); }}
}
for (auto const& of_len_N: answers) for (const auto answer: of_len_N)
{ std::cout << answer[0] << ' ' << answer[1] << '\n'; }
}std::string_view lets you have some of the bugs that are caused by misusing pointers.
I have seen them used in the PIMPL idiom, which is a rather controlled case.
The answer is: Effectively not hard, because:
1. When you write complicated software - especially with older-standard-version C++ - you often have the thought of "Oh, if I could only do X more easily" or "wouldn't it be good if we could skip the tedious coding to make the compiler do Y?" - and then you either grit your teeth and write something ugly which works. But then, a few years later, you hear it mentioned that X' or Y' have been standardized, and then you know "Oh, good, now I can do that more easily".
2. Stuff that you _don't_ know about, that gets introduced - you typically don't have to know about. Either it's not relevant to you, or it is, but you're just writing old-style code.
3. The "junk" gradually makes you be able to write the code you want more easily. So, unless you want to do deep guru things - you can gradually even _forget_ things you used to know how to do, since you no longer need to know about them.
C++ is a weird combination of pragmatic features, close to the metal performance (which you can junk if you don’t actually understand what is happening on machine kevel), universally abysmal tooling (compared to other current languages), huge ecosystem of super-usefull super-nontrivial libraries… a combination of super good and super bad.
If you don’t need the super good stuff (which you don’t need unless you know you need it) all you are left with is the bad stuff.
The C++11 is okay. C++ committee is a weird combination of clown-car non-savant idiots and super talented pros.
An actual engineer or carpenter doesn't master every conceivable tool before beginning their work, they can't, there's too many.
Say what you will about C++ programmers, but at least they are free from the burden of trying to use a perfect language and can focus on more important things.
As a C++ dev - If you don’t need C++ then choose whatever other modern language.
We keep up with C++ because of specific constraints other languages don’t fill.
People use Java because they work in a Java shop. Similarly, COBOL.
I would say most programmers, in any language, are free from that burden: once they picked their language they can focus on those important things.
After 35 years of C++ on and off, I have pretty much given up it. I don't have the mental energy to deal with its complexity anymore. I will deal with parts of C++11 or C++14, mostly so that I can read other people's Arduino code.
I think I would rather learn a new language (Rust?) than deal with the hairball that is called "modern C++".
The vast majority of programmers' lives is spent reading code. We need to be able to interpret, repair and extend the work of others.
I often hear this defense of C++, that you only need to know certain parts and the rest are for "library writers". This is an absurd argument, but not exactly surprising from the core C++ cult(and I say this with 26 years as a C/C++ dev). It's almost as if there are two separate camps, one writing and maintaining production software, and another group which only works on language internals and is becoming further divorced from reality.
But many offer better ways to do familiar things, that make the overall programming experience more pleasant. Use those as soon as the compiler you use gets support for them. Often they make bugs harder to write, and correct code easier to write. Now we can write
for (auto const& [key, value] : map) { ... }
for (Map::const_iterator_type it = map.cbegin; it != map.cend; ++it) {
Map::key_type const& key = it->first;
Map::mapped_type const& value = it->second;
...
}
Another example is extension of "constexpr" to more and more of the language; each eliminates the need for some range of template metaprogramming. Nowadays you can ignore almost everything written about template metaprogramming, because there are good, straightforward ways to achieve its aims with ordinary language features.
I learn something new all the time when I explore new codebases or even less beaten corners of existing codebases. Only a tiny fraction of the time it is a new facet of the language.
Herb Sutter has been working on it for awhile. My only exposure to it has been watching this recent talk:
Instead, start using the most modern language your compiler supports. Everything you write will come much easier, with much less opportunity for mistakes, and be much more fun. You will hardly ever find yourself using pointers, and never allocate or free memory.
I would be very careful with that approach. C is broken beyond repair, and C++ didn't fix it. The only sane way forward is a clean break with a cleaner syntax (or at least one that is truly context free, dammit), and fewer undefined behaviours. Much fewer.
And of course, GC and RC aren't fixes, they can't apply in the performance constrained settings C and C++ typically are used for (tiny embedded chips, video games, video encoding…).
Also there's no way I'll even look at a new language without some form of generics. They're just too damn useful. Sure we could try the Go approach and special case generics for a few core data structures, but I believe a general purpose language needs a way to add custom ones. Heck, even Go fixed its mistakes and added generics after all.
But I (mistakenly) thought we were talking about designing a language. And for this I have a point: coming up with something like C in 2023 would be unacceptable. We know better now.
Sorry about the non-sequitur.
C++ completed a cycle of related versions with C++11/14/17 so a lot of firms have settled on C++17 for now. C++20 introduced a LOT of new language features, some of which are still being explored and implemented and is still considered bleeding edge. C++23 has been finalised but is still going through the final ratification as far as I know.
It is absolutely fine to be a few years behind the curve, as unlike other languages (typically controlled by one company) where a new version ships at the same time as compiler/library support, for C++ the spec is released first and then the many different vendors implement it (in some cases approved features are implemented ahead of release - typically Microsoft gets library features implemented quick while other compilers get language features quick. Modules are the notable exception to this rule).