(Some) C++ support?

Hello,

What about some C++ support, after all? To answer question (or
outright negative statement) why that would be needed: C++ is
multi-paradigm language, and there're different uses, including -
surprisingly - right and useful. 2 typical examples of usages which may
be well target area of dietlibc too:

1. Metaprogramming - using compile-time compositional facilities (OO
and functional) to achieve high run-time efficiency, beyond C
capabilities, and within compromising high-level abstactions of target
domain.

2. Using "syntactic sugar" runtime object orientation plus things like
polymorphism.

Note that in both cases I don't talk about libstdc++ - it's optional
for C++ programming.

Giving specific example of case 2, I tried to compile Squirrel
scripting language (http://squirrel-lang.org/) with dietlibc. I had to
unbreak "diet" tool to not goto too hasty to donttouch label on seeing
something but "*cc" as a compiler, and in result I got link errors only
of following classes (each repeated multiple times of course):

sqapi.cpp:(.text._ZN13SQCollectableD0Ev[_ZN13SQCollectableD5Ev]+0x1f): undefined reference to `operator delete(void*)'
squirrel/sqapi.o:(.rodata._ZTV13SQCollectable[vtable for SQCollectable]+0x10): undefined reference to `__cxa_pure_virtual'

operator delete(void*p) would be just { free(p); }
and __cxa_pure_virtual() - { abort(); }


That's exactly what's I'd call "some C++ support" ;-). I'm not sure
how many apps would benefit from it, but at least one above will, and
it's truly good target for dietlibc (Squirrel is both tiny (~200Kb
executable and feature-rich)). More importantly, it will allow folks to
write C++ apps to be compiled with dietlibc, in really good C+
style ;-).



Just as extra note, before I patched "diet", the source was compiled
against glibc headers, and was plagued by _FORTIFY_SOURCE curse. After
I disabled it (-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0), it turned out
that when linking with static -lstdc++, then -lstdc++ contains code
compiled with _FORTIFY_SOURCE, so it's of all those *_chk symbols. So,
I even wanted to ask about an idea to provide compatibility lib, which
would just remap glibc's *_chk symbols into original function calls,
but it all was much better fixed my patching "diet" to not be afraid of
g++. And if aiming for "C++ stdlib" support, then using saner
(than glibc's libstdc++) solutions like STLPort seems like better idea.


-- 
Best regards,
 Paul                          mailto:[email protected]