couldn't allocator.construct/destruct just used for that... for memory managed types a custom allocator specialization could pass its mem mgr instance to the ctor/cctor. ok, perhaps the container classes make sense at all..., as i mentioned earlier, i didn't investigate that any further and it was only meant btw, we could discuss this off-topic, by pmsg, ...
my original message was focusing on sharing the same api so its easier for users to do dom manipulation and xpath and xslt and ... without writing code twice or build brigdes..., i hope this didn't get lost at all. that's why i asked to open the xerces dom api in a 3.x so that it is usable from xalan's point of view or vice versa, before pulling in some other libraries for xpath like pathan. tobias > > > The first of the two requirements is the killer, because it > > > essentially means that allocators cannot have instance data. > > > > I found an interesting discussion about that on comp.lang.c++: > > http://coding.derkeiler.com/Archive/C_CPP/comp.lang.cpp/2004-01/447index > .html > > where opinions go apart. > > Yes, I've read similar threads, but there's also another twist that I > didn't mention before. If you want your new "pluggable memory > management"-aware standard library containers to hold objects that also > are "pluggable memory management"-aware (meaning they require a > MemoryManager instance on construction) as values, you will need to be > able to default construct and copy-construct them with the MemoryManager > instance of the container class. That's one thing the standard will never > provide, but is provided by Xalan-C's container classes through the use of > a special traits class. > > Dave > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
