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>

    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

Reply via email to