Hi all, On gtkmm mailing was posted mail about using boost in gtkmm... Could someone post some info about API, ABI stability of boost? thanks Trigve mail from gtkmm list: //---------------------- 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. On Mon, 2007-08-13 at 12:27 +0800, manphiz wrote:

Hi gtkmm developers:

I'm a new-comer to gtkmm, who found gtkmm a ideal GUI toolkit based on the philosophy of standard C++, which exactly matches my anticipation.

On the other hand, glibmm/gtkmm is virtually a wrapper of gtk+ stuff, which also has to reflect the interface of the original stuff. While Boost is a well-known C++ library collection which has many overlaps in many aspects with glibmm, such as smart pointer, thread support. Recently, a feature request for weak pointer in glibmm and the recent compose api proposed by Daniel Elstner are resemblances as boost::weak_ptr and boost::format, which provide similar functionalities.

Here's the question: whether to reuse Boost or to reinvent all needed functionailities in glibmm? Though there seems a reluctance to use Boost which already results in many reinvention in glibmm, I don't think it is a good idea. Boost is becoming more and more widely used within C++ community. To reinvent is simply a waste of resource, and may even result in different design and implementation which will definitely compromise the interoperability between Boost and gtkmm. With the fact of gtk+ binding, I believe the existence of libsigc++ indicates glibmm/gtkmm is not a zealot to become a strict binding with gtk+ stuff. While Boost is indeed a much heavier library than libsigc++, it still merits reusing in gtkmm. Moreover, many Boost stuff are going to become part of C++0x, which means smart_ptr, threads, regex, etc. will become a part of the language itself, which in turn will loose the need of some stuff currently in glibmm. Due to the binding reality, it is impossible to do everything in Boost, but some of them can benefit a lot.

I wonder if such a migration to Boost is possible? A reimplementation with gtkmm may be infeasible since it will destroy the binary compatibility. Changing glibmm stuff to be a binding of Boost without changing its interfaces sounds viable, which will ultimately save gtkmm a lot of work in the long run. What do you think?

_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list -- murrayc@murrayc.com www.murrayc.com www.openismus.com

_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list //---------------------- ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow