The 'original sin' of C++ is not having both references and pointers, but trying to remain compatible with C.

That means that Stroustrup couldn't have ditched pointers, but if he wanted to implement operator overloading for value types with same efficiency as C he needed some way to support doing that without using pointers directly: http://www.stroustrup.com/bs_faq2.html#pointers-and-referenc... http://stackoverflow.com/questions/8007832/could-operator-ov...

A lot of the nastiness of C++ comes from trying to maintain C compatibility: Special behavior for POD, most vexing parse, .h/.cc file split, everything preprocessor and many other misfeatures. Of course, there's also the flip side of it: if C++ wasn't a near-superset of C, it would have never become so popular.

Yeah I agree that C compatibility is the fail. But it's also the only reason C++ is around today. There were plenty of other compiled systems languages with OO or module systems floated in the 80s, including the quite capable Modula-2/3s, various Pascal dialects, etc. Of all of them only C++ (and Objective-C because iOS) has any relevance today. And likely because there was a kind of path to trendy-OO for existing C programmers and shops.

Surely references have intrinsic value to the programmer? They're a pointer that can't be moved or rebased. Other languages have only references, and in C++ you can use that convention and not have any extra confusion.

Except that references still can be bad: invalidated later on by an object deletion, no matter how many rules were enforced to assign the reference to begin with. And in an almost-worse sense, "sometimes" references can prevent this and sometimes not. Just not good enough, while syntactically making it harder to tell that references are being used in function calls and such.

References are crazy. There's no simple guideline to use them safely. Check this out:

    const string& s = max<string>("a", "b");
    cout << s;

Standard types and functions, const references, no warnings, everything by the book. But it crashes.

There's a similar can of worms related to slicing (treating Derived* as Base* is silently unsafe because arrays and copy constructors exist). C++ is scary.

Works for me in both C++03 and C++14? https://ideone.com/KhfGaN

Your code is not the same as my code and you're probably new to C++. I suggest trying two changes:

1) Replace max("a", "b") with max("b", "a"). Run it, look closely at the result, and be enlightened.

2) Replace max("a", "b") with max<string>("a", "b"). Run it, look at the result, and be enlightened in a different way.

As a small hint, your code invokes unspecified behavior, while my code invokes undefined behavior.

If this exercise doesn't put the fear of C++ into you, then I don't know what will :-)

Sorry, can you clarify? Adding the template argument causes a crash on idone, but I have no idea why that happens. Moreover, the output on my computer is always b\n.

EDIT: Not sure if this is it, but after some digging I've found [0] on lifetimes of temporaries. As for the lacking template argument, presumably const char* is inferred and a temporary string is constructed in main?

[0] http://stackoverflow.com/a/2784304

So first of all, max("a", "b") expands to max<const char*>("a", "b"). It computes the maximum of two pointers, without looking at the characters at all. Comparing two pointers to unrelated objects is unspecified behavior, but in this case it usually returns the second pointer.

As for max<string>("a", "b"), it implicitly converts both arguments into temporary strings, then returns a const reference to one of them. Since it's a reference to a temporary, it becomes dangling when max returns, but you can assign it to a const string& anyway. When you try to access it, you'll get garbage or crash.

Thank you for the explanation! I'll have to look out for that one...

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language, even if it might have been necessary.

I think the main pain with move semantics was that it had to be bolted on to the language later. Consider that factor, they did an amazing job with it.

No, the original sin was C's and it was the use of a separate "arrow" operator for accessing fields of a struct through a pointer. Other languages (C#, Java) successfully avoided that. C++ references allow templated code to be agnostic of whether an object is given by value or by reference, because the syntax is now more uniform.

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language

Compared to using std::auto?

Nah man. std::move is far easier to understand than trying to shove both concepts down operator=. std::unique is simply easier to use than std::auto by any real measurement.

My perhaps naive uneducated opinion: they should have added syntactic sugar for it instead of making it look like a function. A new operator perhaps.

How does adding an operator help? There are two main advantage of having move semantics in the language and at least one of them relies on the fact that moves are implicit; you can write code that will move objects if supported and copy/destroy if not (for example, when returning an object or using an intermediate value in an expression). Adding an operator erases that advantage.

The other advantage is that you can force only move semantics which allows enforcing things like ownership. Adding an operator doesn't destroy this advantage, but it is a bit silly since you're just adding line noise for something that really should be implicit anyway.

Unless you just literally don't like the spelling of "std::move" which seems pretty lame since it should be relatively rare anyway.

> A new operator perhaps.

That'd invalidate a lot of programs. Just like how the new _ operator in Java is killing a lot of code right now.

Every symbol that can be used... has been used. "Move" is the meaning of the operator in any case. Its no less readable than say... Python's __lshift__ or __add__.

What if a hypothetical new operator used only characters already not allowed in identifiers and composed of characters not allowed in contiguous operator sequences.

Consider: :=, <-=, <|, $,

AFAIK, _ isn't an operator in Java (http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#...). The language does allow _ to be used as a separator in numeric literals.

Is there a new operator in some upcoming version of the language specification?

_ is a keyword in Java 9.

It isn't an operator though, right?

That's correct, I only intended to clarify your point.