[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: another arts problem
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-02-28 22:52:08
[Download RAW message or body]

   Hi!

On Fri, Feb 25, 2000 at 02:34:02PM +0100, Stephan Kulow wrote:
> Hi!
> 
> I really wonder when even Stefan will believe in the problems of STL ;)
> 
> Greetings, Stephan
> 
> /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I.
> -I/home/kulow/prod/kdelibs/arts/flow -I../..
> -I/home/kulow/prod/kdelibs/qk -I/home/kulow/prod/kdelibs/dcop
> -I/home/kulow/prod/kdelibs/kdecore -I/home/kulow/prod/kdelibs/kdeui
> -I/home/kulow/prod/qt/include -I/usr/openwin/include
> -I/home/kulow/prod/KDE/include -I/opt/local/include
> -I/home/kulow/prod/kdelibs/arts/mcop    -g -fno-exceptions -fno-rtti
> -fno-check-new -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes
> -Wwrite-strings -Wno-long-long -fno-builtin -frtti  -c
> /home/kulow/prod/kdelibs/arts/flow/synth_play_impl.cc
> artsflow.cc: In method `PortDesc::PortDesc(const class PortDesc &)':
> artsflow.cc:80: warning: base class `class Type' should be explicitly
> initialized in the copy constructor
> /home/kulow/prod/kdelibs/arts/flow/stereofftscope_impl.cc:81: sorry, not
> implemented: object size exceeds normal limit for virtual function table
> implementation, recompile all source and use -fhuge-objects

I don't entierly understand whats happening there, and how.

However, I suppose the problem is not STL, but related to the way mcop maps
interface definitions to C++ code. Suppose you have

interface A {
};

interface B : A {
};

what gets generated is:

NotificationClient

   |
   |
   V

  Object    ---->    Object_skel

   |                       |
   |                       |
   V                       V

   A        ---->        A_skel

   |                       |
   |                       |
   V                       V

   B        ---->        B_skel

Object, Object_skel and NotificationClient exist before. All arrows indicate
virtual public inheritance. If you want to implement B, you derive from B_skel.

I can imagine that this is what bloats the vtables. Especially with multiple
inheritance already used in the interface declarations, you can imagine that
you get a complex graph of inheritance.

That said: I currently don't know when exactly entries are added to the vtable,
and how, and how large they are. Maybe one can optimize the way the mcop <->
C++ binding works, but for that I should understand what exactly is good.

From a quick scan on the net, I can only say that the gcc people are working
on optimized virtual inheritance, and some platforms (e.g. linux) enable
more of these optimizations by default than others. More recent compilers
should also perform better than oldtimers, and -fnew-abi may bring new
improvements, too.

I am really unsure how to fix this right now. Does sizeof(ClassName) indicate
something about the vtable size? How else to find that out?

Another point is: does using virtual inheritance once (in a base class) 
imply further use of virtual inheritance? I assumed that, but the sizeof
seems to change.

Maybe using virtual inheritance in stereofftscope_impl.cc and possibly
object.h (which means: class Object : virtual public NotificationClient)
will improve things?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

[prev in list] [next in list] [prev in thread] [next in thread]