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]