3 ms·

On most embedded systems you cannot include std. You don't have a decent memory allocator. Bad use of templates will consume all of your flash space (code dupli

by scoutt 4y ago

On most embedded systems you cannot include std. You don't have a decent memory allocator. Bad use of templates will consume all of your flash space (code duplication). Yes, it can work for simple Arduino sketches, and I won't say that there are not complex embedded projects in C++. But... why should I want to use C++? For one, I use a small subset, like it's C with classes. I like function overloading and default argument values, initializing default values for some structs, not having to type typedef struct, the fact that for a time I could declare variables mid-function and using literal bool, true, false, etc. But full-blown C++ on embedded (MCU)? I think I'll pass.

pjmlp 4y ago
You cannot also use stdio and most stdlib, so what? You would want to use C++ for stronger type safety, proper enumerations, templates instead of undebuggable macros, namespaces,.... https://news.ycombinator.com/item?id=31406942 https://news.ycombinator.com/item?id=31406942 "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 MCUs also don't support full-blown C, and it isn't a show stopper to keep advocating it, so why should it be for a language with better safety options, even with constraints.
- scoutt 4y ago
  > You cannot also use stdio and most stdlib, so what? You can still use a subset of stdio and stdlib. Newlib also provides hooks you can use to implement fopen and the like, if you want. > better safety options Safety is not always the utmost priority. At least, not that kind of safety. It seems people forget this concept from time to time. > templates instead of undebuggable macros This is if you use complex macros, which is not always the case. I've been doing embedded for 20 years and I rarely (very rarely) find problems with macros. But you know what's undebuggable on embedded? Complex inheritance, which sooner or later you'll hit with OOP. For a system in which you don't have a screen, or logs, or any kind of output, that is usually not in your table, and you have to study failures by telling someone to look at an LED, or by guessing what could have gone wrong, you have to keep your system simple. Add templates to the mix and good luck opening the project six months later, when a customer calls with a problem. Edit: But again, used with caution, C++ can be used in embedded, at least the way I use it, as explained before.
  - pjmlp 4y ago
    The same subsets are available in C++ as well, with stronger type checking and RAII for closing those handles. Yeah, safety and IoT unfortunately aren't something that go together. Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming. The same reason you give for using macros.
    - scoutt 4y ago
      > RAII C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool. Now every function entry has: if (!m_bValid) return; I hate it. > Yeah, safety and IoT unfortunately aren't something that go together. Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priority. > Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming. So we agree. But I think you should be considering the possibility that there might be something going on between you and C, and that it could be possible that not every C developer out there is out of their mind (considering the quantity of past, present and future C projects). Make peace with C, because the world runs on C and we'll be long gone by the time C will be replaced by something else :)
      - pjmlp 4y ago
        In the history of C++, RAII predates exceptions by several years. When I got introduced to C++, via Turbo C++ 1.0 for MS-DOS in 1993, I decided that there was hardly a reason to use C other than being forced to use it by external reasons. Thankfully there are plenty of places that have moved beyond running on C. :)
        scoutt 4y ago
        > beyond running on C Can we agree that for at least the past 25 years, 99% of devices runs on C and/or depends on C and/or relies on C, or its development ran/relied/depended on C? From Windows/MacOS/Linux kernels up to the FW in your mouse, keyboard, monitor and HDD controllers. It's difficult to escape C :)

by scoutt 4y ago

pjmlp 4y ago

You cannot also use stdio and most stdlib, so what? You would want to use C++ for stronger type safety, proper enumerations, templates instead of undebuggable macros, namespaces,.... https://news.ycombinator.com/item?id=31406942 https://news.ycombinator.com/item?id=31406942 "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 MCUs also don't support full-blown C, and it isn't a show stopper to keep advocating it, so why should it be for a language with better safety options, even with constraints.

scoutt 4y ago
> You cannot also use stdio and most stdlib, so what? You can still use a subset of stdio and stdlib. Newlib also provides hooks you can use to implement fopen and the like, if you want. > better safety options Safety is not always the utmost priority. At least, not that kind of safety. It seems people forget this concept from time to time. > templates instead of undebuggable macros This is if you use complex macros, which is not always the case. I've been doing embedded for 20 years and I rarely (very rarely) find problems with macros. But you know what's undebuggable on embedded? Complex inheritance, which sooner or later you'll hit with OOP. For a system in which you don't have a screen, or logs, or any kind of output, that is usually not in your table, and you have to study failures by telling someone to look at an LED, or by guessing what could have gone wrong, you have to keep your system simple. Add templates to the mix and good luck opening the project six months later, when a customer calls with a problem. Edit: But again, used with caution, C++ can be used in embedded, at least the way I use it, as explained before.
- pjmlp 4y ago
  The same subsets are available in C++ as well, with stronger type checking and RAII for closing those handles. Yeah, safety and IoT unfortunately aren't something that go together. Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming. The same reason you give for using macros.
  - scoutt 4y ago
    > RAII C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool. Now every function entry has: if (!m_bValid) return; I hate it. > Yeah, safety and IoT unfortunately aren't something that go together. Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priority. > Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming. So we agree. But I think you should be considering the possibility that there might be something going on between you and C, and that it could be possible that not every C developer out there is out of their mind (considering the quantity of past, present and future C projects). Make peace with C, because the world runs on C and we'll be long gone by the time C will be replaced by something else :)
    - pjmlp 4y ago
      In the history of C++, RAII predates exceptions by several years. When I got introduced to C++, via Turbo C++ 1.0 for MS-DOS in 1993, I decided that there was hardly a reason to use C other than being forced to use it by external reasons. Thankfully there are plenty of places that have moved beyond running on C. :)
      - scoutt 4y ago
        > beyond running on C Can we agree that for at least the past 25 years, 99% of devices runs on C and/or depends on C and/or relies on C, or its development ran/relied/depended on C? From Windows/MacOS/Linux kernels up to the FW in your mouse, keyboard, monitor and HDD controllers. It's difficult to escape C :)