gtkmm and boost
- From: manphiz <manphiz gmail com>
- To: gtkmm-list gnome org
- Subject: gtkmm and boost
- Date: Mon, 13 Aug 2007 12:27:15 +0800
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?
[
Date Prev][
Date Next]   [
Thread Prev][
Thread Next]   
[
Thread Index]
[
Date Index]
[
Author Index]