B On Fri, 2003-02-28 at 01:51, Murray Cumming Comneon com wrote: > 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 -- Edward H. Hill III, PhD Post-Doctoral Researcher | Email: ed eh3 com, ehill mines edu Division of ESE | URLs: http://www.eh3.com Colorado School of Mines | http://cesep.mines.edu/people/hill.htm Golden, CO 80401 | Phones: 303-384-2094, 303-273-3483
Attachment:
signature.asc
Description: This is a digitally signed message part