> I've since moved on to languages that weren't full of problems like this

I think you mean aren't full of those problems yet. :)

There's a lot of nasty corners in C++ but almost all of them are because it effectively has 40 years of wild success. (I say 40 because C++ inherits C's baggage and success.)

It's totally reasonable to pick a younger language with fewer warts. Become an expert in it! Be productive! Ship lots of apps.

Then, one day, decades and several versions hence, you may find yourself now dealing with all of the warts that language has accrued over time. At this point, you're too invested in it to jump ship. The marginal cost of learning a new corner case is smaller than the cost to start over from scratch and learn 2046's new hot language.

Alas, expertise is hard. Everything you learn makes you better at X but slightly disincentivizes you to learn Y, which may not even exist yet.

Java is over two decades old and one of the most widely used languages in the world. It has absolutely stood the test of time. While it does has its pain points its nowhere near as terrible as C++ and (in my opinion) is improving with new versions, and honestly, I think its a joy to program in though that might not be a "cool" thing to say. Whereas C++ is a chore to program in.

That's my opinion, maybe I'm just too used to high level programming to be "good" in C++ but my experience is C++ breaks the "principle of least astonishment" every single time I use it. For example, a simple operation like clearing a stringstream is... not straightforward.

...Or maybe I'm just not smart enough.

Well, there's not a lot of room for problems to crop up when all one can do is define classes :)

Still, here's a few for you: the design of Cloneable is considered to be a mistake, as are exception specifications. These have real negative consequences. File IO was laughably bad and completely unintuitive needing several classes for the simplest of tasks (perhaps this was fixed more recently, but funny you should mention streams).

Resource management was quite tricky to get right before try-with-resources and it still is if one wants performance. Memory leaks and resource leaks are still possible. Boxing and unboxing. The particularly weak type-erased generics.

Java's saving grace is that it's a very programmer-friendly language. No matter how much one screws up, the worst that's probably gonna happen is a null pointer exception with a nicely formatted stack trace attached. The tooling is top class. All of this means that anybody with a pulse can program in Java and get a mostly working program. It won't be a joy to use, unless one is particularly impressed by classes, methods, interfaces in abundance, class hierarchies and factories.

C++ is not like that. If one doesn't use the safer modern idioms and makes a mistake it will crash (if lucky),or act in weird ways or corrupt something. Sometimes there is no way to avoid dangerous code.

There is no nice stack trace, you have to work for it. Probably have to stare at assembly and work with a fully featured but thoroughly painful to use command line debugger that's twice as old as Java.

But it's powerful and really fast. It lets one design creatively, because it supports more abstraction possibilities. And it's not owned by any corporation, it's an international standard that runs on most platforms.

I understand why people use Java. I use C++ because it's not just a tool that gets the job done, but also a way to challenge myself to make something that requires attention and skill. If I want to, it's me and the machine without framewerks, factories, fancy IDEs, dependency injection, package managers and virtual machines.

Like I said, Java has its pain points but Java's pain points are both being drastically improved on with time (java.time anyone?) and was never as bad (in my opinion) as C++. My main point is that Java has stood the test of time without becoming as bad as C++.

I'm not impressed by "classes, methods, interfaces in abundance, class hierarchies and factories." I find Java a joy to program in because I can just Get Shit Done™ and things do what I expect them to do.

In my old age I just want to get shit done, challenging myself is no longer very appealing. That's a personal preference though. There was a time that wasn't the case.

Obviously managed code is not for every application but its good enough for most. I am eternally grateful for C++ programmers for the applications where C++ (or other lower level languages) are needed because I wouldn't want to be doing that. I think C++ programmers, as a group, are so used to C++ idiosyncrasies that they don't see them as idiosyncrasies. That goes for any group though.

For what its worth my first language was C++ but C++ always "astonished" me.

