Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Re:Very much so! (Score 1) 641

And I don't care that you had problems with templates decades ago. If tens of millions of lines of code can be refactored (programmatically may I add) without significant downtime, then the template name mangling etc problem simply isn't that big of a deal.

Comment Re:Very much so! (Score 1) 641

I don't know what you think Google his, but I don't think their 100 million lines of majority C++ code is just for mail. The fact is they obviously have not encountered problems with templates that you think still exist. They refactored that monster and neither search nor mail has been reported to have been down for any significant amount of time.

Comment Re:Very much so! (Score 1) 641

No one said it can't be better. Even Bjarne Stroustrup keeps saying it needs to be better (virtually hear no other language creator say that). But you're making it out to be a lot worse than it is based on decades(?) old experience.

Listening to one of the CppCon talks, some Google engineers talked about how they refactored their entire C++ codebase to modern C++11. Have you noticed any significant downtime in Google services lately?

Comment Re: Very much so! (Score 1) 641

All languages have features that can be abused. It's a trade off. And even when operator overloading is abused in C++, they are still typesafe. You can't override them for existing definitions for other types so you'll get compile errors.

Comment Re: Very much so! (Score 1) 641

I don't know what libraries you are using, but something like the + operator in C++ is still used mostly for number and string like objects. I rarely see misuses of operator overloading these days. But that's beside the point. Yes, when you see hs.add(elem), it's obvious it belongs to hs. But you still don't know what hs or elem is unless you look it up. But in C, you do not have member functions. You have free functions add(hs, elem). And if the person decided that their library requires that add(...) work with a multitude of types, they would make the arguments tagged structs or void pointers, leaving you with even more cognitive strain to look at all the different conditional states in the add(...) function that handle all the different combinations of types explicitly. And that also doesn't guarantee that inside the add(...) function it treats all possible combinations of arguments with equivalent semantics.

Not to mention that, actually, C has some implicit operator overloading as well. You can add pointers and integers together and it behaves differently to adding integers. You will have to look up the actual types of the operands to figure out what the semantics are and that has caught out many good programmers.

For any complex software libraries, whether written in C++ or C, I have never encountered one where I never needed to keep referring to the types of the operands anyway, so the cognitive strain is mostly equivalent.

Comment Re:C is very relevant in 2014, (Score 1) 641

There has to be a point when you encounter the n-th buffer overrun that could, I don't know, compromise the security of the internet, before you realize "hey, maybe it's not stupidity or carelessness that people still create and miss these bugs" and you don't want to spend anymore effort having to deal with it when it should no longer be a thing in the modern world.

Comment Re:Very much so! (Score 1) 641

You'd prefer having to specify that you're printing a long long and not a short rather than letting the compiler figure that out for you (through operator overloading)? You'd prefer having to waste time looking up format specifiers or waste brain power remember them?

Comment Re:Very much so! (Score 1) 641

They're only countless if you're a compiler developer or a standard library author. You can definitely count the features if you're just an end user programmer. Here they are:

Constructor/destructor pairs, containers/algorithms, lambda expressions.

That's three things that you need to know. The most interesting of the three is the container/algorithm duality. Just look at Sean Parent here replace a page and a half of code C-like C++ code with 5 lines of proper C++ https://www.youtube.com/watch?... using nothing but algorithms.

I'd argue you'd actually need to learn LESS in order to learn what algorithms such as rotate or stable_partition do than having to write it out all the time.

Comment Re: Very much so! (Score 1) 641

The operator overloading argument is nonsense. You can say the exact same thing about any kind of function overloading. In Java, ArrayList.add is a completely different method to HashSet.add. You would similarly have to look up the type of object you're calling the add method of to figure out what it does. And even then you're not guaranteed that name is an accurate description of what it does. This is nothing to do with C++ but name overloading in general. For example, you can rewrite your example using no operators: assign(i, multiply(j, 5)) and you will still not know what it does without looking at the types of the arguments and the specification of the functions.

Name overloading of any sort is essential if you want a language to support generic code easily and cleanly. Otherwise you get the even worse C macro hacks that don't blow up on compile. Templates blow up on compile, and once you stop being afraid of it, it actually makes generic coding a lot easier to manage than macros.

Slashdot Top Deals

BLISS is ignorance.

Working...