Re: Good style for memory management?

["Paul Davis" <pjdavis engineering uiowa edu>]

On 3/18/07, Paul Davis <paul linuxaudiosystems com> wrote:
> On Sun, 2007-03-18 at 16:40 -0500, one of a multiplicity of Paul Davis's
> wrote:
>
> > And yes, there are times where I do throw from constructors.
>
> i do so often, despite what i wrote.
>
> > There are other
> > > cases where it doesn't fit either (for example, deserializing from
> > > something like XML which tends to promote HAS-A relationships but your
> > > objects are all inheritance based (IS-A)).
> > >
> >
> > I disagree.  Its just a matter of the engine you build to create your
> > objects.  And the first two thoughts that came to my mind were either
> >
> > 1) Make every object have a constructor that can accept a XML tree.
> > 2) Create a set of factory objects that produce the objects using
> > their 'usual' constructors from the parsed XML.
>
> nuh-uh :)
>
> my objects all have XML-based constructors, and many have factories but
> you run into problems nevertheless. consider this:
>
> class A { public: class A(const XMLNode&); }
> class B : public class A { public: class B(const XMLNode&); }
>
> now consider an XML tree that says "this describes a B object". so the
> factory looks superficially at the XMLNode, sees this, and goes to call
> B::B (const XML&Node). so far so good.
>
> but now B::B (const XMLNode&) has to call A:A (const XMLNode&). not so
> bad. but wait a minute. what node will it pass in? if it passes the same
> node that it was handed, that means that A's XML parser has to
> understand how to get to "the A node inside any derived class's XML
> node". if it doesn't pass in the same node, it means that B has to
> figure out the right node before we've even gotten inside the body of
> its constructor (something like A::A (B::find_A_node (node)))
>
> this happens because XML encourages a heirarchy where a parent node
> HAS-A child node, but in C++, the relationship tends towards IS-A.
>
> i do have solutions for this type of design problem, but i can't say i
> like them very much. most of them involve have a virtual set_state
> (const XMLNode&) method that is called explicitly by the derived class.

I sure can't think of anything better...

I think I'd go for the B::get_A_node method or perhaps preprocess the
XML tree before instantiating the actual objects it represents.

Now I'm gonna have to think about this for awhile.  Thanks alot....

Paul