Re: Standalone Glibmm::ustring

On Mon, 2010-06-14 at 18:35 +0200, Jasper Horn wrote:
> Murray Cumming wrote:
> > I guess you mean gtkmm, not glibmm, right?
> Ah, yes, how stupid. It does indeed mention 20 dlls you will need for
> gtkmm, and says nothing about which dlls you need for just glibmm.
> >>  By trial on
> >> error I have reduced this to six libraries I actually need - totalling
> >> 7 MB.
> >
> > Out of interest, what are those 6 libraries?
> It seems I accidentally counted iconv.dll as well, as such there is
> only five libraries and 6 MB:
> libglib-2.0-0.dll
> libglibmm-2.4-1.dll
> libgmodule-2.0-0.dll
> libgobject-2.0-0.dll
> libsigc-2.0-0.dll
> > I'm not in any rush to do that myself, but it is open source, so you can
> > do that if you really want. You can also patch libxml++ itself, if you'd
> > like to maintain that:
> >
> That sounds like it is indeed a more sensible thing to do then make an
> isolated Glib:ustring library. Additionally, it would also simplify
> the string handling in my application, as conversions between wxString
> and Glib::ustring aren't too cute.
> However, the given approach does not sound like a good one to me. It
> makes a lot more sense to me to choose a string implementation at
> runtime (perhaps with compile-time options to enable/disable choices).
> This would shift the choice from the one that compiles the library
> (end user) to the one who uses the library (the developer).
> It has its downsides as well (like not automatically removing the
> glibmm dependency from any application that uses libxml++), but it
> will not cause sudden unexpected behavior.

My take on this is that we should just use std::string in libxml++. It
can hold UTF-8 data just fine and if people need more sophisticated
UTF-8 operations then std::string can easily be converted to

I think that the upcoming C++0x standard does even have machinery in
place to avoid creating a copy when doing so, using std::move.

Do we break ABI in libxml++ for GNOME 3? If so that might be something
to consider.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]