libxmlplusplus-general — Open discusions about libXML++

Re: [Re: [libxml++] UTF8 support]

[Stefan S. <se...@sy...>]

Christophe de VIENNE wrote:

> node.h (could be splitted in node.h, node_qt.h and node_glib.h):

not splitting it up into separate files would indeed imply depending
on *both*. Remember that the original goal was not to provide two
unicode bindings instead of a single one, but instead to totally
factor it out, i.e. be fully agnostic of it.


> - -------
> 
> template<typename String_t>
> class Node {  // or maybe BaseNode
> 	public:
> 		String_t get_content();
> }
> 
> namespace qt {
> 	typedef xmlpp::Node<QString> Node;
> }
> 
> namespace glib {
> 	typedef xmlpp::Node<Glib::ustring> Node;
> }

This will instantiate the actual types, and thus require the full
template code to be seen. That's what Murray objects to. In order
to hide the templates you really have to use compiler firewalls 
('pimpls'), which requires more than a 'typedef': it requires
real wrapper classes. (you can't forward declare a typedef...).

Stefan

Re: [Re: [libxml++] UTF8 support]

[Stefan S. <se...@sy...>]

Jonathan Wakely wrote:
> On Wed, Mar 19, 2003 at 05:25:02PM +0100, Christophe de VIENNE wrote:
> 
> 
>>Can't we do a default behavior (compiling qlibxml++ and glibxml++ for ex) with 
>>warnings if the user compiles it with something different ?
> 
> 
> That means the default library would be dependent on glibmm *and* Qt.
> One of Stefan's objections was that he didn't want to be dependent on
> glibmm, wasn't it?

I think your interpretation of that remark is wrong. I believe what he
suggests is that two binary packages are created from one source
package. The source package then doesn't depend on either (or at least
only a slim adapter layer does), while the binary packages are
completely independent.

What I don't understand is why distinguish between 'default' and other
builds, i.e. what should the user be warned about ? The binary package
has to be named specifically for the unicode dependence anyways.

Read: from a packageing point of view, there would be a library 
'glibxml++' dependent on packages libxml2 and glibmm, which has no
relationship at all to other 'X-libxml++' packages that may exist.

Stefan

Re: [Re: [libxml++] UTF8 support]

[Jonathan W. <co...@co...>]

On Wed, Mar 19, 2003 at 05:25:02PM +0100, Christophe de VIENNE wrote:

> Can't we do a default behavior (compiling qlibxml++ and glibxml++ for ex) with 
> warnings if the user compiles it with something different ?

That means the default library would be dependent on glibmm *and* Qt.
One of Stefan's objections was that he didn't want to be dependent on
glibmm, wasn't it?

jon

-- 
"Consistency is the last refuge of the unimaginative."
	- Oscar Wilde

Re: [Re: [libxml++] UTF8 support]

[Stefan S. <se...@sy...>]

Jonathan Wakely wrote:

> To use different template params a user would have to either:
> * recompile the library so it explicitly instantiates the templates with
>   their choice of params. Maybe this could be done using clever configure
>   tricks, so when a new release of the lib is made the user configures
>   it to use their choice of string, and then just relink their apps to
>   the new lib.

I don't think this is an option (at least not the way you suggest it):

what would it mean to have libxml++ installed ? From a packaging point 
of view you'd have to ask 'is libxml++-with-glib::ustring' installed ?

In the light of this, if it is really decided to use a templated version
of libxml++ *and* hide that behind a wrapper, you would have to have 
that wrapper be explicit, i.e. something like 'glibxml++' (being the 
libxml++ library for use with the other 'g libraries'), or 'qlibxml++',
the version now compiled for use with Qt, etc., etc.

> or
> * include the definitions into their code directly, which means users
>   must recompile their apps every time the definitions change.

yeah, that's the simple solution I originally suggested, but which was
rejected from people concerned about package maintenance.

Stefan

Re: [Re: [libxml++] UTF8 support]

[Jonathan W. <co...@co...>]

On Wed, Mar 19, 2003 at 03:35:45PM +0100, Christophe de VIENNE wrote:

