I'm not exactly a fan of C++, but this isn't fair. What you're describing is more of a problem with this project's coding style than the language. Most of https://github.com/google/ion/tree/master/ion/base is covered either by the STL or Boost; most of what the C++ committee has been doing lately consists of trying to encourage people to not do what this project is doing (by improving the breadth of the standard library).

I have seen the C sub-community of C++ obsessed with things like what makes the compiler generate more optimized code, i++ or i = i + 1.

This goes for every code line that one writes, most of the time backed up by urban legends and popular beliefs instead of profiling the code.

Whereas other programming languages cultures, tend have a more meaningful approach to optimizing software.

I know a guy who works at an airline company. He's porting all the C++ and assembly code to 64 bit architecture. He genuinely did not know C++ was a seperate language from C.

To be fair, he shamelessly bragged about getting the job through nepotism.

Should be covered by core aspects of the language, and like you said its most. Its 2016, the standard library and language should handle concurrency and memory allocation which all programs have to do.

It is completely legitimate to have important features in the standard library as opposed to baked into the language itself.

"one of the serious issues with C++: numerous code files in a project authored relatively recently that are dedicated to basic application plumbing such as memory allocation/tracking and concurrency."

For some applications, manually tending to the basic plumbing is a necessity and not a burden. I.e high performance applications tend to be memory bouns.

I agree that C++ is not a right tool for every job and that as a language it has issues. But those issues are not about verbosity nor about manual memory management - the latter is rather a feature.

After decades we should have good performant ways to do those things by now, without these guys having to reinvent it.

I suppose one would need a theory encompassing most of high performance applications to achieve that.

Also, that library seems to run on a quite large subset of common platforms. I don't think there is a high level language with as painless integration to as many platforms as C++ does.

The thing with multiple platform support is that it's a really dirty realworld-bound problem. That is, no matter what one does, there will be incompatibilities and unexpected bugs. The best anyone can do, is to pick a platform with as wide userbase on the platforms one wants to support and use that if one wants to minimize headache caused by problems between third party components.

There is no joy in high level abstractions if the execution stalls on implementation related bugs.

> Educate yourselves about the nim programming language

It's hilarious that nobody recognizes blatant trolling on HN

To provide performance improvements that you don't get using the built in facilities.

You don't have to write these things yourself, but if you're trying to eke out every last drop of performance (either at runtime or build time) then you have the option to do so.

Many times it is to get the performance improvements you think you should need, but actually never will.

Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one.

And by correlation the C sub-communities from C++ and Objective-C ones.

Other communities think first into getting their data-structures and algorithms right, use the profiler and then optimize.

I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option.

Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.

These are all optimisations that I have tested and profiled though.

Which is all fine if you are coding for scenarios where every ms counts like you say.

The problem I see is when doing applications where doing the work in 100ms or 1s doesn't matter at all.

Yet one will be discussing about bounds checking impact, if i++ or i = i + 1 generate the same code and many other micro-optimizations.

For the type of work I do, I always embraced the STL and never though a second about those issues, yet I was able to fulfill the expectations.

Half of C or C++ projects have code for these types of plumbing. That's a lot of re-implementation on behalf of 'eking out performance'.

Nim is really the way to go, I don't understand why people still spend time learning slow languages with poor engineering design and concepts. Just learn NIM!

I has been written with so solving so many concepts everyone is trying to solve, but don't solve at ALL.

Just open your eyes the solution is right under your nose.

Curious notion. C++ has perhaps the richest library set in the world.

Only if you've never seen libraries for other languages: there are an order of magnitude more for the JVM or JavaScript, to name two.

I suppose in a particular area - web e-commerce and the like.

Stats for SourceForge (maybe out of date): http://www.statisticbrain.com/computer-programming-language-...

Outside performance critical areas, where shaving off KB and ms really counts, C++ has become an infrastructure language with others taking most of the work.

C++ is not relevant? What world do you work in?