7 ms·

Virtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Whi

Virtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.

pjmlp 7y ago
You mean like a Commodore 64? https://youtu.be/zBkNBP00wJE https://youtu.be/zBkNBP00wJE
- codesushi42 7y ago
  Yawn. Yes. But even C was considered too slow for something like a Motorola 68000 back in the day. Of course it's possible. Besides, C++ can be just as performant if you ignore a huge proportion of its language features and abstractions, but what's the point then? Just use C. And this is precisely why embedded engineers do so.
  - pjmlp 7y ago
    The point is that C will never have proper arrays, strings, bounds checking, real constants instead of magic defines, compile time programming, modules.
    - codesushi42 7y ago
      Yet somehow it has stayed relevant for more than 45 years. Go figure.
      - pjmlp 7y ago
        One cannot teach new tricks to old dogs. What has made relevant was the rise of FOSS UNIX clones and the GNU guidelines for using C. All major desktop OSes were already on the path of adopting C++ frameworks. BeOS, Windows, OS/2, Mac OS. Thankfully C has been shown the door on Apple, Google, Microsoft, Sony, Nintendo and ARM platforms. Others will follow. FOSS UNIX clones and old time embedded developers are the only ones keeping C relevant.
        codesushi42 7y ago
        Again, yawn. Now you are conflating embedded systems with other things. And resorting to ad hominem attacks assuming that all C programmers must be old, tired dummies. Pathetic. Heard it all before, many times. C will be just fine whether you like it or not. I also heard there's a new JavaScript framework out. Go fetch.
        pjmlp 7y ago
        First of all, the only place worthy of JavaScript is the browser. Secondly, apparently you are talking about PIC class systems as embedded, given that even a lonely ESP32 has C++ SDK support. Thirdly, AUTOSAR now advises C++14 as certification language. Do you read Embedded Magazine? Most C proud devs are using C89 alongside proprietary language extensions for their target boards + Assembly, and very resistant to any kind of improvements, not even using unit tests or static analysis tools. Old dogs indeed, I bet that until 2030 the new C++ generations will take over the remaining holdouts.
        nec4b 7y ago
        ESP32 SDK is written in C, but can be compiled with C++. All the libraries for the WiFi, BT, FreeRTOS,... are written in C. Are you one of those people who think everything before their time was bad and only what they do is worth something. I don't know why would you have such demeaning attitude towards people who laid the foundations on which we can build on. Is somebody forcing you to use C?
        pjmlp 7y ago
        My time in computing started during the mid-80's, C had hardly any meaning outside UNIX clones, on our home computers running CP/M, AmigaDOS, MS-DOS, TOS, or other mainframe platforms like VAX/VMS, ClearPath, OS/400, z/OS,.... So those of my generation know that C being the very first systems programming language, the only way to write portable code across platforms in high level languages, is a kind of cargo cult from C devs. Yes, I should have been more explicitly regarding ESP32's SDK. Point being that ESP-IDF Tools Installer supports C++.
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 ago
  I 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 ago
      What 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.

Virtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.

pjmlp 7y ago

You mean like a Commodore 64? https://youtu.be/zBkNBP00wJE https://youtu.be/zBkNBP00wJE

codesushi42 7y ago
Yawn. Yes. But even C was considered too slow for something like a Motorola 68000 back in the day. Of course it's possible. Besides, C++ can be just as performant if you ignore a huge proportion of its language features and abstractions, but what's the point then? Just use C. And this is precisely why embedded engineers do so.
- pjmlp 7y ago
  The point is that C will never have proper arrays, strings, bounds checking, real constants instead of magic defines, compile time programming, modules.
  - codesushi42 7y ago
    Yet somehow it has stayed relevant for more than 45 years. Go figure.
    - pjmlp 7y ago
      One cannot teach new tricks to old dogs. What has made relevant was the rise of FOSS UNIX clones and the GNU guidelines for using C. All major desktop OSes were already on the path of adopting C++ frameworks. BeOS, Windows, OS/2, Mac OS. Thankfully C has been shown the door on Apple, Google, Microsoft, Sony, Nintendo and ARM platforms. Others will follow. FOSS UNIX clones and old time embedded developers are the only ones keeping C relevant.
      - codesushi42 7y ago
        Again, yawn. Now you are conflating embedded systems with other things. And resorting to ad hominem attacks assuming that all C programmers must be old, tired dummies. Pathetic. Heard it all before, many times. C will be just fine whether you like it or not. I also heard there's a new JavaScript framework out. Go fetch.
        pjmlp 7y ago
        First of all, the only place worthy of JavaScript is the browser. Secondly, apparently you are talking about PIC class systems as embedded, given that even a lonely ESP32 has C++ SDK support. Thirdly, AUTOSAR now advises C++14 as certification language. Do you read Embedded Magazine? Most C proud devs are using C89 alongside proprietary language extensions for their target boards + Assembly, and very resistant to any kind of improvements, not even using unit tests or static analysis tools. Old dogs indeed, I bet that until 2030 the new C++ generations will take over the remaining holdouts.
        nec4b 7y ago
        ESP32 SDK is written in C, but can be compiled with C++. All the libraries for the WiFi, BT, FreeRTOS,... are written in C. Are you one of those people who think everything before their time was bad and only what they do is worth something. I don't know why would you have such demeaning attitude towards people who laid the foundations on which we can build on. Is somebody forcing you to use C?
        pjmlp 7y ago
        My time in computing started during the mid-80's, C had hardly any meaning outside UNIX clones, on our home computers running CP/M, AmigaDOS, MS-DOS, TOS, or other mainframe platforms like VAX/VMS, ClearPath, OS/400, z/OS,.... So those of my generation know that C being the very first systems programming language, the only way to write portable code across platforms in high level languages, is a kind of cargo cult from C devs. Yes, I should have been more explicitly regarding ESP32's SDK. Point being that ESP-IDF Tools Installer supports C++.

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 ago
I 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 ago
    What 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.