> About mixing the fully-templated lib and the 'normal' one :

I've been offline for a while so forgive me if I've missed anything...

> It seems (unless I misanderstood the thing) that the templates implementation 
> don't have to be included in client code as long as the templated class 
> instanciation is not done by the client code but by the lib.

Do you mean that the template classes would be explicitly instantiated
in the library? I'd been thinking about the same solution before I went
offline.
That would allow the member function definitions to be hidden from users,
but only if they want to use the templates with params that the library
has instantiated.
To use different template params a user would have to either:
* recompile the library so it explicitly instantiates the templates with
  their choice of params. Maybe this could be done using clever configure
  tricks, so when a new release of the lib is made the user configures
  it to use their choice of string, and then just relink their apps to
  the new lib.
or
* include the definitions into their code directly, which means users
  must recompile their apps every time the definitions change.

> This way we wouldn't have to a heavy wrapping : only a few typedef, and 
> provide functions to instanciate the different classes (which is already done 
> for Node).

I'm not sure I understand what you mean here.

> I'd like comments/opinions on this. If I'm not clear don't hesite to ask more 
> precisions.

I'm not sure how good compiler support is for this (I /think/ it's fine)
and am I right in thinking it delays some errors until link time, which
could be found at compile time (during the second stage of template
compilation) if the templates are instantiated automatically as the user
needs them?
One feature of explicit instantiation is that every member function is
instantiated. Usually a template's member functions are only instantiated
if they are used, which means errors can be introduced which testing
doesn't find unless every single function is called.
Explicit instantiation compiles every function so this is avoided (at
the cost of extra unused code in the object files)

I think this would be a good idea iff some autoconf trick can be done so
that the user specifies which explicit instantiations to include in the
library. Otherwise they still have to see the definitions and recompile
when the lib is updated.

A simple solution would be for the library to provide all the common
instantiations (glib::ustring, QString etc.) and conditionally compile
them according to options to configure (--with-ustring, --with-qstring).
To use the templates with new params would require compiling the
template def'ns yourself, or submitting a patch to the library to add a
new instantiation (and the new configure option to enable it).

jon

-- 
"What I tell you three times is true"
	- The Hunting of the Snark

Re: [libxml++] MSVC++6 support

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 19 Mars 2003 12:09, Ephraim Vider a =E9crit :
> the content of the win32_msvc6 dir is ok and working.
>
> but I think the dist is now broken, all I got in the tar was the
> win32_msvc6 dir
>
> If I understand correctly, DIST_SUBDIRS overrides SUBDIRS
> so it should read:
>     DIST_SUBDIRS =3D $(SUBDIRS) win32_msvc6
> (this worked for me)

Indeed. When checking the tarball I looked if the new dir was included, and=
=20
did not remark that a few other ones were missing ;)

>
> I wont post a patch - I am positive you can handle it...
>

commited.

Thanks,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+eFUvB+sU3TyOQjARAo+mAJ9JC2VPIkVNPBd19Hyj/wf0AbcPEQCeIhgZ
Ogus+IfDjYK03+Sm1w8hlPg=3D
=3D2gQ4
=2D----END PGP SIGNATURE-----

[libxml++] Re: Fix to libxml++ [node.cpp]

[Christophe de V. <cde...@al...>]

Le Mardi 18 Mars 2003 21:02, vous avez =E9crit :
> Hello Christophe,

Hi,

> I have gotten libxml++ 0.22.0 and made a few changes (see attached):
>
> 1. Created a Microsoft Developer Studio project/workspace ("win32" subdir)
> Note that DevStudio did not like the "+"'s, so I named the project
> "libxmlpp".

A patch with mvsc++ project/workspace files is being included in the CVS

>
> 2. Changed all ".cc" files in the "libxml++" subtree to ".cpp" (did not
> change examples)
> It is possible to get DevStudio to recognize ".cc" files as C++ code, but
> it does not
> do so by default. I think ".cpp" is a fairly universal C++ extension
> nowadays.
>

Well, we already spoke about this on the mailing list. We will probably not=
=20
change the file extension (unless we have _huge_ demand for that).

