I'm sorry the discussion got off track about the relative virtues of C++ for embedded programming.
Our need is to run parts of existing C++ code (the px4 http://px4.io/ library for drones) under OP-TEE. The C++ features we need support for thus are the ones used there, and we'd like to change it as little as possible.
So far, I've heard the risk that C++ binaries get large if you include libstdc++ features such as cout. Ok. See my footnote (*) below.
Size aside, what other properties of OP-TEE are risking conflict with C++'s runtime that anyone already knows of?
- Godmar
(*): In this context, I've found a FAQ entry describing why they have such large object files https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.size and mentioning a garbage collection feature of the GNU linker, which I hadn't heard of. It reduces the size for the static Hello World program from a roughly 1.7M text section to 1.3M text:
$ cat hello.cc #include <iostream>
int main() { std::cout << "Hello, World\n"; }
$ g++ -static hello.cc -o hello $ size hello text data bss dec hex filename 1711137 33580 18056 1762773 1ae5d5 hello $ ls -l hello -rwxrwxr-x 1 gback gback 2181416 Aug 12 10:34 hello
$ g++ -static -Wl,--gc-sections hello.cc -o hello $ size hello text data bss dec hex filename 1321767 24388 16424 1362579 14ca93 hello $ ls -l hello -rwxrwxr-x 1 gback gback 1567592 Aug 12 10:34 hello
On Sat, Aug 12, 2017 at 1:55 AM, Jeffrey Walton noloader@gmail.com wrote:
On Sat, Aug 12, 2017 at 1:27 AM, Michael Zimmermann sigmaepsilon92@gmail.com wrote:
That also depends on what you want to use C++ for. If you just want to use the convenient syntax and language features then you don't need to link against any additional library. In that case you'd disable exceptions and rtti and implement new/delete using malloc/free.
Instead of pounding a round peg into a square hole with C++, maybe the path to pursue is GCC support for try/finally in C. You get most of the semantics you are looking for, and someone as experienced as you will know exactly what to do with the feature.
Lack of try/finally support means library often do awful things. Asterisk was full of issues, like resource leaks, that try/finally would have fixed. Eventually Asterisk moved to nested/inner functions and trampolines. They silently lost NX stacks, which was a cure as bad as the disease. It just moved problems around rather than fixing them.
Microsoft compilers support try/finally in C. I recall a GCC bug report years ago asking for it, but it was declined.
Jeff