I considered it outdated back in 1993, when all major GUI based systems (Apple, IBM, Microsoft) were going with C++ for userspace applications.
Then came the rise of FOSS adoption, with the GNU manifest asserting to use only C as compiled language.
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."
For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.
I'm confused. What is a matter of skill? You linked 6 hour livestream where person is working on translating AVR assembly to 6502. What was your point, that translating assembly or executables to another architecture takes a lot of skill? Yes, it does!
Because I could not, by scrubbing that video, find anything where immense skill is used to deal with the enormous overhead that standard C++ forces on every program that uses it.
It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable.
By the way, the famous Arduino and ESP32 hasve no problem dealing with C++.
As we also didn't, back in MS-DOS, with 640 KB, Turbo Vision and Borland Collection Library (BIDS).
> standard library isn't a requirement for each executable.
So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries.
It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions and most of standard library. If you need to implement your own STL subset to satisfy the library, then modify the library to work with your STL, the resulting API is not much of an API, is it?
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding.
It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.
C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library!
You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!
These are great, thanks!
That GBA "butano" compiles with -fno-rtti -fno-exceptions, so it is not a C++ engine/library according to C++ standard! It is, however, an impressive piece of work.
The ESP32 SDK (I lol'd at your "even", those Xtensa/RISCV chips can even run linux kernel!) is extremely impressive - they support enabling/disabling rtti and exceptions (obviously disabled by default, but the fact they implemented support for that is amazing). So "real C++" is possible on ESP32, which is good to know.
For comparision, here are the minimum SQLite dependencies from the submitted article: memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()
Of course you could run javascript and erlang on MCU too, but is that API better than C? Your claim of "skill issue" sounds like RedBull challenge. Please let us unskilled people simply call library functions.
Helium is based on ungoogled-chromium. It enables manifest v2 by simply reverting some code changes made by google. So, if google decides to remove manifest v2 wholly, helium will also lost its ublock original support.
Removing all manifest v2 support is also a code change that can be reverted. Of course, the larger the change, the more work it's likely to require to maintain it in the future.
reply