From: David Abrahams (dave_at_[hidden])
Date: 2003-05-19 04:18:00
Anthony Liguori <anthony_at_[hidden]> writes:
>>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 of memory.
That's not what I mean. I mean, "I give you the blob of memory, you
put an object in it", or "if the blob is big enough, put the object
there". I guess you can do that with allocators, too.
> Since the C++ standard does not allow allocators to have any state,
Oh, but it does. They're even encouraged to have state!
5 Implementors are encouraged to supply libraries that can accept
allocators that encapsulate more general memory models and that
support non-equal instances. In such implementations, any requirements
imposed on allocators by containers beyond those requirements that
appear in Table 32, and the semantics of con- tainers and algorithms
when allocator instances compare non-equal, are
It's just that it also gives the containers permission to treat them
as though they have no state. Twisty, eh? ;-)
Actually, the containers may only assume there's "one state per
allocator type", but not that there's no state whatsoever.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk