[mapguide-internals] RFC60 - Memory Management & Object LifeCycle Issues between Mdf Parser and runtime Maps

[Traian Stanev]

You should not use Ptr<> for STL objects. It's specifically used for refcounted MapGuide API objects, which implement a specific interface (MgDisposable).

1) Children of the LayerDefinition will die if their parent dies. If you need them for longer, copy them, instead of pointing to them. Alternatively, keep the LayerDefinition alive until you are done -- this is what the rendering code does, for performance reasons.

2) I don't know what you mean. You mean the same runtime MgMap object instance?

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Friday, March 20, 2009 12:15 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 - Memory Management & Object LifeCycle Issues between Mdf Parser and runtime Maps

The style guide talks about auto_ptr and I have seen the Ptr<> template 
class being used in the code.

But so far I am using a std::list container for the collection of colors 
in the VectorLayerDefinition (making full use like sort90 and unique())
when creating the final Palette for the Image renderer.
Using the Ptr template classes on an STL container does not compile!

This now throws up some questions regarding the lifecycle of objectts

1) the MdfModel seems to have a limited lifespan.... however the 
VectorLayerDefinition is the source of the color table.
    if I take the MdfStrings from the VLD how long do the live? Can I 
keep some references or do I need to copy the Strings or Adopt them?
    Is the MdfModel shared between the runtime Maps or between sessions? 
Or is it always deserialized/serialized from a stream as a caching method?

2) Is there a possibility that the same runtime MgMap is being used for 
different baseMapGroups?

Can someone please shed some light on those lifecycle issues?
I try to investigate with the debugger but its quite tedious with so 
many threads....

I think this is essential to prevent memory leaks.....

Cheers
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals