On 11/2/05 8:08 AM, "Stefan Seefeld" <seefeld@sympatico.ca> wrote:
Daryle Walker wrote:
On 10/31/05 10:44 PM, "Stefan Seefeld" <seefeld@sympatico.ca> wrote:
[SNIP]
Here are some highlights:
* User access dom nodes as <>_ptr objects. All memory management is hidden, and only requires the document itself to be managed.
I hope there's support for custom allocators somewhere in there. (Maybe indirectly through the string type's allocator.)
Not really, as the backend does the memory allocation. Here again, as with the internal character encoding: would we impose any fine-grained user control on these implementation policies, we would reduce the set of potential backends considerably. (libxml2 lets 'users' define their own memory (de)allocators, but that is a configuration choice, and I'm not sure whether we want to bind so tightly to that.)
Why would we use a back end? Why bother making a Boost XML library if we're just going to make a wrapper that punts to a XML-specific open-source library? If we're not going to just mirror the back end, then we going to have to configure translations between our C++ front end and the back end, which could include allocations. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com