Menu
▾
▴
libxmlplusplus-general — Open discusions about libXML++
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(157) |
Dec
(87) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(78) |
Feb
(246) |
Mar
(83) |
Apr
(32) |
May
(99) |
Jun
(85) |
Jul
(34) |
Aug
(24) |
Sep
(65) |
Oct
(60) |
Nov
(45) |
Dec
(90) |
| 2004 |
Jan
(8) |
Feb
(40) |
Mar
(12) |
Apr
(17) |
May
(56) |
Jun
(13) |
Jul
(5) |
Aug
(30) |
Sep
(51) |
Oct
(17) |
Nov
(9) |
Dec
(20) |
| 2005 |
Jan
(16) |
Feb
(22) |
Mar
(14) |
Apr
(6) |
May
(12) |
Jun
(41) |
Jul
(21) |
Aug
(26) |
Sep
(7) |
Oct
(42) |
Nov
(10) |
Dec
(7) |
| 2006 |
Jan
(6) |
Feb
(9) |
Mar
(19) |
Apr
(7) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
(3) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(10) |
Jun
(32) |
Jul
(6) |
Aug
(8) |
Sep
(10) |
Oct
(3) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(11) |
Apr
|
May
(6) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(3) |
| 2010 |
Jan
(3) |
Feb
(6) |
Mar
(16) |
Apr
(2) |
May
|
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ephraim V. <ef...@ho...> - 2003-06-30 08:47:07
|
I meant win32_msvc6/examples/Makefile.am http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libxmlplusplus/libxml++/win32_msvc6/examples/Makefile.am -eff ----- Original Message ----- From: "Murray Cumming" <mu...@us...> To: <lib...@li...>; <lib...@li...> Sent: Monday, June 30, 2003 9:58 AM Subject: Re: [Re: [libxml++] Win32 link error (v0.24.0 + msvc patch)] "Ephraim Vider" <ef...@ep...> wrote: > FYI: > libxml++ MSVC project file changed in CVS. Great. You mention a change to examples/Makefile.am in the ChangeLog: 2003-06-25 Ephraim Vider <ef...@ep...> * win32_msvc6: libxml++.dsp: added _REENTRANT to support libxml with threads - examples/Makefile.am: added new example project But I don't see that in cvs: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libxmlplusplus/libxml++/examples/ Murray Cumming mu...@us... www.murrayc.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Libxmlplusplus-general mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general |
|
From: Murray C. <mu...@us...> - 2003-06-30 07:58:28
|
"Ephraim Vider" <ef...@ep...> wrote: > FYI: > libxml++ MSVC project file changed in CVS. Great. You mention a change to examples/Makefile.am in the ChangeLog: 2003-06-25 Ephraim Vider <ef...@ep...> * win32_msvc6: libxml++.dsp: added _REENTRANT to support libxml with thr= eads - examples/Makefile.am: added new example project But I don't see that in cvs: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libxmlplusplus/libxml++/ex= amples/ Murray Cumming mu...@us... www.murrayc.com |
|
From: Ephraim V. <ef...@ep...> - 2003-06-25 08:55:00
|
FYI: libxml++ MSVC project file changed in CVS. -eff ----- Original Message ----- From: "Matt Esterly" <ma...@au...> To: <lib...@li...> Sent: Wednesday, June 25, 2003 12:11 AM Subject: Re: [libxml++] Win32 link error (v0.24.0 + msvc patch) > Thanks Ephraim! _REENTRANT did the trick. I think you are correct > _POSIX_C_SOURCE for unix, since libxml++ compiled with the latest > libxml on OSX without configuration changes. > > On Tuesday, June 24, 2003, at 11:58 AM, Ephraim Vider wrote: > > > The relevant lines from xmlversion.h are: > > > > /** > > * LIBXML_THREAD_ENABLED: > > * > > * Whether the thread support is configured in > > */ > > #if 1 > > #if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) > > #define LIBXML_THREAD_ENABLED > > #endif > > #endif > > > > > > If the library is compiled without threads it would say #if 0 and > > never > > define LIBXML_THREAD_ENABLED > > so: > > In msvc you have to define _REENTRANT to get LIBXML_THREAD_ENABLED when > > thread support is on, and it will have no effect on libxml when thread > > support is off. > > > > On unix machines it may be that the _POSIX_C_SOURCE is automatically > > defined > > so there is no need to define anything else, but this is just a guess > > (it is > > so on my linux). > > |
|
From: Matt E. <ma...@au...> - 2003-06-24 22:11:38
|
Thanks Ephraim! _REENTRANT did the trick. I think you are correct _POSIX_C_SOURCE for unix, since libxml++ compiled with the latest libxml on OSX without configuration changes. On Tuesday, June 24, 2003, at 11:58 AM, Ephraim Vider wrote: > The relevant lines from xmlversion.h are: > > /** > * LIBXML_THREAD_ENABLED: > * > * Whether the thread support is configured in > */ > #if 1 > #if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) > #define LIBXML_THREAD_ENABLED > #endif > #endif > > > If the library is compiled without threads it would say #if 0 and > never > define LIBXML_THREAD_ENABLED > so: > In msvc you have to define _REENTRANT to get LIBXML_THREAD_ENABLED when > thread support is on, and it will have no effect on libxml when thread > support is off. > > On unix machines it may be that the _POSIX_C_SOURCE is automatically > defined > so there is no need to define anything else, but this is just a guess > (it is > so on my linux). |
|
From: Christophe de V. <cde...@al...> - 2003-06-24 15:36:44
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 24 Juin 2003 17:14, Ephraim Vider a =E9crit : > Ok, I have found the problem, Great ! > The prebuilt libxml2 2.5.7 was compiled with thread support (as opposed to > 2.5.4) so the "globals" are accessed differently. > > You need to add _REENTRANT to the libxml++ project preprocessor > definitions in order to activate the thread support in the header and have > access to the global variables. > So we'll have the same problem on unixboxes when libxml is compiled with=20 thread support. Question for autotools gurus: =2D - Is there a way at configure time to now wether or not libxml2 has bee= n=20 compiled with thread-support ? subquestion: =2D - Does defining _REENTRANT and link against a libxml2 without threads w= ill be=20 a problem ? I don't think so but we need to test. Cheers, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++HAiB+sU3TyOQjARAmflAKCYpmbs+REvFCoAjgk693H+t3nncACeNC1u 0jSz6DiOR77XLgYLVE/WhKU=3D =3DXpij =2D----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@al...> - 2003-06-24 15:23:14
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 24 Juin 2003 17:50, Ephraim Vider a =E9crit : > :-) > > I hereby solemnly declare that I will not abuse CVS access and always > consult the project maintainers > :-) > good enough? far enough ! You should have CVS access now. Best regards, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++Gz3B+sU3TyOQjARAvwBAJ9kC/7O/C3VJFIXUJHTtof9wcnu/gCgsDTQ Ha9C7LiH2b1Yiek0jWkkdv4=3D =3DK1q+ =2D----END PGP SIGNATURE----- |
|
From: Ephraim V. <ef...@ep...> - 2003-06-24 14:15:21
|
Ok, I have found the problem,
The prebuilt libxml2 2.5.7 was compiled with thread support (as opposed to
2.5.4) so the "globals" are accessed differently.
You need to add _REENTRANT to the libxml++ project preprocessor definitions
in order to activate the thread support in the header and have access to the
global variables.
-eff
----- Original Message -----
From: "Christophe de Vienne" <cde...@al...>
To: <lib...@li...>
Sent: Friday, June 20, 2003 1:25 AM
Subject: Re: [libxml++] Win32 link error (v0.24.0 + msvc patch)
Le Jeudi 19 Juin 2003 22:44, Matt Esterly a écrit :
>
> It appears xmlIndentTreeOutput is not exported in the xmlib2.dll,
>
Well, but we have in globals.h at line 268 :
LIBXML_DLL_IMPORT extern int xmlIndentTreeOutput;
This line is skipped by the preprocessor if thread are enabled, but I don't
think this binary is compiled with thread support.
Try to compile and link a single program :
#include <libxml/globals.h>
int main()
{
printf("%d", xmlIndentTreeOutput);
}
If this doesn't work, you may have some more help on the libxml
mailing-list.
Good luck,
Christophe
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Libxmlplusplus-general mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
|
|
From: Grossmann N. <Nik...@ST...> - 2003-06-20 14:10:51
|
Hi,
I tried to compile the libxml++ 0.24.0 on Solaris using Sun' s C++ compiler
(version 5.2). This compiler distinguishes between C++ linking and C
linking, e.g.
extern "C" void foo();
and pointers to such functions are something different than
extern "C++" void foo();
Thus the assignments like (parser.cc, line 49):
_context->vctxt.error = &_callback_validity_error;
do not work since error is a pointer to a C function (defined in libxml2)
and _callback_validity_error is a static C++ method of Parser.
I came up with three possible solutions but I do not like any of them:
1. add extern "C" {...} blocks around class Parser {...}; and all other
classes where this problem occurres. I have not tested this.
2. for each method which has to be assigned to a C pointer add an function
defined with C linking which then calls the C++ method:
extern "C" void foo_helper();
void foo_helper()
{
ClassName::foo();
}
3. use gcc.
Any other ideas?
Regards,
Niklas.
--
Niklas Grossmann
Start Amadeus GmbH
System Platforms - Middleware Services T-SM
Marienbader Platz 1, 61348 Bad Homburg v.d.H.
|
|
From: Christophe de V. <cde...@al...> - 2003-06-19 23:28:50
|
Le Jeudi 19 Juin 2003 22:44, Matt Esterly a =E9crit :
>
> It appears xmlIndentTreeOutput is not exported in the xmlib2.dll,
>
Well, but we have in globals.h at line 268 :
LIBXML_DLL_IMPORT extern int xmlIndentTreeOutput;
This line is skipped by the preprocessor if thread are enabled, but I don't=
=20
think this binary is compiled with thread support.
Try to compile and link a single program :
#include <libxml/globals.h>
int main()
{
printf("%d", xmlIndentTreeOutput);
}
If this doesn't work, you may have some more help on the libxml mailing-lis=
t.
Good luck,
Christophe
|
|
From: Matt E. <ma...@au...> - 2003-06-19 20:44:40
|
On Thursday, June 19, 2003, at 02:34 AM, Christophe de VIENNE wrote: > Le Jeudi 19 Juin 2003 09:50, Ephraim Vider a =E9crit : >> could it be you are using an old version of libxml2 ? >> this doesn't happen with libxml2 2.5.4 > Strange, the xmlIndentTreeOutput variable is quite old in libxml. > Was libxml2.dll compiled with the same compiler, same version ? I am using libxml2 2.5.7 from=20 http://www.zlatkovic.com/projects/libxml/binaries.html per the readme .=20= It appears xmlIndentTreeOutput is not exported in the xmlib2.dll, I=20 commented out or hard coded the references and libxml++ and the=20 examples compile and run like champs. It appears the binaries are=20 compiled using the MS DDK and I am using MSVC 6.0 which has not been an=20= issue in the past. attempts to build 2.5.7 from scratch get a couple=20 link errors as well so... rolling back to 2.5.4 may be the best option. Has anyone had success with libxml2 2.5.7? thanks >m= |
|
From: Christophe de V. <cde...@al...> - 2003-06-19 09:33:54
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 19 Juin 2003 09:50, Ephraim Vider a =E9crit : > could it be you are using an old version of libxml2 ? > this doesn't happen with libxml2 2.5.4 > Strange, the xmlIndentTreeOutput variable is quite old in libxml. Was libxml2.dll compiled with the same compiler, same version ? Cheers, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+8YOSB+sU3TyOQjARAj9rAKDXvXk5mPUHyYoee7spG7vxdflvvQCfaLaC TUF7voOqSvQoA8uPHBR7TjU=3D =3DsnqN =2D----END PGP SIGNATURE----- |
|
From: Ephraim V. <ef...@ep...> - 2003-06-19 06:49:03
|
could it be you are using an old version of libxml2 ? this doesn't happen with libxml2 2.5.4 -eff ----- Original Message ----- From: "Matt Esterly" <ma...@au...> To: <lib...@li...> Sent: Wednesday, June 18, 2003 8:09 PM Subject: [libxml++] Win32 link error (v0.24.0 + msvc patch) > Hi, > Is anyone else having link errors compiling the example in v0.24 with > or without the visual studio patch installed? I have verified the /Tp > flag is set per the win32 documentation. > > MSVC compiler output: > --------------------Configuration: dom_build - Win32 > Release-------------------- > Linking... > libxml++.lib(document.obj) : error LNK2001: unresolved external symbol > __imp__xmlIndentTreeOutput > libxml++.lib(keepblanks.obj) : error LNK2001: unresolved external > symbol __imp__xmlIndentTreeOutput > > Thanks, > Matt Esterly > > PS very nice work on the API > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Libxmlplusplus-general mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general > |
|
From: Matt E. <ma...@au...> - 2003-06-18 18:09:32
|
Hi, Is anyone else having link errors compiling the example in v0.24 with or without the visual studio patch installed? I have verified the /Tp flag is set per the win32 documentation. MSVC compiler output: --------------------Configuration: dom_build - Win32 Release-------------------- Linking... libxml++.lib(document.obj) : error LNK2001: unresolved external symbol __imp__xmlIndentTreeOutput libxml++.lib(keepblanks.obj) : error LNK2001: unresolved external symbol __imp__xmlIndentTreeOutput Thanks, Matt Esterly PS very nice work on the API |
|
From: Christophe de V. <cde...@al...> - 2003-06-18 13:39:46
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Richard, People willing to help are always welcome, so feel free to participate. All discussions about libxml++ dev are on the mailing-list. If you have fre= sh=20 ideas it's the place where to propose them. If you have patches to propose (either some bugfix or feature improvements)= ,=20 use the patch manager on sourceforge. Patches are usually discussed and we= =20 may ask some corrections before including them into the CVS. Best regards, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+8GuoB+sU3TyOQjARAvV0AJ9jau+WokZggaBqeu7w/Huq6BdS6gCgu1SH KIw4CjItjt0eWxRenBFCYvI=3D =3D+tqM =2D----END PGP SIGNATURE----- |
|
From: Ephraim V. <ef...@ep...> - 2003-06-16 07:47:35
|
I uploaded the changed files to the patch manager. please replace the .opt in cvs since there was an example added and this sets working directory Makefile.am needed updating too regards, -eff ----- Original Message ----- From: "Christophe de VIENNE" <cde...@al...> To: <lib...@li...> Sent: Monday, June 16, 2003 9:35 AM Subject: Re: [libxml++] 0.24 not compiling in VS6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 16 Juin 2003 04:12, Forrest Osterman a écrit : > Hey guys, > Sorry I was unable to test this until this weekend, I was pulled off the > project that I would like to use libxml++ for, for a week. Anyway, I am > unable to compile 0.24 in visual studio. It says it can't open pinode.cc > and therefore can't build. I searched and that file is nowhere in the > release. I see. When I applied the patch I renamed pinode.cc to processinginstructionnode.cc. Since I don't have VS I forgot to correct the project files. If someone using VS could propose a patch, I'd be glad. Cheers, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+7XNFB+sU3TyOQjARArN+AKDnCkzZnaEJuhQJ2xHRuVZ9P0v1jQCcDHDC Xs/zpXILE5vSEIvOnQ/93TQ= =hIuj -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Libxmlplusplus-general mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general |
|
From: SourceForge.net <no...@so...> - 2003-06-16 07:41:38
|
Patches item #755172, was opened at 2003-06-16 10:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312999&aid=755172&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 compile and distrib for 0.24 Initial Comment: changes in msvc files that did not make it to 0.24 please replace the files in cvs (yes, the .opt too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312999&aid=755172&group_id=12999 |
|
From: Christophe de V. <cde...@al...> - 2003-06-16 07:35:21
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 16 Juin 2003 04:12, Forrest Osterman a =E9crit : > Hey guys, > Sorry I was unable to test this until this weekend, I was pulled off the > project that I would like to use libxml++ for, for a week. Anyway, I am > unable to compile 0.24 in visual studio. It says it can't open pinode.cc > and therefore can't build. I searched and that file is nowhere in the > release. I see. When I applied the patch I renamed pinode.cc to=20 processinginstructionnode.cc. Since I don't have VS I forgot to correct the= =20 project files. If someone using VS could propose a patch, I'd be glad. Cheers, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+7XNFB+sU3TyOQjARArN+AKDnCkzZnaEJuhQJ2xHRuVZ9P0v1jQCcDHDC Xs/zpXILE5vSEIvOnQ/93TQ=3D =3DhIuj =2D----END PGP SIGNATURE----- |
|
From: Forrest O. <for...@ho...> - 2003-06-16 02:12:44
|
Hey guys, Sorry I was unable to test this until this weekend, I was pulled off the project that I would like to use libxml++ for, for a week. Anyway, I am unable to compile 0.24 in visual studio. It says it can't open pinode.cc and therefore can't build. I searched and that file is nowhere in the release. -Forrest Osterman _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Christophe de V. <cde...@al...> - 2003-06-14 13:22:35
|
Le Samedi 14 Juin 2003 01:52, Thomas Jarosch a =E9crit : > (Didn't know 0.24 is out as freshmeat still thinks 0.23 is the newest > version) > Strange. I did the release. I'll try to figure what's going on next week. Cheers Christophe |
|
From: Thomas J. <tho...@in...> - 2003-06-14 10:42:38
|
> > > The segfaults are reproducable with the dom parser example program. > > > > which version did you use ? With 0.24 I do not have this segfault. > > I used version 0.23. I'll give 0.24 a try now. > (Didn't know 0.24 is out as freshmeat still thinks 0.23 is the newest > version) Ok, 0.24 works perfect. Hope there aren't any setuid programs out there using libxml++ 0.23 ;-) Thomas |
|
From: Thomas J. <tho...@in...> - 2003-06-13 23:52:34
|
> Le Samedi 14 Juin 2003 01:19, Thomas Jarosch a =E9crit : > > I found another two segfaults :o) > > > > - Zero byte file > > - Special one byte file (attached) > > > > The segfaults are reproducable with the dom parser example program. > > which version did you use ? With 0.24 I do not have this segfault. I used version 0.23. I'll give 0.24 a try now. (Didn't know 0.24 is out as freshmeat still thinks 0.23 is the newest versi= on) Thomas |
|
From: Christophe de V. <cde...@al...> - 2003-06-13 23:45:43
|
Hi, Le Samedi 14 Juin 2003 01:19, Thomas Jarosch a =E9crit : > > I found another two segfaults :o) > > - Zero byte file > - Special one byte file (attached) > > The segfaults are reproducable with the dom parser example program. which version did you use ? With 0.24 I do not have this segfault. Cheers, Christophe |
|
From: Thomas J. <tho...@in...> - 2003-06-13 23:19:17
|
Hi Christophe, > > > 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_exception > > with the message "cannot create parsing context". > > If anybody think a new exception type is needed for that just tell me > > we'll discuss it. In the mean time at least we'll not have a segfault. I found another two segfaults :o) - Zero byte file - Special one byte file (attached) The segfaults are reproducable with the dom parser example program. Thomas |
|
From: Morten H. <mor...@pd...> - 2003-06-13 07:24:13
|
On Thursday, June 12, 2003 1:53 PM, Jonathan Wakely wrote: > Morten, the problem isn't that libxml++ doesn't "support" UTF-8 (it = uses > UTF-8 for all strings, just like libxml) the issue is that > std::string::size() returns the number of bytes, but when the string > contains UTF-8 data the number of bytes is not necessarily the same as > the number of characters. glib::ustring is UTF-8 aware and can tell = you > the correct number of chars. Yeah, I figured it out as well, just after I wrote the previous message. = So it really isn't too much of a problem after all; I just convert my data to UTF-8 right before I pass them on to libxml++, = and everything works like a charm. :) Morten. |
|
From: Morten H. <mor...@pd...> - 2003-06-12 10:52:33
|
Hi. After reading up on old articles in the mailing list archive, I = understand that support for UTF-8 in libxml++ is still to come, and it = will not be available after libxml++ 1.0 has been released, am I right? Anyway; what I wanted to do is to propose a temporary "solution" while = we're waiting for support for an UTF-8 aware string class or whatever. = The solution would not require any change to the outside API, and thus = should be relatively safe to apply. Ok; suggestion: std::string is really a typedef for std::basic_string<char>. When a = std::string is passed on from libxml++ to a function in libxml, it's = char * representation is just casted to unsigned char *. Would it be = terribly wrong to assume that the input in the std::string is always = ISO-8859, and convert the input-string to UTF-8 (as opposed to just = casting) before passing it to libxml? libxml contains a function called = something like isoLatinToUTF8, which can take care of the conversion. As a result, we would still have std::string in all the public = interfaces, but at least gain "support" for 128 more characters, which I = guess would make the life better for most people. Since the first 127 = characters in ISO-8859 are the same as in ASCII, it should not make the = matter worse for anyone. Thoughts? Morten. |
949 messages has been excluded from this view by a project administrator.
