4 ms·

When many of these low power chips have less than 64K of RAM, C++ is a terrible mistake. Once the program reaches even a modest level of complexity, expect blo

When many of these low power chips have less than 64K of RAM, C++ is a terrible mistake. Once the program reaches even a modest level of complexity, expect blown stacks left and right. I have had to clean-up so many of these things! And the guy who insisted on using C++ in the first place is always like, "I'll just change the compiler flags, and then it'll be OK." And that never fixes it.

pjmlp 8y ago
If we are speaking about something like a PIC with 8 KB I agree, for anything else comparable with a C64 or better, it is quite doable. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE
- jstewartmobile 8y ago
  Turner obviously understands his tools, and exercised a lot of discipline with them to write pong within a resource budget. The systems that I have encountered professionally have been uniformly more complicated, and written with less discipline, than Jason Turner's pong. And that is not to say that the people who wrote the original programs were bad programmers. In business, you're trying to beat the other companies to the finish line, so a lot of siegeworks engineering happens out of necessity. Turner had the luxury of taking his time.
  - gumby 8y ago
    The point of a language like C++ is to build the abstractions that make it possible to quickly deploy something efficient and robust. Yes, that takes some time up front, but so does designing a board!
    - jstewartmobile 8y ago
      The abstractions are not free. The cost is negligible when working with megabytes. The cost is immense when working with kilobytes. If you're doing something more complicated than toggling LEDs with one of these low-energy chips, C++ is a false economy--rapid progress in the beginning, and a slog of memory budgeting in the end.
      - gumby 8y ago
        Believe me I am used to programming machines with a KB of RAM, or even less, and small amounts of bank-switched program memory. I've been a compiler and RTOS developer, and have worked on telecom, avionics, automotive control, power generation, and instrumentation. Certainly the abstractions can be free (at runtime -- may require the compiler to do hard work, but that's what it's for). A struct that allocates some of its instance variables into memory-mapped IO space and the other ones in regular ram can reduce errors that appear from splitting representations and/or doing explicit pointer arithmetic. Can people write shitty code? Of course they can. Can you use your tools to reduce the chance that that will happen? Sure, sometimes. Let's be realistic: while some of the very best programmers I've worked on have developed high-performance embedded systems, those are very few and far between. Most people writing embedded code have low status (this is the case in Japan and China in particular) so are often not the best developers, or are hardware engineers who figure writing some code isn't all that hard (isn't necessarily, but often leads to spaghetti) or are non-embedded programmers who figure "how hard can this be?" Another commenter's reference to hearing, "well it works when the optimizer is on" is a symptom of this. Sure, people who fling around the STL on a small resource machine will rapidly suffer. But those people will fail regardless. I have built code that takes up less space with a C++ compiler than the C version.
        jstewartmobile 8y ago
        Yes, yes. Since you are so experienced, and everyone else is "low status," riddle me this: If C++ is so great, why does every joint turning out even halfway decent C++ have to subset the bejesus out of it? Even in game dev, where resources are plenty, they still subset it. Could it be that maybe, maybe, someone discovered that even competent devs do better work when a few pieces of duct tape are stuck over the sharper, rustier edges of C++. On low RAM devices, I'd subset it all the way down to plain C. Fellow low status developer Linus Torvalds would do that at the outset for any device.
wdfx 8y ago
I'm currently writing a hobby project in c++ for esp8266. I'm using about 35% DATA and 40% PROGRAM according to the compiler... seems to be ok so far (though my application does not need to allocate arbitrary memory right now, almost all is determined by initialisation). On the other hand I'm trying to export some data at work from a web app... Firefox grows to 8.9GB ram usage then reports "uncaught exception: out of memory" :(
- deleted 8y ago
  [deleted]
- octorian 8y ago
  I used C for my last ESP8266 project, which seemed mostly okay. It did involve a fair amount of HTTP request/response and parsing, where I was just careful to do things incrementally. I don't think I ever considered C++ for the project. (The most annoying thing was probably the large number of callbacks I had to track state across for anything involving a TCP socket.) For my current project, I moved onto the ESP32, where I'm also sticking with C. On this project, there's a lot less network code. Now the annoying part is the lack of built-in data structures in C. I'm making up for it with the uthash project, but I really wish it wasn't something where every project had to "roll their own" (or pull in some macro library, none of which seem to be "the standard everyone uses") C++ would definitely make the code look a lot prettier, even if only for the sake of organization. I still just hesitate, because I'd then be tempted to wrap all the C framework APIs in C++ classes which would only add to the bloat.

pjmlp 8y ago

If we are speaking about something like a PIC with 8 KB I agree, for anything else comparable with a C64 or better, it is quite doable. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE

jstewartmobile 8y ago
Turner obviously understands his tools, and exercised a lot of discipline with them to write pong within a resource budget. The systems that I have encountered professionally have been uniformly more complicated, and written with less discipline, than Jason Turner's pong. And that is not to say that the people who wrote the original programs were bad programmers. In business, you're trying to beat the other companies to the finish line, so a lot of siegeworks engineering happens out of necessity. Turner had the luxury of taking his time.
- gumby 8y ago
  The point of a language like C++ is to build the abstractions that make it possible to quickly deploy something efficient and robust. Yes, that takes some time up front, but so does designing a board!
  - jstewartmobile 8y ago
    The abstractions are not free. The cost is negligible when working with megabytes. The cost is immense when working with kilobytes. If you're doing something more complicated than toggling LEDs with one of these low-energy chips, C++ is a false economy--rapid progress in the beginning, and a slog of memory budgeting in the end.
    - gumby 8y ago
      Believe me I am used to programming machines with a KB of RAM, or even less, and small amounts of bank-switched program memory. I've been a compiler and RTOS developer, and have worked on telecom, avionics, automotive control, power generation, and instrumentation. Certainly the abstractions can be free (at runtime -- may require the compiler to do hard work, but that's what it's for). A struct that allocates some of its instance variables into memory-mapped IO space and the other ones in regular ram can reduce errors that appear from splitting representations and/or doing explicit pointer arithmetic. Can people write shitty code? Of course they can. Can you use your tools to reduce the chance that that will happen? Sure, sometimes. Let's be realistic: while some of the very best programmers I've worked on have developed high-performance embedded systems, those are very few and far between. Most people writing embedded code have low status (this is the case in Japan and China in particular) so are often not the best developers, or are hardware engineers who figure writing some code isn't all that hard (isn't necessarily, but often leads to spaghetti) or are non-embedded programmers who figure "how hard can this be?" Another commenter's reference to hearing, "well it works when the optimizer is on" is a symptom of this. Sure, people who fling around the STL on a small resource machine will rapidly suffer. But those people will fail regardless. I have built code that takes up less space with a C++ compiler than the C version.
      - jstewartmobile 8y ago
        Yes, yes. Since you are so experienced, and everyone else is "low status," riddle me this: If C++ is so great, why does every joint turning out even halfway decent C++ have to subset the bejesus out of it? Even in game dev, where resources are plenty, they still subset it. Could it be that maybe, maybe, someone discovered that even competent devs do better work when a few pieces of duct tape are stuck over the sharper, rustier edges of C++. On low RAM devices, I'd subset it all the way down to plain C. Fellow low status developer Linus Torvalds would do that at the outset for any device.

wdfx 8y ago

I'm currently writing a hobby project in c++ for esp8266. I'm using about 35% DATA and 40% PROGRAM according to the compiler... seems to be ok so far (though my application does not need to allocate arbitrary memory right now, almost all is determined by initialisation). On the other hand I'm trying to export some data at work from a web app... Firefox grows to 8.9GB ram usage then reports "uncaught exception: out of memory" :(

deleted 8y ago
[deleted]
octorian 8y ago
I used C for my last ESP8266 project, which seemed mostly okay. It did involve a fair amount of HTTP request/response and parsing, where I was just careful to do things incrementally. I don't think I ever considered C++ for the project. (The most annoying thing was probably the large number of callbacks I had to track state across for anything involving a TCP socket.) For my current project, I moved onto the ESP32, where I'm also sticking with C. On this project, there's a lot less network code. Now the annoying part is the lack of built-in data structures in C. I'm making up for it with the uthash project, but I really wish it wasn't something where every project had to "roll their own" (or pull in some macro library, none of which seem to be "the standard everyone uses") C++ would definitely make the code look a lot prettier, even if only for the sake of organization. I still just hesitate, because I'd then be tempted to wrap all the C framework APIs in C++ classes which would only add to the bloat.