Re: opinions wanted on control of extern inlines

On 27 Jul 1998 23:18:27 -0400, Rachel-Louise Koktava
<KittyCrap@severins-child.demon.co.uk> wrote:


>I wish to control the production of so called "extern inlines" during
>the compilation of c++ code. In particular, template instantiation,
>vtables and copies of inline functions are causing unacceptable levels
>of code bloat.


I ran into the same problem with gcc 2.7, and it's a big problem.


Can you move to EGCS? Or are you stuck with the vxworks compiler?


I ended up doing two things: changing the source code to make less use
of templates and virtual functions, and writing perl filters that
stripped out the redundancies from the output source files. If you
can live with this latter approach, I think it's a lot easier than
hacking the gcc sources, which are not known as being extraordinarily
self-documenting. So, for instance, if you're sick of the bloat of
the duplicated inlines, you can just run them compiler with -S and
then strip out the extra gunk with a perl filter. At least you could
test your ideas this way.


Actually, it heartens me to read about what you're doing. Perhaps you
could get Lucent to let you distribute it when you're done. I was so
shocked by the code bloat, the same things that you are seeing, that I
rewrote major pieces of my app in C, from C++. I used structs instead
of classes, and then statically initialized them (instead of having to
call constructors). Eventually I made all the overhead go away, and
the program runs much faster now as well. So by upgrading to C, from
that old klunky C++, I experienced significant space and speed
improvements.


What about my constructors and destructors? Did it by hand;
smaller and faster and not hard to read. The great advantage
is that you can statically initialize structs:


struct foo { char a; int b};
foo F = ('x', 2};


Try doing that with constructors. You can't, because the constructor
has to dynamically set the vtbl pointers. Unless I'm missing
something here (and tell me if I am, because it might help me later)
if you buy into C++ constructors, then you have to have code that runs
at startup to initialize the constructor, and also you have to have
RAM space for the object itself. Thus you need space for two objects
- the object itself in RAM, and the executable code that builds it as
a global constructor, which can be in ROM. This, even for just a
static table!! So I divided my objects into fixed and mutable parts,
statically initialized the fixed parts in ROM, and saw a great savings
in space and startup time, as I was letting the linker do much of my
startup initialization.


What about my function overloading and default arguments? Left them
in there; those are actually useful features of C++.


What about vtables and virtual functions? I use function pointers
instead; they work fine, and with a typedef or two, they are not bad
to read. They can be initialized by the linker, which again is a good
thing. I wrap them with member functions in the struct; not a bad way
to go.


What about templates? This is the biggest kludge in C++, isn't it?
They're too general, and they bloat up big-time. Yet you need
something like them, some kind of polymorphism. Most authorities now
tell us to factor out the template code into two parts: the interface
part that knows about the specific instantiated type, and the
implementation part that contains the actual algorithms themselves,
that are not templified and thus not duplicated over and over and
over, as are the template instantiations. Does this sound vaguely
familiar, like maybe you've heard it somewhere before? Well, you
have, back in your C days. In C we call them ... void pointers.


You use "void*" instead of "template x<T>". You write the algorithms
to operate on void*, and then you only have to write them (and
instantiate them) once. You typedef ("typedef void* T") and there you
are. In other words, you handle the polymorphism yourself, and you
know what? It's just not that bad. It's kind of clean, actually,
when you get it done. You sit back and look at it and think, this is
pretty cool. You can see exactly what's going on, there is none of
this private/ protected BS, and it's a lot smaller than a zillion
template instantiations would have been.


I'm not the only one who's done this. See Dave Hanson's "C Interfaces
and Implementations" for a very clean alternative to C++. You can
write C code that is every bit as polymorphic as C++ code, and nearly
as readable. Some non-C++-gurus would claim it's _more_ readable,
because there's nothing magic going on behind the scenes that can jump
up and bite you in surprising ways.


Hope this adds a little perspective.


Dwight
--

Return to the comp.compilers page.
Search the comp.compilers archives again.