D wrapper classes leak memory. Next steps?

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 31 02:58:30 PDT 2014


On Fri, 31 Oct 2014 10:53:27 +0100
Marco Leise via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> Am Fri, 31 Oct 2014 10:51:04 +0200
> schrieb ketmar via Digitalmars-d <digitalmars-d at puremagic.com>:
> 
> > On Fri, 31 Oct 2014 09:46:54 +0100
> > Marco Leise via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> > 
> > > Can't blame the author when there is no other choice in the
> > > language than to use tracing GC with inheritance.
> > there are alot of choices. i'm succesfully using wrapper classes with
> > reference counting in my i/o streams library, for example. they are GC
> > roots, and they are freed in the same moment when their reference count
> > becomes zero.
> 
> I meant obvious, clean, idiomatic choices. It's clear that D's
> expressiveness makes pretty much anything work if you put a
> week's worth of time into it. What I'm saying is, the language
> should offer something to use external resources in class
> hierarchies, because it is a common need. Something that comes
> with so little friction that you don't think twice.

if you have something concrete in mind, write ER or forum post, so we
can destroy it. ;-)

> > > Which prompts the question again how to deal
> > > with exceptions in dtors.
> > class dtors should not throw any exceptions. stack-allocated struct
> > dtors can do what they want, just catch that and you'll got "nothrow"
> > function. what's the problem here?
> 
> E-he, stack sounds nice, but those are in D's "parameter
> scope". You cannot wrap their destruction in try-catch.

there is no problem that can't be solved by introducing one more
wrapper. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141031/3d3271b1/attachment.sig>


More information about the Digitalmars-d mailing list