From: Anthony Liguori (anthony_at_[hidden])
Date: 2003-05-18 19:50:41
>It's really interesting! :) I don't understand it, though :(
>I've never understood what people meant by "virtual constructor"
>anyway. The closest thing I can imagine is "clone() member function",
>but that doesn't appear to be quite what you're doing.
Well, I've always taken a virtual constructor just to mean a method to
allocate objects whereas the type isn't known at compile time (you can
think of virtual methods in the same light).
It's not a clone() function because a clone() function duplicates an
object. This is more similar to the java Constructor class [the return
of Class.getConstructors()]. Of course, this is a type safe version of
that concept :-)
>Can this thing handle construction in raw memory, or does it always
>do a dynamic allocation?
Sort of. Right now it uses std::allocators. One could create a
std::allocator that was a small object allocator that used one big blob
Since the C++ standard does not allow allocators to have any state, one
couldn't use it as a replacement for the placement new operator. Of
course, as I said in the original message, I would rather use a more
powerful allocator (and have the ctor_fn function objects have an
allocator object as state). Of course the trade off for this is that it
is no longer conformant to standard allocators.
I'm looking for feedback as to what folks would think the best
allocation strategy is so if you have any recommendations, I'd be happy
to hear them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk