Skip to main content
gamedev.net
🔒 Locked

Destructor Problems

Started by llvllatrix 9 replies 1.4k views
Original Post
llvllatrix
llvllatrix
Heres the situation: I have a memory allocator that logs memory errors and a logger class. Both are singletons. When the allocator gets destroied I want it to log a few error. The problem is that doing that requires use of the use of the logger. How do i make sure that the memory destructor gets called before the logger destructor? All i can think of is doing an unitialize function and calling that somewhere in d code.
JOL
JOL
I don''t know if this would work but how about letting the allocator and logger be wrapped in another class as a static members or something similar, the static members will be instantiated once and you could control the order of destruction...

As I said, havent really thought it through though...just a idea
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~I'm looking for work
llvllatrix
llvllatrix
hmm...How can you control the order of destruction? Sounds like a good idea tho...
tok_junior
tok_junior
Uhm, how to control the order? How about manually deleting them?
Pipo DeClown
Pipo DeClown
class A {
.
Logger* log;
.
log = 0;
log = new Logger();
.
log->logThis( "This" );
.
delete log;
log = 0;
.
};

--
You''re Welcome,
Rick Wong
- sitting in his chair doing the most time-consuming thing..
Lukerd
Lukerd
Hmm.. just an idea but cant you just call the memory destructor from inside the logger destructor?

As the logger isn''t deleted until its destructor is finished, the memory thing will deleted first.

Just me thinking aloud really

Kazade.

"To err is human, to really mess up requires a computer"
"To err is human, to really mess up requires a computer"
SiCrane
SiCrane
One approach is to use Loki''s SingletonWithLongevity implementation or more directly, its SetLongevity() function. Another approach is giving the logger re-creation semantics.
llvllatrix
llvllatrix
hmm...well i suppose the simpilest solution would be to write a destroy function for both routines and call one before the other...also maintains encapsulation.
RipTorn
RipTorn
Why not make the Log class reusable on the same log file. so it can just open and append.

In the destructor for your memory allocator, if you need to use the log, just create a local Logger object and use that. No assumptions will need to be made.


eg,
something like:

CLogger log;
log.open("mem.log");
log.append("53 memory leaks OMG pancakes");
log.close();

???

surly that is better than going to extreme lengths to make sure the compiler doesn''t destroy a static object early...

| - My (new) little website - | - email me - |
psykr
psykr
I have something like RipTorn''s idea, except for my settings manager class: each time I need to use it, I create a local object, like so:

int Width;
Setting( L"graphics_dimensions.x" ) >> Width;

The actual functionality is placed in a SettingsManager class, which the Setting class then accesses. Maybe you could do that with your Log class (create a LogString object or something).


Depending on how your singleton-ness is implemented, you could specify creation / destruction explicitly and make sure that they are destroyed in the right order.
llvllatrix
llvllatrix
quote:

Why not make the Log class reusable on the same log file. so it can just open and append.

In the destructor for your memory allocator, if you need to use the log, just create a local Logger object and use that. No assumptions will need to be made.


eg,
something like:

CLogger log;
log.open("mem.log");
log.append("53 memory leaks OMG pancakes");
log.close();

???

surly that is better than going to extreme lengths to make sure the compiler doesn''t destroy a static object early...



That sounds good...thx guys

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.