> 3. Fixed a null-pointer problem in "node.cpp" which was causing an
> unpleasant crash
> I notice that other pointers are not checked for null either. I could not
> tell which might
> be dangerous, so I only concerned myself with the one causing the crash. I
> think you
> can reproduce crash by removing all "linkend"'s from "example.xml".

Could you provide us a separate patch for this problem ? And putting it in =
the=20
patch manager would be even better=20
(http://sourceforge.net/tracker/?atid=3D312999&group_id=3D12999&func=3Dbrow=
se).=20
Thanks.
If you don't know how to create a path, have a look to :
http://gtkmm.sourceforge.net/bugs.shtml

>
>
> I would be happy to add DevStudio projects for the examples, but was not
> sure if you
> would accept these changes.
> Let me know if I should go about making changes
> like
> this differently (I have never done this before).

Thanks very much for your proposition, but as I said it's being done...

>
> BTW, I like the class library
> Thanks!
> Chris

Thanks.

=46or further discussion (I'm sure you'll bring us usefull contribution(s))=
,=20
please use the mailing list (http://sourceforge.net/mail/?group_id=3D12999).


Best regards,

Christophe

[libxml++] [ libxmlplusplus-Patches-704986 ] msvc support for libxml++

[SourceForge.net <no...@so...>]

Patches item #704986, was opened at 2003-03-17 16:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=704986&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ephraim Vider (eff7)
Assigned to: Nobody/Anonymous (nobody)
Summary: msvc support for libxml++

Initial Comment:
attached is the content of a win32 directory to be added 
under the root libxml++ dir. it contains workspace and 
projects for msvc 6.0
(in case you wonder - the.opt file is needed to set the 
correct working dir for the samples)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=704986&group_id=12999

[libxml++] JokoSoko - Jacado Breaking News March 18, 2003

[<ne...@mi...>]

<HTML>
	<HEAD>
		<TITLE>Jacado Breaking News - March 18, 2003</TITLE>
	</HEAD>
<BODY>

<TABLE WIDTH=580>
<TR>
<TD>

  <table><tr><td>Please click <a href=http://www.jacado.com/news/200303/20030318_JACADO_BREAKING_NEWS.html target=_blank>here</a> if you can't read this email.</td></tr></table>

  <BR>

  <A HREF=http://www.jacado.com/product.jsp?team=jacado&code=1132&title=Puzzle+Games TARGET=_blank>
  <IMG SRC=http://www.zindell.com/postcards/JokoSoko.gif BORDER=0></A>

  <BR><BR><font size=2><a href=http://www.jacado.com/product.jsp?team=jacado&code=1132&title=Puzzle+Games target=_blank>JokoSoko</a> was developed by <a href=http://www.jacado.com target=_blank>jacado</a>.
  Please click <a href=http://www.jacado.com/product.jsp?team=jacado&code=1132&title=Puzzle+Games target=_blank>here</a> for more info about this awesome puzzle game.
  If you find this puzzle game interesting, we suggest you to check some of our other magnificent puzzle games:
  <a HREF=http://www.jacado.com/product.jsp?team=jacado&code=1111&title=Puzzle+Games target=_blank>MagicTable</a>,
  <a href=http://www.jacado.com/product.jsp?team=jacado&code=1149&title=Puzzle+Games target=_blank>TriangleNumbers</a>
  and
  <a href=http://www.jacado.com/product.jsp?team=jacado&code=1119&title=Puzzle+Games target=_blank>JacadoJump</a>.
  <BR>&nbsp;<BR>

  <FONT SIZE=-2>This email was sent by Jacado news service. Please click <a href=http://www.jacado.com/remove.jsp?type=jacado target=_blank>here</a> if you wish to unsubscribe or visit at http://www.jacado.com/remove.jsp?type=jacado.</FONT>

</TD>
</TR>
</TABLE>

</body>

</html>

[libxml++] [ libxmlplusplus-Patches-704881 ] exceptions in sax_exception example

[SourceForge.net <no...@so...>]

Patches item #704881, was opened at 2003-03-17 11:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=704881&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ephraim Vider (eff7)
Assigned to: Nobody/Anonymous (nobody)
Summary: exceptions in sax_exception example

Initial Comment:
this patch changes the Clone return type for the private 
exception
and also catches all exceptions to prevent uncaught 
exceptions when a real error occurs


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=704881&group_id=12999

Re: [libxml++] Segfault in dom parser

[Thomas J. <tho...@in...>]

> > Remove example.xml and try running the included example dom_parser.
> > It should segfault. Is it a bug of the example or the library?
>
> The bug comes from the lib which doesn't check if context creation is
> sucessfull. I'll commit a patch in a few minutes.

:-)

