Eliminate class allocators and deallocators?

Leandro Lucarella llucax at gmail.com
Wed Oct 7 13:30:25 PDT 2009


Andrei Alexandrescu, el  7 de octubre a las 15:23 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el  7 de octubre a las 14:16 me escribiste:
> >>Sean Kelly wrote:
> >>>== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >>>>dsimcha wrote:
> >>>>>== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >>>>>>It is a bad idea because distinguishing between release of (expensive)
> >>>>>>resources from dangerous memory recycling is the correct way to obtain
> >>>>>>deterministic resource management within the confines of safety.
> >>>>>This is based on two faulty assumptions:
> >>>>>
> >>>>>1.  Memory is cheap.  (Not if you are working with absurd amounts of data).
> >>>>>2.  Garbage collection is never a major bottleneck.  (Sometimes it's a worthwhile
> >>>>>tradeoff to add a few manual delete statements to code and sacrifice some safety
> >>>>>for making the GC run less often.)
> >>>>malloc.
> >>>So for placement construction of a class, I guess it would look something like:
> >>>
> >>>auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
> >>>x.__ctor( a, b, c ); // construct
> >>>...
> >>>x.__dtor();
> >>>free( cast(void*) x );
> >>>
> >>>Is that right?
> >>Yes, I think so, but I haven't checked all the details. For example
> >>I'm not sure whether __ctor copies .init over the memory before
> >>running the user-defined constructor, or expects that to have been
> >>done already.
> >>
> >>My understanding from Walter is that __ctor(x, y, z) are simply the
> >>functions this(x, y, z) as written by the user, so you'd need to
> >>memcpy the .init by hand before calling __ctor.
> >
> >What I don't understand is why you're willing to make that hard to do
> >manual memory management in D. Do you see that you're making the
> >programmer's job deliberately for no reason? D needs conservative GC,
> >which means slow GC; by definition. D is a system programming language, so
> >it's expected to be fast, but because of the GC there will be often
> >situations where you have to do manual MM. Why are you making that much
> >harder?
> >
> >You know that in the search for safety you'll be making much more unsafe
> >(or bug-prone) to do manual MM?
> 
> You seem to be asserting that without additional built-in language
> support, manual memory management is unduly difficult. Why so?

Because of this:

> >>>auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
> >>>x.__ctor( a, b, c ); // construct
> >>>...
> >>>x.__dtor();
> >>>free( cast(void*) x );

:)

You even forgot to register your object as a root in the GC, so if your
MyClass has any pointers to the GC your program will blow in your face.

If you plan to library support to ease this and avoid repetitive and
bug-prone work, you can ignore my complains...

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y tuve amores, que fue uno sólo
El que me dejó de a pie y me enseñó todo...



More information about the Digitalmars-d mailing list