SDK Question functions from vessel class destructor not called?

[fred18]

Hi all,

I just noticed that if I need to call functions in my vessel class destructors they just don't get called...

I tried also to simply log something with oapiWriteLog but nothing appears in the log...

Does anyone have an idea of why? I thought that from the destructor I could call any function I wanted. Of course I need to be careful not to "leave anything behind", but I can't even write a single word to log.

Why is that? :shifty::shrug:

Isn't the vessel class destructor called at simulation exit?

If you ask why I want to call functions from the destructor:
I need to close my log file handle, I want to be sure that some stuff is deleted etc...

EDIT:
I just found out that I had set as debugging option the "terminate orbiter process". I guess that kills orbiter like I would do with CTRL-ALT-DEL so the destructor does not get called... that would be curious anyway since the scenario is saved anyway so Orbiter knows it's quitting but it doesn't call the destructor?

 

[Urwumpe]

Did you call delete?

Usually, you are expected to delete the vessel by reacting to ovcExit.

 

[fred18]

Did you call delete?

Usually, you are expected to delete the vessel by reacting to ovcExit.

yep:

DLLCLBK void InitModule(HINSTANCE hModule) {}
DLLCLBK void ExitModule(HINSTANCE hModule) {}
DLLCLBK VESSEL *ovcInit(OBJHANDLE hvessel,int flightmodel){return new StationBuilder1(hvessel,flightmodel);}
DLLCLBK void ovcExit(VESSEL *vessel){if(vessel)delete(StationBuilder1*)vessel;}

If I choose as shutdown option to terminate orbiter process the following does not produce any log entry:

StationBuilder1::~StationBuilder1(){
	
	CloseSBLog();
	oapiWriteLogV("TEST DESTRUCTOR");
	return;
}

while if I choose to deallocate memory and open launchpad it does. So it seems that if I choose to terminate orbiter process it will be closed "brutally" without calling class destructor... :huh:

 

[Urwumpe]

Yes, then Orbiter simply deallocates all its process memory as whole, instead of letting the vessels handle their deallocation individually.

Has the advantage that memory leaks are no issue.

AFAIR, there is a ExitSimulation callback, but I am not sure, if it is also available for vessel modules.

 

[fred18]

AFAIR, there is a ExitSimulation callback, but I am not sure, if it is also available for vessel modules.

If you refer to clbkSimulationEnd I think it's just for modules, like plugins. I don't know if there is a way to call it from vessels or within a vessel code somehow...
maybe using the old, deprecated and ugly opcCloseRenderViewport ?

 

[jedidia]

Does anyone have an idea of why? I thought that from the destructor I could call any function I wanted.

You can. The question is, is your destructor called in the first place? The thing is, destructors aren't polymorphic by default in C++. They need to be virtual, or they won't be implicitly called when the destructor of the base class is called. This had tripped me up too, once, and what you're describing very much sounds like this might be your problem.

 

[fred18]

You can. The question is, is your destructor called in the first place? The thing is, destructors aren't polymorphic by default in C++. They need to be virtual, or they won't be implicitly called when the destructor of the base class is called. This had tripped me up too, once, and what you're describing very much sounds like this might be your problem.

So does it mean that I have to declare my destructor as virtual? from what I read from the net it seems that is the base calss destructor that needs to be virtual, but of course I have no access to that. I tried to make my destructor virtual but it doesn't get called if orbiter shutdown is to terminate process.

 

[jedidia]

from what I read from the net it seems that is the base calss destructor that needs to be virtual, but of course I have no access to that.

Uhm yes, of course. Never mind, I was confused there for a moment. If your class derives *directly* from VESSELX, this can't be the problem.

I just found out that I had set as debugging option the "terminate orbiter process".

That thought crossed my mind, but it would kind of surprise me if it were the case. I would still expect orbiter to go through the shutdown routines, just to also close the launchpad afterwards, but I never tried this.
Here's a little experiment you can do: Delete your vessel in the scenario editor. If that invokes your constructor, then it seems likely that orbiter does in fact not call any destructors when that option is set.

 

[fred18]

That thought crossed my mind, but it would kind of surprise me if it were the case. I would still expect orbiter to go through the shutdown routines, just to also close the launchpad afterwards, but I never tried this.

this was exactly my thought! but it isn't the case: if I change the option to deallocate memory and get to the launchpad the destructor gets called properly. So the conclusion is that if you have the "terminate orbiter process" as an option the destructor is not called.
I used that option not for particular memory reasons but because while developing I open and close orbiter many times and with that I saved myself from having to also close the launchpad everytime but just get back to the code by hitting ctrl+q.