> On context creation failure the lib will now throw an internal_exceptio=
n
> with the message "cannot create parsing context".
> If anybody think a new exception type is needed for that just tell me w=
e'll
> discuss it. In the mean time at least we'll not have a segfault.

KISS =3D Keep It Simple Stupid

Though detecting a "file not found" error
via an exception could also be nice.

Thomas

Re: [libxml++] Segfault in dom parser

[Christophe de V. <cde...@al...>]

Le Jeudi 13 Mars 2003 20:59, Thomas Jarosch a =E9crit :
> Hi,
>
> I've found a little bug I want to report:
>

Thanks

> Remove example.xml and try running the included example dom_parser.
> It should segfault. Is it a bug of the example or the library?

The bug comes from the lib which doesn't check if context creation is=20
sucessfull. I'll commit a patch in a few minutes.

On context creation failure the lib will now throw an internal_exception wi=
th=20
the message "cannot create parsing context".
If anybody think a new exception type is needed for that just tell me we'll=
=20
discuss it. In the mean time at least we'll not have a segfault.


Best regards,

Christophe

[libxml++] Segfault in dom parser

[Thomas J. <tho...@in...>]

Hi,

I've found a little bug I want to report:

Remove example.xml and try running the included example dom_parser.
It should segfault. Is it a bug of the example or the library?

Please CC: replies.

Cheers,
Thomas

[libxml++] Kill The Ducks! - Jacado Breaking News March 11, 2003

[<ne...@mi...>]

<HTML>
	<HEAD>
		<TITLE>Jacado Breaking News - March 11, 2003</TITLE>
	</HEAD>
<BODY>

<TABLE WIDTH=580>
<TR>
<TD>

  <table><tr><td>Please click <a href=http://www.jacado.com/news/200303/20030311_JACADO_BREAKING_NEWS.html target=_blank>here</a> if you can't read this email.</td></tr></table>

  <BR>

  <A HREF=http://www.jacado.com/product.jsp?team=jacado&code=1012&title=Arcade+Games TARGET=_blank>
  <IMG SRC=http://www.zindell.com/postcards/DucksHunting.gif BORDER=0></A>

  <BR><BR><font size=2><a href=http://www.jacado.com/product.jsp?team=jacado&code=1012&title=Arcade+Games target=_blank>DucksHunting</a> was developed by <a href=http://www.jacado.com target=_blank>jacado</a>.
  Please click <a href=http://www.jacado.com/product.jsp?team=jacado&code=1012&title=Arcade+Games target=_blank>here</a> for more info about this awesome game.
  If you find this game interesting, we suggest you to check some of our other coolest games:
  <a HREF=http://www.jacado.com/product.jsp?team=jacado&code=1019&title=Arcade+Games target=_blank>SpaceInvasion</a>,
  <a href=http://www.jacado.com/product.jsp?team=jacado&code=1500&title=Gambling+Games target=_blank>ClassicRoulette</a>
  and
  <a href=http://www.jacado.com/product.jsp?team=jacado&code=1015&title=Arcade+Games target=_blank>BugzBuster</a>.
  <BR>&nbsp;<BR>

  <FONT SIZE=-2>This email was sent by Jacado news service. Please click <a href=http://www.jacado.com/remove.jsp?type=jacado target=_blank>here</a> if you wish to unsubscribe or visit at http://www.jacado.com/remove.jsp?type=jacado.</FONT>

</TD>
</TR>
</TABLE>

</body>

