After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575005 - Should we go boost?
Should we go boost?
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: Engine
GIT master
Other All
: Low normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-11 21:48 UTC by Snark
Modified: 2009-08-30 19:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Shell script to mostly move from gmref_ptr to boost's shared pointers (764 bytes, text/x-sh)
2009-05-21 12:00 UTC, Snark
  Details
Patch to take care of what the shell script couldn't do (74.31 KB, patch)
2009-05-21 12:01 UTC, Snark
none Details | Review
Script to mostly move from gmref_ptr to boost's shared pointers (1.14 KB, text/x-sh)
2009-06-21 19:40 UTC, Snark
  Details
Patch to take care of what the shell script couldn't do (17.59 KB, patch)
2009-06-21 19:42 UTC, Snark
none Details | Review
Patch to take care of what the shell script couldn't do (18.17 KB, patch)
2009-06-23 06:02 UTC, Snark
none Details | Review

Description Snark 2009-03-11 21:48:31 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.
Comment 1 Snark 2009-03-17 08:15:36 UTC
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.
Comment 2 Snark 2009-03-22 13:43:02 UTC
I digged boost smart pointers deeper : they are interesting.
Comment 3 Snark 2009-03-23 22:17:20 UTC
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).
Comment 4 Snark 2009-05-21 12:00:38 UTC
Created attachment 135084 [details]
Shell script to mostly move from gmref_ptr to boost's shared pointers
Comment 5 Snark 2009-05-21 12:01:38 UTC
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).
Comment 6 Snark 2009-06-21 19:40:59 UTC
Created attachment 137131 [details]
Script to mostly move from gmref_ptr to boost's shared pointers
Comment 7 Snark 2009-06-21 19:42:52 UTC
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.
Comment 8 Snark 2009-06-23 06:02:49 UTC
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.
Comment 9 Snark 2009-07-01 09:25:54 UTC
Damien : I propose to go boost for smart pointers in master. Is it ok for you?
Comment 10 Damien Sandras 2009-07-27 08:26:09 UTC
I'm ok for boost for smart pointers and signals.
Comment 11 Snark 2009-08-26 17:01:23 UTC
Smart pointers are done -- signals need more time.
Comment 12 Yannick 2009-08-26 17:18:41 UTC
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
Comment 13 Snark 2009-08-26 18:36:38 UTC
It is definitely not trivial...
Comment 14 Snark 2009-08-29 23:29:14 UTC
It was definitely not trivial, but it's now done. Ekiga's master repository doesn't use sigc++ anymore.
Comment 15 Eugen Dedu 2009-08-30 18:39:02 UTC
Julien, you said sigc++ is still used in the e-mail.  Is it still needed or not?
Comment 16 Eugen Dedu 2009-08-30 19:28:14 UTC
Sorry Julien, I have just seen your post on ML about that.