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 21:01 +0100, Milosz Derezynski wrote:
> > Is there any particular reason you're not passing the args to the
> > ctor? As we all know C++ rather likes
> > init-with-ctor-rather-than-init()-method
>
> C++ might, but lots of experts with real life experience of C++ in cases
> where exception-during-construction is real and problematic suggest that
> the init-with-ctor doesn't fit well in that scenario.

I was gonna make a witty retort but I can't think of anything that
rhymes with expert.

Anyway, the real point is that there is no *real* reason for this
(that I've ever read).

But if someone will point one out, I'll scratch my head on why all my
software works. with as near as I can tell no leakage or anything.
(And my stuff runs for days and weeks at time, so I'm 80% ish certain
its not leaking.

And yes, there are times where I do throw from constructors.

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.

> i agree with you that if its not so much of an issue, then you
> suggestion of:
>
>     MyFancyWidget* w = 0;
>
>     try {
>         w = manage (new MyFancyWidget(some, args, it, might, need));
>     }
>     catch (....
>
> is perfectly sensible.
>
> --p
>
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list

Although, I will just say again, this is all in the realm of
preference. I've never read one solid argument on why you *must* do
one or the other.

Paul Davis