</html>

[libxml++] [ libxmlplusplus-Patches-698972 ] DomParser as a Document wrapper

[SourceForge.net <no...@so...>]

Patches item #698972, was opened at 2003-03-06 22:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=698972&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ephraim Vider (eff7)
Assigned to: Nobody/Anonymous (nobody)
Summary: DomParser as a Document wrapper

Initial Comment:
this makes DomParser a wrapper around Document and 
removes duplicate functionality


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=698972&group_id=12999

Re: [libxml++] recursive get_children?

[Stefan S. <se...@sy...>]

Eric Bourque wrote:
> Are there plans to have a recursive Node::get_children or something
> similar? For example, the perl libxml wrapper has
> Element::getChildrenByTagName, and Element::getElementsByTagName, the
> latter of which is recursive. This is extremely handy.

Indeed. The standard way to do that is using XPath expressions
(http://www.w3.org/TR/xpath), which is supported in libxml++ by means of
the Node::find() method. Have a look into the examples, it demonstrates
how to use it.

Regards,
		Stefan

Re: [libxml++] Vote: templates everywhere v. Glib::ustring: results + I'm back

[Stefan S. <se...@sy...>]

Christophe de VIENNE wrote:

> But before the definitive choice, I would really like the discussion about an 
> intermediate solution, with specialized classes for glib::ustring and QString 
> in a library, and the possibility to use the fully templated classes, to go 
> to a conclusion.

Never mind my suggestion about using libxml++ with QString. So far I was
the only one suggesting that the two might be used together, and as I
don't use libxml++ anyways, there is really no point for you to work on
a specific libxml++_QString solution.

The question is really (IMO) whether to parametrize or not, not whether
or not to support a specific unicode implementation.


Regards,
		Stefan

Re: [libxml++] libxml++ on win32 domparser problem

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Jeudi 6 Mars 2003 14:18, Ephraim Vider a =E9crit :
> the .cc to .cpp change makes it much more natural to build with msvc, .cc
> files are not recognized as C++ files by default

I guess it's possible to override this in the .dsp/dsw files. Is it ? In th=
is=20
case I would prefer not to change the file extensions.

Christophe

PS: Could you avoid posting in HTML in the list ? Thanks very much.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Z0yaB+sU3TyOQjARAsBWAJ9nfAo+xPcC6fkKrggmQs2p39erpQCgxJ4e
occ36sQ4tkrRfsQKZaBssHg=3D
=3D6Mqu
=2D----END PGP SIGNATURE-----

Re: encoding translation (was Re: [libxml++] Libxml++ 1.0.0 soon)

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Jeudi 6 Mars 2003 12:35, Christophe de VIENNE a =E9crit :
> Since libxml has some encoding translation to do, I suspect it contains
> some functions which are able to translate UTF-8 to any encoding and vice
> versa. I had a quick look to the API and found only UTF8Toisolat1 and
> isolat1ToUTF8. But a better search is needed I think.

xmlCharEncodingInputFunc () and xmlCharEncodingOutputFunc () seems to feet =
to=20
what I was looking for.
(cf http://xmlsoft.org/html/libxml-encoding.html#XMLCHARENCODINGINPUTFUNC).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Z0vJB+sU3TyOQjARAhEXAJ98mhoJI4qDbK1mLWZWgymiaJE6rACgs5l/
geIZJv8rytIrlcqCe96vSTg=3D
=3DNyIp
=2D----END PGP SIGNATURE-----

[libxml++] recursive get_children?

[Eric B. <er...@co...>]

Are there plans to have a recursive Node::get_children or something
similar? For example, the perl libxml wrapper has
Element::getChildrenByTagName, and Element::getElementsByTagName, the
latter of which is recursive. This is extremely handy.

Cheers,

Eric

Re: [libxml++] Design Issue (was: libxml++ on win32 domparser problem)

[Stefan S. <se...@sy...>]

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

[libxml++] Design Issue (was: libxml++ on win32 domparser problem)

[Ephraim V. <ef...@ep...>]

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
>

Re: [libxml++] libxml++ on win32 domparser problem

[Stefan S. <se...@sy...>]

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

[libxml++] libxml++ on win32 domparser problem

[Ephraim V. <ef...@ep...>]

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

[libxml++] Mobizex Newsletter, February 2003

[<ne...@mi...>]

<HTML><HEAD><STYLE>
BODY {font-family="Arial"}
TT {font-family="Courier New"}
BLOCKQUOTE.CITE {padding-left:0.5em; margin-left:0; margin-right:0; margin-top:0; margin-bottom:0; border-left:"solid 2";}
SPAN.TABOOHEADER {display=none}
</STYLE></HEAD>
<BODY>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="cid:filelist.xml@01C26494.79C3D5D0">
<link rel=Edit-Time-Data href="cid:editdata.mso@01C26494.79C3D5D0">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Mobizex - Smart Utilities for Better Life</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{
	panose-1:2 11 5 0 0 0 0 0 0 0;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:3 0 0 0 1 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=white lang=EN-GB link=blue vlink=blue style='tab-interval:36.0pt'>
<a name=top></a>
<div class=Section1>


<table border=0 cellpadding=0 width=611 style='width:458.25pt;mso-cellspacing:
 1.5pt;mso-padding-alt:0pt 0pt 0pt 0pt'>
 <tr>
  <td width=607 style='width:455.6pt;padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<img
  width=604 height=46 id="_x0000_i1025"
  src="http://www.zindell.com/images/mobizexlogonews.jpg"></span></font></p>
  <table border=0 cellpadding=0 width="100%" style='width:100.0%;mso-cellspacing:
   1.5pt'>



   <tr>
    <td width="73%" style='width:73.0%;padding:.75pt .75pt .75pt .75pt'>
    <p><font size=4><span
    style='font-size:10.5pt;font-family:Arial;color:#000099'>Monthly Newsletter</span></font><a name=top></a></p>
    </td>
    <td width="27%" style='width:27.0%;padding:.75pt .75pt .75pt .75pt'>
    <p align=right style='text-align:right'><font size=4
    color="#000099" face=Arial><span style='font-size:10.5pt;font-family:Arial;
    color:#000099'>February 2003</span></font></p>
    </td>
   </tr>


  </table>
  <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3 face="Times New Roman"><span style='font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>
  <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>
  <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;</span></font></p>
  <table border=0 cellpadding=0 width="100%" style='width:100.0%;mso-cellspacing:
   1.5pt'>
   <tr>
    <td style='padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal><font size=12.5 color="#000099" face=Arial><span
    style='font-size:12.5pt;font-family:Arial;color:#000099'>In this issue</span></font></p>
    </td>
   </tr>
  </table>
  <p class=MsoNormal><font size=3 face="Times New Roman"><span
  style='font-size:12.0pt;display:none;mso-hide:all'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>
  <table border=0 cellpadding=0 width="100%" style='width:100.0%;mso-cellspacing:
   1.5pt;mso-padding-alt:0pt 0pt 0pt 0pt'>
   <tr>
    <td width="2%" style='width:2.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
    font-family:Arial'>-</span></font></p>
    </td>
    <td width="98%" style='width:98.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal><font size=2 face=Arial color="#FF9900"><span style='font-size:10.0pt;
    font-family:Arial'><a href="#a">MyStuff is one of the most popular J2ME applications in France</a></span></font></p>
    </td>
   </tr>
   <tr>
    <td width="2%" style='width:2.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
    auto'><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
    Arial'>-</span></font></p>
    </td>
    <td width="98%" style='width:98.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
    auto'><font size=2 face=Arial color="#FF9900"><span style='font-size:10.0pt;font-family:
    Arial'><a href="#b">HeartRate & BMICalc popularity sets new records</a></span></font></p>
    </td>
   </tr>
   <tr>
    <td width="2%" style='width:2.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
    auto'><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
    Arial'>-</span></font></p>
    </td>
    <td width="98%" style='width:98.0%;padding:.75pt .75pt .75pt .75pt'>
    <p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
    auto'><font size=2 face=Arial color="#FF9900"><span style='font-size:10.0pt;font-family:
    Arial'><a href="#c">Install the LottoNumbers on your mobile telephone and win the lottery</a></span></font></p>
    </td>
   </tr>
  </table>
  <a name=temporary></a>
  <p class=MsoNormal><span style='mso-bookmark:temporary'><font size=3
  face="Times New Roman"><span style='font-size:12.0pt'><o:p></o:p></span></font></span></p>
  </td>
  <span style='mso-bookmark:temporary'></span>
 </tr>


 <tr>
  <td width=607 style='width:455.6pt;padding:.75pt .75pt .75pt .75pt'>
  <p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<a name="a"></a></span></font></p>
  <p><font size=4 color="#000099" face=Arial><span style='font-size:12.5pt;
  font-family:Arial;color:#000099'>MyStuff is one of the most popular J2ME applications in France</span></font></p>
  <p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'><a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3501&title=Productivity+Applications target=_blank>MyStuff</a> is the most popular application at <a href=http://www.jeuxmobiles.com target=_blank>www.jeuxmobiles.com</a>, the number one J2ME portal in France. Other Mobizex popular Java applications in France include the following applications: <a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3103&title=Health+Applications target=_blank>Fertilax</a>, <a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3900&title=Finance+Applications target=_blank>CostManager</a> and <a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3404&title=Sport+Applications target=_blank>SportWatch</a>.
  </span></font></p>
  <font size=2><a href="#top">Back to top</a>&nbsp;&nbsp;&nbsp;<a href="http://www.jeuxmobiles.com" target="_blank">More...</a></font><BR>&nbsp;<BR></span></font></p>
  </td>
 </tr>


 <tr>
  <td width=607 style='width:455.6pt;padding:.75pt .75pt .75pt .75pt'>
  <a name="b"></a>
  <p><font size=4 color="#000099" face=Arial><span style='font-size:12.5pt;
  font-family:Arial;color:#000099'>HeartRate & BMICalc popularity sets new records</span></font></p>
  <p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>According to <a href=http://www.handango.com/pdf/HandangoYardstick4_2002.pdf target=_blank>Handango Yardstick (Fourth Quarter 2002)</a>, two of the top three health & fitness applications for Java devices, were developed by Mobizex. These two applications are <a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3105&title=Health+Applications target=_blank>BMICalc</a> and <a href=http://www.mobizex.com/product.jsp?team=mobizex&code=3104&title=Health+Applications target=_blank>HeartRate</a>. Please click <a href=http://www.mobizex.com/page.jsp?team=mobizex&topic=health target=_blank>here</a> for more info about Mobizex J2ME health applications.
  </span></font></p>
  <font size=2><a href="#top">Back to top</a>&nbsp;&nbsp;&nbsp;<a href="http://www.handango.com/pdf/HandangoYardstick4_2002.pdf" target="_blank">More...</a></font><BR>&nbsp; </span></font></p>
  </td>
 </tr>


 <tr>
  <td width=607 style='width:455.6pt;padding:.75pt .75pt .75pt .75pt'>
  <a name="c"></a>
  <p><font size=4 color="#000099" face=Arial><span style='font-size:12.5pt;
  font-family:Arial;color:#000099'>Install the LottoNumbers on your mobile telephone and win the lottery</span></font></p>
  <p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>
  Alhaji Samura (Rome, Italy) has already won the lottery using our LottoNumbers application. The next person can be you! Having with you, on your mobile telephone, a Java application that guesses the lottery numbers can make you a millionaire!!!
  </span></font></p>
  <font size=2><a href="#top">Back to top</a>&nbsp;&nbsp;&nbsp;<a href="http://www.mobizex.com/product.jsp?team=mobizex&code=3010&title=Mystic+Applications" target="_blank">More...</a></font><BR>&nbsp; </span></font></p>


  <FONT SIZE=-2>This email was sent by Mobizex news service. Please click <a href=http://www.mobizex.com/remove.jsp?type=mobizex target=_blank>here</a> if you wish to unsubscribe.</FONT>




  </td>
 </tr>



</table>

</div>

</body>

</html>

</body></html>