Re: gtkmm and boost

["Paul Davis" <pjdavis engineering uiowa edu>]

Like you mention, its always going to be a balancing act.

I think the thing you need to remember when thinking about changing
parts of the backend of Gtkmm is that it *is* a wrapper around Gtk.
There's no getting around that. Replacing things like Glib::RefPtr
with boost::shared_ptr are probably just not going to happen.

There will always be a whole host of issues that would simply not
exist if the original Gtk were written in C++. But had it been, it
probably would've been replaced by somethg else by now.

Paul Davis

On 8/13/07, manphiz <manphiz gmail com> wrote:
> Murray Cumming wrote:
> > Boost is not a stable API. If it ever declares API and ABI stability
> > then we could use it. Using boost now would break already-installed
> > applications and break compilation of applications when boost is
> > upgraded.
> >
> > When parts of the Boost API become part of the official C++ standard
> > then we would use that API where appropriate. For instance, we hope to
> > port to a standard C++ signals API in the future. That API was largely
> > based on libsigc++ anyway.
> >
>
> Though there are some libraries staying intact for quite a long time
> already, I agree with you on Boost's unstable nature. But it hurts me
> when some part of gtkmm and Boost provide different interfaces, most
> significantly incompatible smart pointers.
>
> However, it seems at least TR1 is in a more stable status now, though
> several amendment is being revised and voted according to the C++
> standard working groups. So is it possible to import TR1 stuff into
> glibmm once it is settled which covers some aspects in glibmm as smart
> pointer, regex, reference wrapper, omnibinder? Maybe it's reasonable to
> wait for wider compiler support though :)
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>