(I've never had a problem with boxing and unboxing. Java has had autoboxing for a really long time so those days of manual boxing/unboxing are ancient history)

File IO got a rework with java.nio.

"Several classes" Are you taking about input/output streams, not file I/O?

> Java is over two decades old and one of the most widely used languages in the world.

Half the age of C++ (and it's ancestor C which is it largely compatible with).

> It has absolutely stood the test of time.

Sure, it's held up really well. It takes advantage of the fact that baking in GC, memory safety, and platform independence sweeps a lot of C++'s nastiness under the rug. Of course, those choices are also what generally makes Java unsuitable for many of the things you can do in C++.

Even so, Java has certainly acquired it's share of cruft. Primitives, type erasure, checked exceptions, Uri.equals() hitting the network (!), nested classes, covariant arrays, arrays and lists being different and arrays getting all the nice syntax, etc.

Agreed but in my opinion the cruft in Java is not nearly as bad as the cruft in C++. That's a personal opinion though, I'm mostly a Java programmer in my day job so that may cloud my perception of the language because I'm so used to it. I've never fought with Java like I have with C++.

It's URL::equals that hits the network, not URI::equals; the latter is a lot more sane. And even URL::equals often won't hit the network, because Java caches DNS lookups forever.

I realise that i am not exactly disproving your point about cruft here.

Ha, I couldn't remember if it was URI or URL and I was too lazy to look. :-/

Checked exceptions is definitely cruft. Java is also has the advantage of trying to be less things than c++. It's not a systems language and it's hardly even a desktop applications language anymore. Java has the same niches as ruby and python more than c++.

I'm seeing a few people in this thread mention checked exceptions being cruft. I haven't heard this before and was wondering about the reasoning.

Why are checked exceptions cruft?

Because in practice they lead to exceptions not being handled properly with a lot of boilerplate try catches. If you can't do anything sensible with an exception (like retry a couple of times) then they shouldn't be caught. The other alternative is chaining throws on function definitions up the call stack.

Most new libraries don't use checked exceptions. They were a good idea in theory but not in practice.

What do you think of languages like Rust, Go, or Haskell which return errors as part of the return type? That's somewhat akin to having all exceptions be checked.

This is the exact opposite of checked exceptions, it returns an error you don have to handle at all.

It turns me off go and Haskell altogether because they are languages suitable to applications. I think it's going to lead to a lot of apps in the wild ignoring errors.

Rust is a bit different because it's a systems language, it makes sense there.

I don't think it's the exact opposite at all. It forces you to "catch" the exception, but doesn't force you to do anything with it, the same as a checked exception.

Like in Go I can do:

    f, err := os.Open("foo.bar")
    

I am then free to ignore err or do something with it, but the type system forces me to at least acknowledge that it exists. It's the "compiler forces you to acknowledge the possibility of an error" that makes them pretty similar to checked exceptions in my opinion.

Yeah it's similar in that sense, but checked exceptions force you to acknowledge every type of exception that can be thrown, or one generic one. If you can't handle it then they force you to list every type of exception that can be thrown all they way up the chain.

Eh, from what I've seen, a lot of what people now consider to be the "warts" of C++ were there when I learned it in the '90s. Not all, obviously — but a lot of them, like the STL and all the relics of C, are quite old.

It seems similar to JavaScript. There were some initial good ideas and a bunch of early bad ideas and we're stuck layering improvements over that very uneven base.

Not all languages age the same way. That's the reason I enjoy writing Lisp code even if I am not paid for it. There are some warts, but it aged well.

> Then, one day, decades and several versions hence, you may find yourself now dealing with all of the warts that language has accrued over time.

What languages are getting even close to being as bad as C++ in this respect though? Java, Python and JavaScript have been around for a while now for example and they seem more opinionated in a way that stops too many warts from appearing.

C++ has undefined and compiler dependent behaviour in the core of its design which I think is the real problem. Its complexity just multiplies at an exponential rate as more features and undefined behaviour is introduced.

I would argue that there are rabbit holes in Haskell that can lead to baroque terrors of syntax on par with the C++ horrors in the article. The difference between Haskell and C++ is that Haskell code always has a well defined meaning even if it is _insanely_ terse. There is no ambiguity like with C++.

C# maybe? The amount of features in it is very rapidly nearing those of C++.

Javascript certainly has. Most people don't even seem to be writing javascript in javascript anymore.

Most languages have Undefined and Implementation specific behavior. Few languages have so carefully specified their undefined behavior as C++ though.

Undefined behavior is not specified, by definition! It is the absence of requirements, including the requirements to diagnose.

C++ has something called "unspecified behavior" also, which is stronger than undefined, because it gives requirements. It denotes some circumstances when an implementation can behave in one of a finite possible ways (none of which fail) and must choose one of them without documenting which choice is made. For instance the expression f(a(), b(), c()) can call the functions a, b and c in any of the six possible permutations of the order: no particular order is specified. (This arises due to the order of evaluation of function arguments being unspecified, together with the sequenced evaluation of function calls.)

The specifications of C and C++ contain large number of places in which they carefully state that no requirements apply to some situation. This is not a good thing; it's basically a myriad holes punched in the requirement spec, any one of which could be a pitfall.

Few languages are so chock full of holes in their requirements.

> Undefined behavior is not specified

But it is precisely specified how to invoke undefined behavior. For example when to numbers are added and they overflow the size of the type. This is carefully specified when this is or isn't undefined behavior. The C++ standard goes into excruciating detail but they have not covered everything

Compare that to many of the newer scripting languages. Elsewhere on this page I described how to recover from a segfault by setting string conversion function, which I don't think was specified anywhere. You can break some newer language by overriding innocuous function like #hash on some objects. These languages have at least as many pitfalls as C++ they are just less well described.

> Undefined behavior is not specified

> unspecified is stronger than undefined because it gives requirements.

I do not understand what you are saying.

"unspecified behavior" in C++ is a formal term denoting a situation in which requirements are in fact given. There are multiple possible requirements, and the implementation chooses which apply, without having to document the choice. So in fact something is specified, just not entirely.

"undefined behavior" refers to situations in which no requirements apply at all. (Truly unspecified in the regular sense of the word.)

Thanks, I understand your usage now.

Unspecified means the implementation has some leeway.

Undefined means the implementation can do anything.

Yes; as in "unspecified which choice".

Any examples? My experience is you will frequently be bitten by undefined behaviour in C++ if you don't know the rules well but this is very rare in other languages. It's rare you're going to get a segfault or the whole program crashing in languages like Python, Java and JavaScript.

Those languages all have heavy runtime environments; if a segfault occurs it's an interpreter bug. Whether the mistakes you can make are a result of "undefined behavior" is a different question whether from the consequences of a mistake are an abrupt termination, or an abrupt termination with a helpful error message.

This is how it works in Ruby.

In the CRuby/MRI interpretter when a segfault happens it calls the #to_s method on the current execution context, to get the some memory address and technical details. Ruby happens to be flexible enough that you can override that method. Then you can call whatever you want and you have effectly "recovered" from a segfault. The parser is totally in an inconsistent state and could crash at any moment for any reason but it works often enough people have done it live in front of audiences for talks.

It is not officially specified that I am aware of that overloading #to_s on anything allows recovering of segfaults it is intended for converting things to_strings.

For more on what I mean start reading the Ruby standard, which was about 1,500 pages last I checked. Then check the C++ standard which is about 3,000 for C++11 and then another 2,500 for the standard library. C++ with its standard library is much smaller than Ruby (in terms of the functionality provided) but has at least 3 times the specificity.

You can do the same thing in C++, either by intercepting signals on Linux, or setting up a structured exception handler on Windows. It's useful when you either A) want to attempt a recovery or B) have a complex tear down.

But in C++ you are specifying a signal handler, not overloading a string conversion function.

Imagine your surprise when you discover via dmesg that your have generates hundreds of segfault per second but a string conversion functions hid this bug.

Interesting post. Small comment: the C++11 standard has about 1300 pages, not 5500, thank goodness.

I misremembered...

So I just went and look this up the C++14 standard, or at least the nNvember draft is 1368 pages and the Ruby ISO standard is 313. I was off by a fair amount.

But this made my point more extreme. C++ has mauch smaller feature list than Ruby and the spec is more 4x the size C++ is much more specific and precise. Ruby and many other languages will use the behavior of some de-facto implementation as their standard.

Is C++ really better specified? Some languages use "the implementation is the spec" and that's bad, sure (though I'd argue it's less bad than "programs that worked on previous versions of the compiler will contain memory safety vulnerabilities on newer versions of the compiler", which is the end result of C++'s approach to undefined behaviour). But compare to e.g. Java, which has a (shorter!) spec with multiple implementations, including a well-specified memory model in the presence of threads (which weren't even specified at all by C++ until recently), and more importantly actually defines behaviour rather than specifying very carefully the wide range of conditions in which the compiler is permitted to arbitrarily break your code.

Memory is specifically hard one for C++ because it tries not to put a layer between the coder and the underlying hardware. Much of the memory model must be implementation defined.

It wasn't that long ago that we had different pointer for small fast memory and large slow memory, back when more that 64k was a real big deal. Kind of like how now video memory is a real big deal. Now we have a bunch of weird C APIs for putting things there (I presume these can be accessed from JNI or something similar), but these are temporary ugly hacks.

When video ram becomes a more common thing to refer to specifically, what will that look like in Java? That weird memory that C++ has is ready, because it has done exactly this in the past a few times. I am also looking forward to C++17 and its newer way to run std algorithms on heterogeneous executors (like GPUs).

There is nothing to "figure out". You are putting up a false narrative that this is at all a big problem in C++. You'll have to do more work than that if you want anyone to seriously believe such an outlandish claim. The only reason such syntax bugs become popular is because because C++ has a sizable chunk of the complexity-loving developer populace who are attracted to such things. The vast majority of C++ developers have never even thought about such complexities because they don't need to. In much the same way nobody really sits and thinks how weird it is that 1 == '1' is true in JS, or how you can assign an undefined variable to itself in ruby, etc etc.

Obviously this is very hard to quantify but for me the cognitive overload of being a good C++ is massively higher than for languages like Java, Python or JavaScript. C++ to me clearly has significantly more undefined behaviour, compiler specific behaviour and other quirks along with less safety nets (e.g. garbage collection, null pointer checks).

Do you really find JavaScript, Ruby, Java and Ruby harder to master than C++?

The blog post was about a possible bug in the syntax/standard itself. I pointed out that all languages have weird edge cases and buggy syntax.

If you want to discuss programming languages in general then that is a totally separate discussion. C++ is not in the same class of languages as JS or Ruby, so why would you use them interchangeably? C++ is meant for low level system programming, when performance or size are constraints on the problem you're trying to solve. The problem domain itself entails a certain amount of care.

Also, JS and Ruby are indeed just as hard to master as C++. Heck even Bash is hard to master. Case in point.

http://codegolf.stackexchange.com/questions/tagged/code-golf

I agree with most of your post. The domain of C++ and JS are widely apart. Comparing C++ and JS is hardly justified, IMHO. However if we were to compare them:

> Also, JS and Ruby are indeed just as hard to master as C++.

I have to call Bull on this part, with apologies for the tone (but I don't know any better way to put it). How on earth you can claim JS is harder than C++? C++ is doubtlessly a much more complicated language than JS, and for good reasons (albeit a good portion of those are historical). However sub-optimal JS is (for it was designed with hardly any gestation time and on a ridiculously tight schedule), it can be taught, almost completely in a matter of hours (sans the DOM). Add a couple more hours for teaching browser security models and pointers on where to find docs for everything JS.

>How on earth you can claim JS is harder than C++?

Because I didn't? Please re-read. I said any language is just as hard to master since the earlier context was obscure dark corners of C++ syntax (Which was the general topic of the article. The vast majority of C++ programmers would never have run into that syntax bug). JS has obscure syntax and my argument is that you need to expend equal effort to master it.

My comment started with "C++ FAQs are full of massively complex conundrums like this for problems you just don't get in other languages" so I was making a general comment prompted by the article.

> C++ is meant for low level system programming, when performance or size are constraints on the problem you're trying to solve. The problem domain itself entails a certain amount of care.

Agree with this but my view is you should avoid C++ at all costs if practical because of its productivity and bug risk impacts compared to other solutions. If low level is required though your options are limited.

> Also, JS and Ruby are indeed just as hard to master as C++.

We'll have to agree to disagree then because C++ is an order of magnitude more complex in my eyes. Code golf isn't a good metric to me as that's all about using obscure tricks to write as few characters as possible which isn't how you code normally. I would rather measure how easy it is to write code with minimal bugs and C++ gives you a million ways to shoot yourself in the foot.

IMO, Code golf is an excellent metric. Only someone who masters a language and knows its weird edge cases and obscure syntax can make sense of the answers, or attempt to present an answer themselves. If writing code with minimal bugs is your goal, then you don't need to master the language at all. So, I don't even know what we're arguing about. Looks like we agree on most things. So lemme ask you, can you name books (or courses) that teach C++, and devote a significant chunk (or any) of the material to cover such arcane syntax topics? Yes, C++ is complex, because the underlying hardware is complex - and you want to get as close to the hardware as possible. After all, you're basically signing up to repair and service the car yourself, versus bringing it in at the dealership.

> IMO, Code golf is an excellent metric. Only someone who masters a language and knows its weird edge cases and obscure syntax can make sense of the answers, or attempt to present an answer themselves.

To me, mastering a language is knowing how to use it in a way to solve a problem in the fastest development time with minimal bugs and maintainable code which does not match up with code golf. C++ gives you lots of ways to introduce weird bugs which isn't something code golf demonstrates.

> So lemme ask you, can you name books (or courses) that teach C++, and devote a significant chunk (or any) of the material to cover such arcane syntax topics?

The C++ Programming Language book and Effective Modern C++ are good and they're full of "don't do this or something bad will happen!" parts. I'm not really concerned about a few arcane syntax problems but I am concerned that C++ has a lot of undefined behaviour that lets you shoot yourself in the foot in a way that other languages avoid.

I really find Python harder to master than C++: in C++ you sometimes have to grapple with syntax and development tools, but after it's resolved, your program works predictably, just don't forget to enable debug symbols and core dumps in release builds. Resources are allocated and freed deterministically, the memory requirements are often obvious from code down to some additive, not multiplicative, constant.

Granted, I mostly work on embedded image processing systems, but would use C++ in any context where long-running processes and/or low latencies are required.

On a more subjective note, I'm waiting for .NET Core to mature a bit, since C# seems to have a balanced selection of features from managed and native worlds, plus a very pleasant syntax and tool support.

> nobody really sits and thinks how weird it is that 1 == '1' is true in JS

I beg to differ https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...

Sorry, I don't quite understand what your point is. You will have to be more clearer than posting a link as a reply to an obvious use of a rhetorical device. But if that was the extent of the reply then you will have to excuse me from any pedantic argument.

I can see why he is taking time off C++ -- I have read his Effective Modern C++ and it did not encourage me to want to understand the depth of C++ anymore. Ruined my desire to be an expert -- does not lead to sanity.

    “The object of life is not to be on the side of the
     majority, but to escape finding oneself in the ranks 
     of the insane.” 
          ― Marcus Aurelius, Meditations

Haha, same here. I learned C++ as my first real programming language, and I used to like the role of language lawyer at the forums. Still like the role, but now I do appreciate working with simpler (grammar-wise, not feature-wise) languages.