I'm so done with C++. When a fundamental keyword becomes a semantic pitfall, you've created an esoteric niche for enthusiasts, not a useful tool.
You can happily never know the existence of '=delete' and nothing about your code changes. And if you ever hit a libraries usage of it, like the standard library, you get a pretty clear error message at compile time instead of an actual footgun in C++98 like memory corruption or runtime crashes.
'=delete' is basically the entire reason why std::unique_ptr is safe and std::auto_ptr is a footgun. It reduces the ammo aimed at yourself & the amount of knowledge you need to know (like the knowledge to never put auto_ptr in a vector)
Like, are there other =<something> construct? Is it overridable or overloadable by the user? Can I use it to "erase" any member of a class, for instance to hide a parent member from an inherited class?
I suspect that the answer to all of these questions is "no", but I can't know for sure without deep diving into some C++ ref.
In the C++ I knew there was nothing resembling this syntax, and `delete` was only the keyword you used to free memory.
Yes, there's "= 0" to mark a virtual method as not implemented in this class (that is, it must be implemented by a subclass), which is older than "= delete". Conceptually, it sets the corresponding slot in the virtual method table to null instead of a pointer to the (non-existent) method, except that it actually doesn't do that, it sets that slot to a pointer to a "pure virtual method called" function from the standard library, which AFAIK prints an error message and exits the program (IIRC, this is because there are some situations in which you can actually manage to call such a pure virtual method, like calling it from a function called within the constructor or destructor of the base class.)
If you try to instantiate an object without all methods implemented you'll get a compiler error about the class being "abstract". You should never have a case where there's a null in the vtable.
If there is some specific edge case around ctors then forgive me - this is C++ after all! But in practice you don't have to worry about this which is true for most of the C++ minutia.
Yes, the specific edge case is around ctors and dtors. During the ctor or the dtor, the vtable is the vtable of the base class, not the derived class, so if you call a virtual function within the ctor or dtor of the base class (don't do that), the function which will be called is the one from the (possibly abstract) base class. See for instance this FAQ entry: https://isocpp.org/wiki/faq/strange-inheritance#calling-virt...
As a sibling mentioned, it's not even a new syntax as '= 0' has always been there.
You can use =delete to delete any overload of a function, be it class member or namespace scope.
Languages evolve; =delete and default were added to get rid if a bunch of common hacks and the language is better for that (at least for delete, default has a bunch of pitfalls of its own unfortunately).
You don't become a good craftsman by rejecting every tool that isn't perfect. You become one by knowing your tools and their flaws and strengths well.
Yes, that's why I said "I" am done with it, not "you should be done with it." There's no need for me to use it ever. Except when forced to with mbed, TFLiteMicro, and the occasional port of an Arduino driver to C.
I've been at this since before C++ existed. I've watched it come in to the world, and I've watched it mutate, Akira-like, into an academic omphaloskepsis.
EDIT: Fun story: I learned C++ in ... 1990? ... by watching a series of videos on VHS tape taught by none other than Bjarne Stroustrup himself. I think it was a bonus that came with the purchase of the first version of the Borland C++ compiler for OS/2.
private : myclass(const &myclass )=delete;
Just to be safe :-)
Edit: NVM, looks like all major compilers will say that the copy ctor is deleted. https://godbolt.org/z/jTd3714Tb
Foo() = delete;
Foo(const Foo& orig) = delete;
Foo(Foo&& orig) = delete;
Foo operator=(const Foo &other) = delete;
Foo operator=(Foo &&other) = delete;
But what to use instead? Especially in an industry like game engine development, where C++ is basically all there is (and almost all there’s ever been)?
Are we forever going to be stuck with every company trying to reduce complexity by defining their own custom subset of C++?
Have fun! Write some cool games!
I periodically check https://www.areweguiyet.com/ to see the state of things, but C++ is still king here.
I cut my teeth on C++ but was then employed to write code in C. After almost two decades of doing this, C++ looks vastly different to what I remember from 2001 and kind of ugly to me. I'm sure, however, if I had stuck with C++ for the last twenty years it would feel like home.
I'm coming up on year 25 of my career and I haven't touched C++ since school, if one can indeed call what is covered in school C++. Especially nowadays. And C and Java I've barely touched. I certainly couldn't put them on my resume with a straight face.
I say this because you kind of sound like you're making some sort of plaintive plea, as if C++ is somehow the only viable option in the world and who could even dream of stepping outside of it? And I'm telling you that while that may be true in an ever-decreasing set of niches, it is not true in general anymore and hasn't been for a long time.
Yes, probably? In 30 years of professional coding and a decade of game engine development, I’ve never seen that not be the case, all the companies I’ve been at and all the companies I know about limit their C++ to a subset to try to control complexity.
I’m curious if you’re suggesting it would be better to increase complexity by allowing all of C++? There are definitely features I don’t trust everyone with.
Complexity combined with engineer hubris is one of the big problems with C++. While working in games, I witnessed many people overengineering and being too clever by half, and costing the team time and money. One of the most memorable bugs I ever tracked down while working in games was a release-build only crash where a programmer had tried to get fancy with a copy constructor and bungled it unknowingly. We had a team of 10 people working over a weekend trying to catch it and I had to write a custom debugger to trap the call stack. The cost of his trickery was easily in the several tens of thousands of dollars at least. It only takes that happening a few times before you realize C++ is a foot-gun in many (most? all?) hands.
No, definitely not. I’m wondering if there might be a language on the horizon that’s suitable for game engine development but which is substantially less complex than C++.
Or, if not, is there an effort to rally round a particular subset of C++ instead of everyone defining their own? In your experience, have the C++ subsets used in different companies been very similar, or quite different?
If it doesn't exist, it should be created and called --C.
(C-- is already taken) https://en.wikipedia.org/wiki/C--
The problem with doing this is the same as with the idea that one "90% of people only use 10% of Excel's features" so we should be able to make a simpler Excel and capture 90% of the market: all those people use a different 10% subset. It's the same with C++; everyone wants a "simpler" language, but no one agrees on what should be kept and what should be thrown out. C++ is the language that results from putting together everything that everyone needs (and then dealing with the resulting conflicts and contradictions).
you think quux wouldn't be able to find semantic pitfalls in literally every language you would use instead ?
C++ is an old beast with many many footguns.
There's a more modern subset hiding inside, these days, but let's not pretend every language has the same pitfalls that C++ has.
But, adding keywords to C++ is expensive. You can't use these as symbols, you can't name a class, a variable, a function or anything "delete" because that's a keyword and so it's reserved. A new keyword would clobber existing symbols, and that's painful, so, C++ tries not to do it, instead repurposing existing keywords.
So as well as the operator named "delete" now "delete" refers to this feature where you can tell the compiler that this particular overload mustn't be used, if it was looking for an overload, it won't use this because you explicitly said not to (even if it could have otherwise conjured a default) and if somebody else called it by mistake now they get a compile error saying not to.
I don't think they would naturally have written =delete if not for being conscious that doing so is "free" (the word is already reserved for something else) whereas some other word would have caused compatibility problems.
Today delete is both the operator and this entirely unrelated feature, so that alters the meaning, a matter of semantics.
Natural languages have plenty of such ambiguity, but C++ has a Committee (yes I know about French, no the Académie Française doesn't actually get to decide how French works, that's not how natural languages work) which could have chosen to use a different word and did not.
But sure, C++ does have actual hidden spike traps, where unwary programmers are going to hurt themselves badly by mistake and this is not one of those.
I haven't written C++ in many years and my interpretation of the code examples before reading the rest of the article was that it was somehow binding it to the delete operator as a function.
I don't like the use of + for concatenation much either, even though it's overloaded to do that in some languages I really like, and it's even special cased despite the lack of overloading in one language I think is fairly good (Java) and some others I've used but think are garbage.
But I'm willing to cut some more slack for symbols because they're short.
I think erase for example would have been a better choice here (I haven't spent long thinking about this, the committee had months), but C++ had to worry about the backwards compatibility penalty and that's... sad.
Other examples of contextual keywords are 'final' and 'override', which may also occur on function declarations.
It's even more painful than that. A new keyword could conflict with a macro. So even contextual keywords (something which is a keyword only in a place where arbitrary symbols are not allowed, so there's no conflict) could be problematic.
Unless we are talking about v1.0 there always such cases when a language is around long enough.
but it always was!