From: Ephraim V. <ef...@ep...> - 2003-03-04 18:50:03
|
Hi, I successfully compiled xml++ (0.20) on windows using msvc 6 and the pre = built version of libxml2 2.5.1 for windows. the basics seem to work, but I am truly baffled with domparser.. The example in dom_parser crashes because parser.get_root_node() returns = 0. Actually I am not surprised that this happens because I can't figure out = how and when the _private member should have been initialized to point to an Element. Can someone explain how this code is supposed to work? Thanks, -eff |
From: Stefan S. <se...@sy...> - 2003-03-05 01:20:30
|
Ephraim Vider wrote: > Hi, > > I successfully compiled xml++ (0.20) on windows using msvc 6 and the pre > built > version of libxml2 2.5.1 for windows. > the basics seem to work, but I am truly baffled with domparser.. > > The example in dom_parser crashes because parser.get_root_node() returns 0. > Actually I am not surprised that this happens because I can't figure out > how and when the _private > member should have been initialized to point to an Element. > > Can someone explain how this code is supposed to work? libxml++ is a wrapper around libxml2. The latter provides a callback mechanism to notify the wrapper whenever a xmlNode is created/destroyed. In document.cc a function 'construct' is registered with libxml2 that is responsible to allocate wrapper objects, pointed to by the various _private members. Please test whether the Document::Init constructor is actually called, as this is the place where the callbacks are initialized. It seems that isn't working right for you. May be this is a bug in msvc 6 not initializing the Document::_init object... Regards, Stefan |
From: Ephraim V. <ef...@ep...> - 2003-03-05 16:42:59
|
Thanks Stefan, Now the problem is clear - DomParser does not reference Document in any way, so that Document with its static initialization object does not get linked in if you only use DomParser. As I see it, this is a correct behavior of the linker. (why doesn't this happen on other platforms?) Which brings me to the design issue: DomParser and Document contain duplicate document access functions which are implemented twice (some even with different names - set_root / create_root). My suggestion is: Leave document access functions only in Document. DomParser will hold an internal Document instead of having only an xmlDoc. Add a get_document function to DomParser to access the Document. This is cleaner, without duplication, and solves the initialization problem. Regards, -eff ----- Original Message ----- From: "Stefan Seefeld" <se...@sy...> To: <lib...@li...> Sent: Wednesday, March 05, 2003 4:18 AM Subject: Re: [libxml++] libxml++ on win32 domparser problem > Ephraim Vider wrote: > > Hi, > > > > I successfully compiled xml++ (0.20) on windows using msvc 6 and the pre > > built > > version of libxml2 2.5.1 for windows. > > the basics seem to work, but I am truly baffled with domparser.. > > > > The example in dom_parser crashes because parser.get_root_node() returns 0. > > Actually I am not surprised that this happens because I can't figure out > > how and when the _private > > member should have been initialized to point to an Element. > > > > Can someone explain how this code is supposed to work? > > libxml++ is a wrapper around libxml2. The latter provides a callback > mechanism to notify the wrapper whenever a xmlNode is created/destroyed. > In document.cc a function 'construct' is registered with libxml2 that is > responsible to allocate wrapper objects, pointed to by the various _private > members. > > Please test whether the Document::Init constructor is actually called, as > this is the place where the callbacks are initialized. It seems that isn't > working right for you. May be this is a bug in msvc 6 not initializing the > Document::_init object... > > Regards, > Stefan > |
From: Stefan S. <se...@sy...> - 2003-03-05 16:54:31
|
Ephraim Vider wrote: > Thanks Stefan, > > Now the problem is clear - DomParser does not reference Document in any way, > so that Document with its static initialization object does not get linked > in if you only use > DomParser. Oh. When I checked in the Document type, I expected it to replace (to a great extend) the DomParser. In fact, the code I checked in made the DomParser completely obsolete. Due to various issues this move never got finished, and I'm not developing libxml++ any more. What I *would* do is change the DomParser's implementation to just wrap a Document, so DomParser will remain there, if only for backward compatibility. > As I see it, this is a correct behavior of the linker. (why doesn't this > happen on other platforms?) because that's what the ELF specs say (used on all modern unix platforms): When you load a shared library, all global (and that includes class-scope) objects are constructed. It may even be part of the C++ standard (which MS isn't very keen on). Regards, Stefan |