This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [I don't think it's off-topic at all] Linking speed for C++


>>>>> "Michael" == Michael Matz <matz@kde.org> writes:

Michael> Hi,
Michael> On Wed, 30 May 2001, Joe Buck wrote:
>> 
>> So the next thing to try (Michael Matz, or another interested party) is
>> to see if you can make any private data members effectively a secret
>> of the library at object code level.  This means that any inline
>> functions that access those objects should be moved to a .cxx file
>> that belongs to the same shared library as the definition of the object.

Michael> Yep, like I already wrote, simply don't allow inline
Michael> accessors.  OK, I've done that for kdecore and konsole as a
Michael> test-program (there it's only the KApplication::KApp
Michael> variable, the static instance of the application object,
Michael> which makes such problems and from which I constructed my
Michael> last example).  Still no go.  The problem now seems to be
Michael> more involved (and it seems to be different problems), I
Michael> couldn't make a small example (I'll try further), so I give
Michael> the circumstances:

Michael> one problem is our template KStaticDeleter, which serves as a
Michael> type-safe delete mechanism for objects which are allocated in
Michael> such a way:

Michael> void f() {
Michael>   static Object* o = 0;
Michael>   if (!o) o = new Object;
Michael>   ...
Michael> }

Michael> Without further means o would be a program-exit memleak, so
Michael> we have a template (for type-safety) which collects all such
Michael> objects in a list, which then is cleaned at program exit.

Why do you store static pointers to objects, instead of static
objects?  As far as I understand the standard, static objects within a
function are created the first time the function is invoked, and
destroyed in reverse order of creation - allowing such objects to
depend on global variables in their constructors.

At first sight, that apporach would let you get rid of the template
without introducing a memory leak.  Or am I missing something here?

Hildo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]