GNOME Bugzilla – Bug 575005
Should we go boost?
Last modified: 2009-08-30 19:28:14 UTC
Here are some things where boost could be used in ekiga : - sigc++ for signals ; - a custom-made gmref_ptr for smart pointer. Technically : - it isn't better than sigc++ for signals (the choice of sigc++ was because it's used in gtkmm and I was hoping we could dump part of our C-code gui for shorter C++ code) ; - but it's definitely better than my gmref_ptr code for smart pointers, since there are more variants, and it's not code we would have to maintain ourselves. I have an experimental small patch and an even more experimental short sh-sed script to automatize most of the transition from sigc++ to boost::signal. I have nothing to kick gmref_ptr out yet, but I'm pretty sure it would be easy -- I'm only worried we will need to had more explicit dynamic castings than currently, since they wouldn't be automatically hidden in gmref_ptr anymore. I just added a notice in bug #574998 that boost could also be used for some string manipulations (but we already have glib which does them pretty well, so maybe that's not that interesting). There's also the problem that boost is tricky to detect in configure.ac to take into account. Hope I gave enough food for thought -- I'm posting this report mostly to summarize my ideas after a discussion with Damien. There is enough to do in ekiga to keep us busy even without that.
I digged boost signals deeper -- and I have some patches ready to lower our dependancy on sigc++ ; however : - boost lacks the make_slot method, and it will be a pain to get around that ; - Ekiga::Runtime (which I don't like) would be a pain to move to boost signals (unless I get a new idea) ; - sigc++ is more touchy about types (sigc::hide_return has no counterpart in boost signals for example), and this is bad.
I digged boost smart pointers deeper : they are interesting.
In fact, I used boost's shared_ptr (as std::tr1::shared_ptr) to fix a recent bug, where gmref_ptr would have been more complex. But gmref_ptr has a few advantages : - it does casting for us ; - it uses references counts in the objects (which are useful... or at least should be).
Created attachment 135084 [details] Shell script to mostly move from gmref_ptr to boost's shared pointers
Created attachment 135085 [details] [review] Patch to take care of what the shell script couldn't do Notice that we would still have to remove gmref.h from the tree (the file and the references to it in the Makefile.am).
Created attachment 137131 [details] Script to mostly move from gmref_ptr to boost's shared pointers
Created attachment 137132 [details] [review] Patch to take care of what the shell script couldn't do We would still need to remove gmref.h and detect boost in the configure script.
Created attachment 137227 [details] [review] Patch to take care of what the shell script couldn't do This is an update, since I changed a few things.
Damien : I propose to go boost for smart pointers in master. Is it ok for you?
I'm ok for boost for smart pointers and signals.
Smart pointers are done -- signals need more time.
A raw suggestion: will unit testing make tracking of regression more automated? http://www.boost.org/doc/libs/1_39_0/libs/test/doc/html/index.html
It is definitely not trivial...
It was definitely not trivial, but it's now done. Ekiga's master repository doesn't use sigc++ anymore.
Julien, you said sigc++ is still used in the e-mail. Is it still needed or not?
Sorry Julien, I have just seen your post on ML about that.