5 ms·
> Personally, I think what C++ offers is the same as Rust. I think this dismisses incidental complexity that can certainly exist in general, and certainly does
by quietbritishjim 7y ago
> Personally, I think what C++ offers is the same as Rust.
I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++.
Just look at how complex move semantics are in C++:
* you have & and && references,
* there are all sorts of categories (e.g. glvalues),
* in a template && means something different (but not always),
* std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront),
* even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning.
In Rust, the difference is enormous:
* When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything;
* Move is always a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point)
* Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it.
This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem.
(Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)
- pjmlp 7y agoYou forgot about SFINAE, CTAD, decltype vs auto, perfectly forwarding references, guaranteed RVO (but only in certain ISO versions), initialization semantics, ...
- WesternStar 7y agoHe didn't forget perfectly forwarding references.
- quietbritishjim 7y agoBut that does show how confusing the notation is!
- WesternStar 7y agoI guess I watched the back to basics c++ series on move semantics and its not really all that bad. I did struggle with it beforehand though. I've never worked in C++ tbh. I does take the 2 hours but you have it when you're done. https://youtu.be/St0MNEU5b0o https://youtu.be/St0MNEU5b0o
- quietbritishjim 7y agoReally? You can tell off the top of your head what the difference between an xvalue and a glvalue is? Which function has higher precedence in the overload list out of foo(string&) and foo(string&&)? (Note that's not a const string&!) That these are so obvious to you that there's no chance you would make a mistake about them when you're in a hurry trying to solve an actual problem that has its own complexities rather than playing games with C++'s unnecessary complexity? The one where foo(std::move(x)) doesn't necessarily move x is a particular killer (although at least it only causes a performance problem rather than noticable change in behaviour). I have worked with C++ for a hell of a lot more than 2 hours since C++11 came out (the first version with move semantics) and worked with many others that have too, and I can tell you that "once you have it you're done" is just not true. I fully understand all the concepts but I can still make mistakes.
- WesternStar 7y agoIs there more? Yea. Do you need for most code ? No. Also I lied I have coded professionally in C++.
- BubRoss 7y ago> SFINAE, CTAD These are advanced template techniques for people who want to dive deep into writing template libraries that are as generic as possible. Insinuating that they are a necessity to learn is ridiculous. decltype is easy and only necessary when trying to make something more generic. > guaranteed RVO Also something that programmers don't even need to know exists unless they want to dig into it.
- pjmlp 7y agoExcept that is all nice and good, until one comes up with the naive idea to use Boost, and somehow they need to dive into the source code to track down a bug. Or landing by parachute on a codebase that needs some work. Or just having to integrate a C++ library done by other team into their managed language framework. Ridiculous is how many in ISO C++ seem to ignore Bjarne's plea to not overcomplicate the language.
- BubRoss 7y agoNow you are conflating the language itself with examples of it being used terribly. I pointed out that your criticisms are a huge stretch in reality and instead of confronting that, you decided to ignore what I said and throw more out there that isn't even a part of C++. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop Boost is mostly terrible and isn't hard to avoid. People don't need to use it and they don't need to debug it. This is far removed from talking about the language itself.
- pjmlp 7y agoBoost is very relevant to the language's standard library, as it is the research ground for features that eventually end up in ISO C++ standard library. Should we go through the ISO C++ features that were born in Boost?
- BubRoss 7y agoBoost is an external library and it is known for its overly complex templates and long compile times. It isn't part of C++. The features that were adopted from being tested in boost do not have the same dependency problems. Your initial criticisms didn't hold, now you are trying to criticize external libraries as a failing if the language. Maybe you just want to criticize c++ with anything you can think of, no matter how ridiculous. Ironically there are probably an endless streams of criticisms that could be lobbed at it, but everything you've mentioned are things that just aren't problems in practice.
- yaktubi 7y agoI agree about the looseness in C++. However, the details of move semantics are not complex. For instance, reading first item of Effective Modern C++, “understanding type deduction” shows it’s pretty much the same as type deduction templates have used for decades. If one understands the aspects you mention above, good coding practices can easily be put in place and code reviews enforce.
- nicoburns 7y agoThe fact that you have to read a book to understand C++ says it all really.
- yaktubi 7y agoOne should read a book—or perhaps even many books—on mathematics, or any subject, to call oneself proficient in the subject matter. In fact, if you do not read books on subjects , you are part of the code quality problem to begin with.
- nicoburns 7y agoI have a maths degree, and I don't think this is at all true for programming. Lot's of people read books on Object Oriented programming, and write absolutely awful Java Enterprise code. Or they read books on algorithms, and write fantastically efficient code that's completely unreadable. And what's better than a book of best-practices? A compiler that enforces them.
- antonvs 7y agoI've never met a person with a maths degree who could write professional quality code, unless they also had some sort of other training. Reading books doesn't automatically fix that, but it can help, just by exposing one to practices that one might not have come across in the kind of work that passes for programming for mathematicians, data scientist, etc.
- 7y ago
- ignoramous 7y agoAlso see: https://wiki.c2.com/?CppBashing https://wiki.c2.com/?CppBashing u/yosefk is probably the greatest CPP basher of all time. iirc, Rich Hickey was an expert CPP programmer before he developed clojure.