[mapguide-internals] RFC60 - Memory Management & Object
LifeCycle Issues between Mdf Parser and runtime Maps
traian.stanev at autodesk.com
Fri Mar 20 11:24:58 EDT 2009
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?
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
Can someone please shed some light on those lifecycle issues?
I try to investigate with the debugger but its quite tedious with so
I think this is essential to prevent memory leaks.....
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals