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 <noloa...@gmail.com> wrote: > On Sat, Aug 12, 2017 at 1:27 AM, Michael Zimmermann > <sigmaepsilo...@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 > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
