21–30 of 41 posts
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.
C++ was supposed to be portable. When you add a layer of threading, networking, etc. you are starting to commit to specifics of operating systems. 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.
Am I missing something, or is this article virtually content-free?
Wait, the domain is called "modernescpp.com", that's Modern s Cpp... not Modern Cpp. Wow, that's not good....
So I had been looking at threading for an embedded system recently. I found Intel's Thread Building Blocks [1] 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. S…
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[1] (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).
[1] 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.
So I had been looking at threading for an embedded system recently. I found Intel's Thread Building Blocks [1] 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. S…
1: Which ARM? (Designing for a Cortex M0+ is entirely different from an M3 is from ...) 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 com…
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).
So I had been looking at threading for an embedded system recently. I found Intel's Thread Building Blocks [1] 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. S…
1: Which ARM? (Designing for a Cortex M0+ is entirely different from an M3 is from ...) 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 com…
Just look at this[1] (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).
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:
https://software.intel.com/en-us/forums/intel-threading-buil...
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.
It's been five years (and two standard revisions). Can we stop calling C++11 a new standard?
My recollection is that C99 took roughly ten years to go from "the new thing" to "normal".
It's been five years (and two standard revisions). Can we stop calling C++11 a new standard?
C++ was supposed to be portable. When you add a layer of threading, networking, etc. you are starting to commit to specifics of operating systems. 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.
Also, the technical specification for parallel STL algorithms might make interesting reading: https://isocpp.org/files/papers/P0024R2.html
