C'tors from templates

dsimcha dsimcha at yahoo.com
Sat Oct 31 15:38:49 PDT 2009


== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> dsimcha wrote:
> > == Quote from dsimcha (dsimcha at yahoo.com)'s article
> >> == Quote from grauzone (none at example.net)'s article
> >>> dsimcha wrote:
> >>>> Is there a way to run a class's c'tor on a block of memory from a template
> >>>> function?  For example:
> >>>>
> >>>> C newClass(C, CtorArgs...)(CtorArgs args) {
> >>>>     // Allocate, initialize.
> >>>>     // Want to call the c'tor that takes type CtorArgs.
> >>>> }
> >>> Deeply hidden on the Digitalmars homepage, it hints _ctor() and shows
> >>> how to correctly construct an object (if you're using dmd):
> >>> http://www.digitalmars.com/techtips/class_objects.html
> >> Yeah, I had thought of this, but apparently it doesn't work anymore.  This is
> >> called excessive encapsulation--making things so opaque that, when someone really
> >> knows what they're doing and has a good reason to mess around with the internals,
> >> they still can't.  I'll file an enhancement requesting that this be put back.
> >
> > Never mind, I realized I was doing two things wrong:
> >
> > 1.  It changed from _ctor to __ctor.
> > 2.  The class needs to define a c'tor  If it doesn't, then there's no default
> > __ctor() that takes no args.  However, this is easy to check for in a static if
> > statement.
> Walter and I talked a few times about the necessity of providing useful
> functions a la C++'s placement new in Phobos. std.algorithm offers swap
> and move, but we need some more. Please advise.
> Andrei

Basically, I've got the back end stuff for precise heap scanning (the GC
implementation itself) working.  I've got the front end stuff (the templates to
generate the pointer offset information at compile time) working.

I still need the middle end (getting the pointer offset information into the GC
for anything other than a direct call to GC.malloc).  Right now, the functions
that get called when you use the new keyword don't have access to compile time
type info, and runtime type info is too crippled to generate pointer offset info
from (which is part of why I'm doing it at compile time in the first place).  I
figured I should at least have a prototype of this functionality before I submit
the patch b/c otherwise it's not that practically useful.  The problem was that
how to run the constructor on a block of memory isn't well-documented, so it took
a while for me to figure out.

Ideally, allocating class instances and arrays in a way that provides the GC with
the information necessary for precise scanning of said objects would be the
default, but this won't happen without modification of the compiler.  Until then,
I just wanted there to be an easy, if non-default, way to do this.



More information about the Digitalmars-d mailing list