I used to code C++ in early 00s and used to think I know the language OK. Then I stopped using it, meanwhile C++11 and friends came, along with lambda syntax, move semantics etc. - that was a jump but I could still just about follow.
Now I don't follow anymore. It's a new language on top of new language on top of new language. On top of C++. On top of C.
C++11 introduces a lot of things that make it far, far easier to work with. I would not want to go back to a pre-11 environment.
As for everything after that, you don't need to use those features. You can still write C++ like it's '11 and be none the lesser. That's what I do. Keep it simple.
In a similar boat with C++, but even the complexity of fundamental "simple C++" issues and lack of syntax sugar made me gravitate away from C++ to better-C style languages ultimately landing on Zig.
Using another language has only made me feel C++'s shortcomings more strongly than before.
Stroustrup even gave a talk about what a new C++ next language would look like and lands on many things better C languages already have implemented.
Sadly it's doubtful for gamedev to move away from C++ anytime soon. I am enjoying Vulkan+SDL in Zig on a personal project and can only hope that space of the language's community continues to grow.
I find a lot of the syntactic sugar problems can be solved with a library. I use QT for a lot of my work and it is a fantastic library that saves me a lot of time. Using its strings are a breeze, not to mention QFile/QFileInfo/QDir for anything file related, QProcess for running external processes, etc. It's rich, well documented, and highly functional.
Yeah. C++11 was very much a new language “on top of” C++ — but it was a so much better language that learning it was a joy, and using anything predating it would be crazy. The minor tweaks since then are at times visually stunning (and not always in a good way), but are in the end quite minor, and can be safely ignored.
The frustrating thing with layer-cake languages like C++ is that it can technically have all the ergonomic APIs that make life nice to write, yet have all this cruft and esoteric edge-case behavior that makes it so, so hard to read. I can't safely ignore features in C++ that others are using when I'm evaluating the correctness and security implications of already written code. And barring a strictly enforced (e.g. mandatory lint before merging) coding convention that bars all the nasty sharp points and legacy APIs, even a new project will gradually accrue the bad bits from devs who are used to using C++ that way.
All languages that are sufficiently widely used eventually become 'layer-cake' languages.
It's inevitable once you have multiple big groups of people with very different needs. And once language design and best practices has evolved from where it was when the language was originally developed.
The only ones that escape this problem aren't widely used enough to have much demand for new features or changes.
Yeah, I'm not saying these are bad changes! Only that it's so changed that I cannot read modern non-noddy C++, having been previously at least conversational, maybe fluent in it.
There are also some features that have been introduced later, but which are so simple that they do not increase the cognitive load, so there is no need to avoid them.
For example, C++14 has introduced a digit separator in numbers, some 35 years after Ada. For me this is an extremely useful feature, because I have to use big constants from time to time, even if I hate any contributor to the C++ standard who has thought that instead of using underscore as the digit separator, like in Ada and in many languages that have followed Ada, it is a good idea to replace the underscore with the apostrophe.
There has never been any valid argument for using the apostrophe instead of the underscore. Underscore would have introduced a few subtle complications when parsing legacy programs, but that is also true for the apostrophe. Such complications could have been trivially avoided by forbidding a number to start with a separator.
I have the same feeling. It seems to me these copy/move semantics are done for performance reasons, and at the same time are very hard to follow / use / implement correctly. Today I would rather use C or assembly language than C++. At least I know what I am doing.
The =default syntax might be new, but this should work the same if you use {}... I think this semantic has been the same the whole time I've used C++ (which seems to be a lot longer than you)? (Or like, is the issue with using the is copy constructable check from the standard library? Back in the late 90s we all had those, just in bespoke libraries.)
I have the same issue. Every time I feel I want to get better at C++ and learn what changed in the past 2 decades, I also have to contend with the fact that I'll have to learn cmake, that package management is non-existent, that compile times are atrocious and let's not forget the whole template abomination.
The day I need the performance and guarantees C++ can give me is the day I'll dive deep into Rust instead.
The rule for determining copy constructibility is whether a non-deleted copy constructor is present. In the case of Derived, it is present. It may not be instantiatable, but that’s not what is_copy_constructible looks for.
This whole article is a very verbose way to reach the conclusion that std::is_copy_constructible_v is a poorly chosen name, not reflecting the actual truth that the construct provides.
If it were called std::has_copy_constructor, there would be no need to write even the title of this article, let alone the body.
Also, maybe this should require a diagnostic due to it being statically obvious that it is calling a deleted constructor:
Derived(Derived const& d) : Base<T>(d) {}
... and if we use regular non-template classes, it does!
The problem with eager diagnostics and templates is that the program could define a `Base<int>` specialization that has a working copy constructor later. [0]
I think if you define an explicit instantiation definition, it should type check at that point and error. [1] I find myself sometimes defining explicit instantiations to make clangd useful (can also help avoid repeated instantiations if you use explicit declarations in other TUs).
I would argue that has_copy_constructor would also have the same issue in naming since most people would assume that has_copy_constructor means the damn thing works for copying.
Too many traits is my diagnosis, so I agree with "foiled by templates". Like almost any attempt to make a sane C++ codebase.
> most people would assume that has_copy_constructor means the damn thing works for copying
Assumptions that something "works" in C++ are generally too nuanced and optimistic to be a good idea. Calling the test "has_copy_constructor" would at least make explicit that it is a test about what declarations a class contains, which is a very rough compile-time approximation of being copy-constructible in practice: a valid declaration is only the first step towards calling a constructor without runtime errors and other trouble.
> If it were called std::has_copy_constructor, there would be no need to write even the title of this article
Ah, but then someone might ask "Why does the library report that my type has no copy constructor, when it is in fact copyable?" And then the blog post would have to be about how it's possible for a type to be copy-constructed using a constructor (or constructor template) that is not itself a copy constructor.
Of course, the existing state of C++ doesn't prevent us from having to write that blog post, either!
I guess it's better, but with C++ being C++, you will then need to decide if you consider
struct A { A(const volatile& A); };
as a class with a const copy constructor. Maybe someone cares?
Proper templated classes don't behave like this. If you manually define a copy constructor in a template class it has to work. And if it works only conditionally (like in many container classes) you need to add constraints on your constructors (>C++20) or derive from appropriately specialized base classes (e.g. std::_Optional_base in libstdc++).
It sucks to tell users "you're holding it wrong", but I don't think there's a way to make it simpler without breaking everything written since C++11.
The real wtf here is templates, right? Am I right in thinking that if Derived wasn't a template, its copy constructor that tries to use a deleted parent copy constructor would fail to compile?
Now I don't follow anymore. It's a new language on top of new language on top of new language. On top of C++. On top of C.
reply