Re: [libxml++] Vote: templates everywhere v. Glib::ustring

["Martijn" <rootroot xs4all nl>]

A

----- Original Message -----
From: <Murray Cumming Comneon com>
To: <libxmlplusplus-general lists sourceforge net>
Sent: Friday, February 28, 2003 09:51
Subject: [libxml++] Vote: templates everywhere v. Glib::ustring


> I can't decide completely, and whatever I decide is likely to upset
someone,
> so I'd like to take a vote. See the bottom of this email for some more
> thoughts.
>
> What I want you to do:
>   Everyone has had time to comment and I do understand all the issues so I
> would like everyone to respond with a simple A, B, or C vote - 1 only
> please. I _will_ ignore any additional comments - this is a vote so
further
> discussion, if necessary, can happen in a separate thread. If you need
more
> information before voting, please do look at the archives, particularly
from
> the last few days:
> http://sourceforge.net/mailarchive/forum.php?forum_id=12784
> The maintainer(s) will probably respect the outcome of this vote but, then
> again, we might choose to ignore you completely - it's only fair to warn
> you.
>
> *** The Vote:
> Libxml++ 1.0 will use std::string. But to support UTF8 (Unicode) properly
in
> its API a future version of libxml++ should ...
>
> A.
> use Glib::ustring, which is already used by gtkmm.
>
> Advantage:
>   Glib::ustring is very much like std::string and you can use a
std::string
> wherever you see a Glib::ustring, if
>   you like. Here is some more documentation on Glib::ustring:
>
http://www.gtkmm.org/gtkmm2/docs/reference/html/classGlib_1_1ustring.html
> Disadvantages:
>   - Libxml++ would then depend on glibmm 2.4 and glib. Libxml++ would not
> need gtkmm.
>   Glib is on every linux distribution and will be on Solaris by default
very
> soon.
>   - Theoretical loss of performance when using a different string class,
> because data must be converted.
>
> B.
> Use templates almost everywhere. The string class would be a template
> parameter for each class - e.g. We would provide typedefs for common uses
> such as
> typedef xmlpp::Node<Glib::ustring> xmlpp_ustring::Node
> typedef xmlpp::DomParser<Glib::ustring> xmlpp_ustring::DomParser
> and
> typedef xmlpp::Node<QString> xmlpp_qstring::Node
> typedef xmlpp::DomParser<QString> xmlpp_qstring::DomParser
>
>
> Advantage:
>   Allows use of whatever string class you like.
> Disadvantage:
>   - Almost all code in libxml++ would be in a template in a header.
Libxml++
> would no longer really be a library so
>   it would have no concept of ABI. You would have to recompile your
> application to benefit from even minor
>   implementation bug fixes.
>   - The API would be less clear because people would actually use the
> typedefs but would need to look at the
>   actual templates to see the methods. The situation is the same for std::
> iostreams but people tend not to use so
>   many classes together - libxml++ is a hierarchy of related classes.
>
> C.
> do whatever you like. I don't care.
>
>
> More thoughts:
> - Personally, I think the templates-requiring-recompilation-of-apps
problem
> is a major one. It's not suitable for gtkmm so I doubt it's suitable for
any
> other library. Even if people vote overwhelmingly for B I _might_ choose
to
> fork libxml++ after 1.0 and do a Glib::ustring version. If I do this I
would
> probably not be involved with the templated fork. This is a possibility -
I
> haven't made a decision yet. I would find this decision easier because I
> think the templated fork would exist only for people who want to use
Qstring
> and I think that most of those people would prefer to use Qt's own XML
> parser instead.
>
> Murray Cumming
> murrayc usa net
> www.murrayc.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Libxmlplusplus-general lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>