Re: gtkmm and boost

[Murray Cumming <murrayc murrayc com>]

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