4 ms·
Probably the most important C++ ideal is that you don’t pay for what you don’t use, and you _still_ get a more expressive language than C if you don’t use those
by clappski 7y ago
Probably the most important C++ ideal is that you don’t pay for what you don’t use, and you _still_ get a more expressive language than C if you don’t use those features.
Your cons:
- Virtual functions. Don’t use them if you don’t want to incur an extra indirection.
- STL. Don’t use it if you don’t want to.
- Large binary size. Don’t spin up hundreds of template instances, problem solved.
- No RTTI? Literally a compiler switch away.
Some pros:
- constexpr
- true type safe generic programming (at the cost of code size if you get crazy with it and like TMP)
- type safe no-overhead containers (std::array, std::tuple)
- RAII ownership semantics (I.e. std::unique_ptr)
- Can still emit a C ABI
- Multi-paradigm at a language level, rather than procedural with other paradigms bolted on ad-hoc
The reason C++ (IMHO) is always a better choice than C is that if you don’t want to incur the cost of feature X, drop down to how you would do it in C and it works exactly the same and you can still use the zero-cost C++ features that will never land in C.
- codesushi42 7y agoI would agree with this assessment in most cases. The problem is it's hard to determine which language features perform worse than C. But usually the cost of being wrong is low or inconsequential for modern hardware. But it is not true for embedded systems. And the industry disagrees too, and continues to use C because of this.
- kllrnohj 7y ago> But it is not true for embedded systems. And the industry disagrees too, and continues to use C because of this. What resource constrained embedded systems even exist? Fucking lightbulbs run JavaScript these days. SmartCards have been running Java for 20 years. What is the actual market you're so up in arms about that you think is choosing C on technical merits instead of purely inertia? What is this "performance constrained embedded" market to you?
- codesushi42 7y agoWhat is this "performance constrained embedded" market to you? The very definition of embedded systems? I would say it is more much likely the many folks who work on embedded systems in C are right and do so with technical merit. And it is much more likely that it is you who is wrong. Which is quite clear as someone who seems to advocate using JS on embedded hardware for serious tasks. A detail that is seriously amusing in its own right.
- adrianN 7y agoI worked on embedded systems for trains and we used C++. Many people use C just because the chips they target only have a C compiler.
- pjmlp 7y agoWhere is that definition written on? Are we talking about PICs with 4KB, or ESP32 that would run circles around the Amstrad PC 1512 that I used to play Defender of the Crown on? A system that already had quite a few high level programming languages available for us to learn programming on. Ah maybe we are speaking about my Visa card running a set of tiny Java Card applications on 256KB, to handle my authentication processes at POS.
- kllrnohj 7y ago> The very definition of embedded systems? Microcontrollers got a lot faster and more powerful over the years. What problem in that space kept up with that speed advancement? Who is paying for hyper-optimized C/asm code instead of just spending an extra $.50 for a dual-core 240mhz ESP32? And who is doing that decision and has decided C is somehow faster than C++? > Which is quite clear as someone who seems to advocate using JS on embedded hardware for serious tasks. I never advocated for it. I said it happened.
- nec4b 7y agoCan you do high speed sampling, motor control, signal analysis,... in javascript in realtime? Usually microcontrollers have several memory region with different speeds and access characteristics. Can you fine tune in which parts of the memory part of your javascript program will go into? Can you write a driver for a high speed bus or low speed for that matter in javascript on a mcu?
- pjmlp 7y agoNo, but you can use JavaScript on ARM mbed OS, running on $5 ARM-based microcontrollers. https://os.mbed.com/javascript-on-mbed/ https://os.mbed.com/javascript-on-mbed/ On Samsung's SmartThings embedded devices https://smartthings.developer.samsung.com/docs/index.html https://smartthings.developer.samsung.com/docs/index.html SigFox customized IoT solutions https://build.sigfox.com/ https://build.sigfox.com/ Or on the other side from ARM mbed's offering, a beefy ARM 580 MHz with 96 MB (RAM + Flash), using JavaScript alongside Rust. https://tessel.io/ https://tessel.io/ Now if your only definition of embedded are constrained micro-controllers that aren't even able to cope with standard ISO C89 without having additional proprietary compiler extensions, then naturally everything else are just miniature desktop computers. Meanwhile some forward looking companies keep on delivering innovative products.
- nec4b 7y agoParent poster wondered if there were such embedded applications that can't be done with javascript. And I listed some. That doesn't mean i'm implying that javascript can't be use on a MCU! Where did you get that idea from? I don't think I ever gave a definition of an embedded system, but you can quote me to prove me wrong. A PC embedded in a slot machine for instance can also be called an embedded system. A more important distinction is whether the system must run in real time or not. And you can have a beast of a microprocessor and you will not be able to do low level real time processing with it in javascript.
- jstimpfle 7y ago> RAII ownership semantics (I.e. std::unique_ptr) RAII is baad for performance. Really bad. It's an OOP programming style that can be used to glew a few high-level constructs together. But if you use it on the lower levels, you will miss out on a lot of (systemic) optimization possibilities, because RAII gives you piecemeal construction/destruction pairs. constexpr/generic programming might have a few nice applications, but in most places they're used without a real need (from what I've seen), while leading to extremely slow compiles. (Those in turn lead to longer turnaround times, worse program quality, worse efficiency...). std::array, like std::vector, is some nice sugar compared to the C primitives, but if you use them at API boundaries you will get bad coupling effects. The C++ programmers that I look up to all write basically C with maybe a few select C++ features. Many never write "class" and never include C++ headers. Some just write plain C.
- z_open 7y agoIf C++ is just as fast as C except when it's not, then it's not as fast as C. More importantly, it's not easy to tell when you're going to hit performance issues with C++. You need an obscene amount of knowledge of both the language as well as hardware to get a sense of what to use to match C performance.