28 seconds ago
>but pointer semantics (and in fact they prefer raw pointers T* to T&,
>like explained in Google's C++ Style Guide)
Please don't quote the Google C++ Style Guide - it is totally boneheaded.
While I don't agree with every point of that style guide, I respect that guide and I think great software was built using it (starting from the search engine used by billions of people worldwide).
While with the help of Intellisense the reference parameters can be accepted, if you read plain source code I think having a form of syntax to specify at the call site that a parameter is going to be modified and a pointer is actually passed is a good point.
>but now with the addition of rvalues things got much more complicated.
Yes, things are definitely more complex!
Rvalue references do give you pause, I agree. I'm confident that things
will get smoothed out over time however.
I hope so
In general, I view the attitude that every programming language "should be as easy as Visual Basic" as so much noise.
I agree with you that we can't have super-easy programming languages; but I think that crossing some high-complexity line is not good.
Keep in mind that code must be maintained, so its clarity is a very important point.
For example, remaining in the domain of C++98/03, I think template metaprogramming kind of crossed an high-complexity line: writing, and especially maintaining and debugging template metaprogramming code is an highly complex (and error-prone) job,
It is important to pay attention to not cross a "read-only/write-only complexity level".
[...] I would argue that it is advanced features and uncompromising performance that ultimately keeps C++ relevant.
I think C++ gives very good performance and also offers good abstractions.
But when, after benchmarking, we identify some hot spots and want to make the performance better, we can always use low-level pure C or even manually crafted assembly code in those particular cases.