Orbiter 2006-P1 and VC++ 2005

[tblaxland]

It would seem there is very little penalty to statically linking everything (see Wraith's post). For those that are using VS2005 Pro, this strategy presents no problem. For those using VC++2005 Express, it would seem best to upgrade to the 2008 version to gain the static linking capability (see computerex's post).

 

[martins]

I just did a test build of orbiter and some default modules using static linking of the runtime libraries, and I realised that there is another subtle difference between static and dynamic linking that we need to take into consideration:

Any module that links the runtime libraries statically creates its own local 'heap environment'. This means that the orbiter core and the modules no longer share their heap space. In particular, memory allocated by a module cannot be deallocated by the core any more, and vice versa. This situation doesn't happen very often, but it does happen (e.g. mesh groups allocated by the module and inserted into a globally managed mesh will be deallocated by the core), and results in a crash.

Of course one could argue that cross-module memory allocation/deallocation is pretty unclean anyway and should be removed, but the upshot is that fixing this issue may require changes in the API that could break backward compatibility.

So the static linking approach isn't entirely without problems either.

 

[Donamy]

The price of progress.

 

[Wraith]

Any module that links the runtime libraries statically creates its own local 'heap environment'. This means that the orbiter core and the modules no longer share their heap space. In particular, memory allocated by a module cannot be deallocated by the core any more, and vice versa.

Not entirely. If the data you share happens to be a class with a virtual destructor, there will be correct deallocation.
Here, I've made a tiny demonstration of the matter. (Note how the HeapFree() function correctly gets the pointer that was returned by HeapAlloc() in every case.)

This situation doesn't happen very often, but it does happen...

I thought it doesn't at all, seeing pairs like ovcInit() and ovcExit().

(e.g. mesh groups allocated by the module and inserted into a globally managed mesh will be deallocated by the core), and results in a crash.

Is that even allowed? I mean eg. if I just replace a pointer to vertices in MESHGROUP to my own vertex data, what would happen to the old vertex data, that were previously allocated by Orbiter? Isn't that a memory leak?

 

[tblaxland]

Not entirely. If the data you share happens to be a class with a virtual destructor, there will be correct deallocation.
Here, I've made a tiny demonstration of the matter. (Note how the HeapFree() function correctly gets the pointer that was returned by HeapAlloc() in every case.)

And then the backward compatibility issue rears its head because older addons will probably not have such a virtual destructor.

Is that even allowed? I mean eg. if I just replace a pointer to vertices in MESHGROUP to my own vertex data, what would happen to the old vertex data, that were previously allocated by Orbiter? Isn't that a memory leak?

It seems that way.

Is it possible to do const overloading on oapiMeshGroup so that it returns a const MESHGROUP when the corresponding MESHHANDLE is const? That would mean that a vessel could not change the global mesh (a good thing?) but has the disadvantage of breaking some older addons.