libxmlplusplus-general

[libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

Hi,

I have read all the previous posts regarding the use of Glib::ustring and std::string for use with libxml++.  I have even read the bug and the associated patch.  I understand Murray's point of view and agree with him from a package maintainer's point of view.

However, I would really like to move forward with one part of the proposed change, and am willing to produce an updated patch.

The change that David Yan submitted on 2007-02-10 had two changes.  The first was to rename all of the use of Glib::ustring to xmlpp::string.  This, I believe, should be adopted in the mainline as it has no functional change, and would serve to minimize the number of locations the external glibmm libraries are referenced.  The second change was to allow the underlying type of xmlpp::string to be selected by the installer.  If only this change is integrated with the code, the second change can be easily done by anyone who really needs it.

I would like to use libxmlpp, but my target system doesn't have (nor will it) any glib libraries.  That dependency is a non-starter.  However, like many other libraries, I am willing to patch this one -- I purpose build all of the third-party libraries I use, I don't use the system version.  The inclusion of the first of David Yan's changes (updated to match the current code, of course) would allow be, and anyone else, to make my patch much MUCH smaller.

I understand the desire to keep the current api, and appreciate that, as Murray said, it would be too easy for the wrong version of a package to be released with some OS, causing havoc.  That said, what do you think of including the first part of those changes into the main-line?

Thanks!

David


NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[Steven <red...@gm...>]

On Tue, July 27, 2010 19:09, David Benoit wrote:
> Hi,
>
> I have read all the previous posts regarding the use of Glib::ustring and
> std::string for use with libxml++.  I have even read the bug and the
> associated patch.  I understand Murray's point of view and agree with him
> from a package maintainer's point of view.
>
> However, I would really like to move forward with one part of the proposed
> change, and am willing to produce an updated patch.
>
....
> The second change was to allow the
> underlying type of xmlpp::string to be selected by the installer.  If only
> this change is integrated with the code, the second change can be easily
> done by anyone who really needs it.
>

I'm not really a libxml++ developer, but, when changing the underlying
type in the installer (really the installer, and not some compile flags?),
wouldn't this pose an issue to other applications, dependent on libxml++?
Wouldn't they need to be recompiled as well?
I use Debian, so libxml++ is pre-build and installed using the package
manager, but what if someone creates a binary with the other string
implementation?

Just asking :)

Kind regards,
Steven


-- 
Rarely do people communicate; they just take turns talking.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

> -----Original Message-----
> From: Steven [mailto:red...@gm...]
> Sent: Wednesday, July 28, 2010 3:00 AM
>
> I'm not really a libxml++ developer, but, when changing the underlying
> type in the installer (really the installer, and not some compile
> flags?),
> wouldn't this pose an issue to other applications, dependent on
> libxml++?
> Wouldn't they need to be recompiled as well?
> I use Debian, so libxml++ is pre-build and installed using the package
> manager, but what if someone creates a binary with the other string
> implementation?
>
> Just asking :)

Yes and no.  The configuration change (the second change that I expect would not be integrated with the source) would be a change in the build configuration that changes the compilation, not the install.  It would be something that the package maintainer would be aware of, and nobody else.

The distributed libxml++ package would be shipped as it is today, with Glib::ustring as the storage.  The proposed (first) patch to the mainline code would simply:
 - rename all occurrences of Glib::ustring to xmlpp::string, and associated changes
 - add a "string.h" file that contains:
    namespace xmlpp {
      typedef ::Glib::ustring string;
    }
This would result in no change in process, effective API, binary, ABI, etc.  It simply makes things more flexible.

David

NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

Attached is the proposed first patch.  Source cloned from git yesterday.  Comments welcome.

David

NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[Murray C. <mu...@mu...>]

On Wed, 2010-07-28 at 15:13 -0400, David Benoit wrote: 
> Attached is the proposed first patch.  Source cloned from git yesterday.  Comments welcome.

Please put this in bugzilla.

I'm generally still thinking about this and haven't quite decided yet.

-- 
mu...@mu...
www.murrayc.com
www.openismus.com