Wow, that's not good....
> Because the roots of my blogs are in German, I will continue to call him Modernes C++. That is not by mistake.
Not saying it's a good decision...
neuter, was that intentional?
But that doesn't change the age of the standard, or the fact that C++14 was published, and the Committee is finishing up C++17. At some point it's silly to call C++11 "new." "Unfamiliar," sure, but not "new." It reminds me of Larry Wall's talk ( http://www.wall.org/~larry/pm.html ) "Do you know when New College was founded. Any guesses? New College was new in 1379."
My recollection is that C99 took roughly ten years to go from "the new thing" to "normal".
For example TI.
I found Intel's Thread Building Blocks  which looked exactly like what I wanted.
Unfortunately, there are some long-standing issues with the ARM port, to the point that the included unit tests take a long time and/or crash on ARM (in this case it was on a Nvidia Jetson TK1).
If I had more time and expertise, I'd have tried to debug that further.
So is there anything else in that direction I should be looking at?
2: What are your design contraints? (Do you have hard-real time requirements? If so, you're probably going to want to use the primitives that come with the RTOS (QNX/Green Hills Integrity/all-the-major-players have their own method of "IPC/threading/whatever you want to call it" and it's usually an Erlang-esque message passing component.)
3: I'm presuming you're going for automotives, in which case lol, TBB rules but you'll never get ISO 26262 certification using it. If it's for an entertainment thinger just use QNX like everyone else.
4: "Unit tests take a long time and/or crash.." I'm sure the TK1 has ETM (which is better than bondout chips, seriously).
Just look at this (then get your manager to bring me in as a consultant - it pains me to hear you have "long-standing issues with an ARM port" and the way your team-lead thinks he can solve it is with unit tests). "Long time to load which sometimes fails entirely" is a race condition. Insure++ is the "Coverity" for embedded (just as expensive, just as wonderful).
 http://i.imgur.com/wcqlon7.png -- how your team lead should be actually debugging embedded components. If you give me more details re: your system/functional/integration requirements, I can likely tell you in which direction to move though.
I think you misunderstand.
The platform already shipped with TBB. However, when I recompiled TBB from source, the unit tests that came with TBB (which are just peachy on my desktop) took either a long time to run, or crashed. I didn't have to write any unit tests myself.
Before doing any hardcore debugging, I looked around a little and found this:
Which still doesn't seem to be fixed correctly in the latest release. That's from 2013, hence the 'long standing issues'. I gave up on TBB before spending much time on it.
Seems compiling with the -O0 flag fixed some issues for a few chaps, worth a shot I'd imagine, though you've seemed to completed your alternate implementation for the ARM platform.
Alternatively, the TBB errors seem to be when using a gcc deriv that depends on GNU as. Now VS can build ARM binaries (at least, ARM LE bins). It'd be interesting to see if that solves the problem.
What did you end up using instead of TBB? Stock Pthreads/pth? Or did you go with something lighter? Regardless, next time you have to write for embedded stuff hopefully you have a new tool in your belt that'll save you from frustration :)
Not really, QNX is quite on the decline here. I know more than 2 major OEMs (and their suppliers) which switched to Linux. I still know some QNX users, but overall Linux looks like the more common thing fur current projects. WinCE was also a major candidate some years ago, but it's now mostly discontinued (no new Windows for Automotive version).
Dozens of follow up articles are on the blog in German.
The Author has published several German books on C++
I have never read any of the books or blog posts, so can't say anything on the quality.
Also, the technical specification for parallel STL algorithms might make interesting reading:
It's fine to keep this at a library level, and promote that library to be an standard on specific platforms. But C++ should not get tainted with OS specifics.
I only care about OS specific code when using C or C++, not any other language with richer runtimes.
Actually, C's runtime is called UNIX and is packaged as POSIX for non-UNIX OSes.
Any C or C++ developer that wants "portable" code needs to litter their code with #ifdefs, for any dependency not on the standard library.
This is what sprung to mind anyway.
I agree, it feels like not a lot, but when you look at the standardization process I think it's safe to say that healthy progress has been made on most if not all the promises made.