November 2004 - Boost-users

[Review] Named Parameters library (ongoing)
by Doug Gregor 22 Nov '04

22 Nov '04

Today is the last day of the review of the Named Parameters library by David Abrahams and Daniel Wallin. Let's hear some more comments! The original announcement follows: The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

1 0

Re: [sigc] Re: [Boost-users] Signals & Slots
by Peter Dimov 22 Nov '04

22 Nov '04

Carl Nygard wrote: > On Thu, 2004-11-18 at 14:09, Doug Gregor wrote: > >> I'm not in a position to do this at the moment, although possibly in >> the future. It would be *wonderful* if someone went off and studied >> both libraries in-depth to make this comparison, especially if that >> person was not intimately familiar with either library beforehand. >> > > Available: http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html > > Updates for code samples from Chris Vine and Jonathan Brandmeyer will > be forthcoming. > > I could use some suggestions on how to incorporate common code into > the code comparison tables. > > And of course, any other comments, flames, etc. will be welcome. I'm > only doing this as a service for keeping track of comments. I'd like > to see some of this stuff make it into the C++ standard library. About: [-ed I'd love this, as long as I didn't have to use all of Boost to get it]. in reference to Boost.Bind. You don't need all of Boost. boost::bind is reasonably self-contained. I see that a dependency on mpl::bool_ has crept up in boost/ref.hpp, but Bind does not need it, so it's excisable without much effort. "Soon" (in a few years, once TR1 is implemented across the board) we'll hopefully be able to get 'bind' and 'function' by just including <functional>. This will also help Boost.Signals a bit since I suspect that nowadays most of the preprocessed code comes from boost::function.

2 3

Re: [sigc] Re: [Boost-users] Signals & Slots
by Doug Gregor 21 Nov '04

21 Nov '04

On Nov 21, 2004, at 8:09 PM, Carl Nygard wrote: > On Sun, 2004-11-21 at 14:26, Murray Cumming wrote: >> On Sat, 2004-11-20 at 15:58 -0500, Carl Nygard wrote: >>>> 2. libsigc++2 uses sigc::signal<>, not sigc::signal[1/2/3/4/5]<>. >>> >>> Yup, and Boost.Signal has signal<void (float, string)> notation as >>> well. I was trying to keep the examples as identical as possible to >>> show commonalities, but I'll make a note. >> >> The API here seems to be different, so it would be useful to show >> that. >> >> I don't think anybody is interested in using some secondary API >> (probably semi-internal API) just because that API is similar in both >> libsigc++ and Boost.Signal. > > Sorry, I thought the reason for the comparisons was as a first step for > C++ standard library, so I figured the analysis should concentrate on > underlying implementation instead of syntactic conveniences... although > those conveniences go a long way toward making the library usable. > I'll > update the docs... > > Regards, > Carl We should compare the "best" interfaces of both libraries, because we want to have the best interface to present to the C++ committee. For Boost.Signals, that's the "boost::signal<void(float x, string s)>" interface. As for the interface vs. implementation question... the C++ committee is interested in interfaces and their semantic descriptions, only. Having an implementation is important to validate the interface (having two implementations is, of course, much better!), but implementation details need not be discussed. They do come into play when we talk about the best semantics we can get... for instance, whether disconnecting a slot is O(1) or O(lg n), etc. Doug

1 0

boost mutex locking order
by amiel montecillo 21 Nov '04

21 Nov '04

Hi all, i was supposed to use boost::mutex in my multithreaded app, and came across a problem with its scheduling policy. if more than one thread is going to use the mutex object, how can we implement the FIFO scheduling policy? i need it so that other threads waiting for the mutex to be unlocked can acquire it in order in which they waited on the mutex that is accessed through boost::mutex::scoped_lock.

1 0

boost::variant output a vector?
by Bo Peng 21 Nov '04

21 Nov '04

Dear list, In the manual of boost::variant: OutputStreamable: For any object t of type T, std::cout << t must be a valid expression. However, I can not output a variant vector work by defining ostream& operator<< vector<double> . Attached is a test case. Note that variant int, string can be outputed, but not the vector. Yet, cout << vector<double> is working. I am using gcc 3.2.2 on linux redhat 9. Many thanks in advance. Bo #include "boost/variant.hpp" using namespace std; #include <string> #include <vector> typedef boost::variant<int, double, string, vector<double> > Variable; #include <iostream> ostream& operator<< (ostream& out, const vector<double> & vec) { out<< "["; if( ! vec.empty() ) { vector<double>::const_iterator it = vec.begin(); out << *it; for( ++it; it!= vec.end(); ++it) out << ", " << *it ; } out << "]"; return out; } int main() { Variable a(2); Variable b("asd"); vector<double> vec(0); vec.push_back(3.0); Variable c(vec); cout << vec << endl; // OK cout << a << b << endl; // OK cout << c << endl; // compiling errors. return 0; }

2 1

serialization example linker errors.
by Jeffrey Holle 20 Nov '04

20 Nov '04

My boost libaries come from CVS on Sun Nov 14 18:35:14 EST 2004 I'm building with gcc v3.4.2 on a linux system. I've run into a problem in attempting to build the serialization examples. All failed in link phase with: /usr/bin/ld: cannot find -lm

1 1

Luabind and Boost 1.32.0
by Jeremy Swigart 20 Nov '04

20 Nov '04

Just grabbed the latest version and attempted to compile a previously working setup of Luabind and I get the following error. \luabind\class.hpp(105) : fatal error C1083: Cannot open include file: 'boost/mpl/apply_if.hpp': No such file or directory Apparently this file was removed in boost 1.32 Anyone know how to get luabind back to a working state? Thanks. Jeremy

2 1

Re: [sigc] Re: [Boost-users] Signals & Slots
by Edward Diener 20 Nov '04

20 Nov '04

Carl Nygard wrote: > On Thu, 2004-11-18 at 14:09, Doug Gregor wrote: >> On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote: > >> I'm not in a position to do this at the moment, although possibly in >> the future. It would be *wonderful* if someone went off and studied >> both libraries in-depth to make this comparison, especially if that >> person was not intimately familiar with either library beforehand. >> > > Available: http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html > > Updates for code samples from Chris Vine and Jonathan Brandmeyer will > be forthcoming. > > I could use some suggestions on how to incorporate common code into > the code comparison tables. > > And of course, any other comments, flames, etc. will be welcome. I'm > only doing this as a service for keeping track of comments. I'd like > to see some of this stuff make it into the C++ standard library. In the just-released Boost 1.32, the Boost signals library does make a guarantee of the order of signals within a particular group. The order within a particular group is FIFO.

1 0

Re: [sigc] Re: [Boost-users] Signals & Slots
by David Abrahams 20 Nov '04

20 Nov '04

Carl Nygard <cjnygard(a)fast.net> writes: > On Thu, 2004-11-18 at 14:09, Doug Gregor wrote: >> On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote: > >> I'm not in a position to do this at the moment, although possibly in >> the future. It would be *wonderful* if someone went off and studied >> both libraries in-depth to make this comparison, especially if that >> person was not intimately familiar with either library beforehand. >> > > Available: http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html > > Updates for code samples from Chris Vine and Jonathan Brandmeyer will be > forthcoming. > > I could use some suggestions on how to incorporate common code into the > code comparison tables. > > And of course, any other comments, flames, etc. will be welcome. I'm > only doing this as a service for keeping track of comments. The syntax you're using for boost::function is a bit passe. // Signal with two args and int return value boost::signal2<int, float, string> sig; Should be // Signal with two args and int return value boost::signal<int (float, string)> sig; I think your analysis underestimates or ignores the importance of syntax, most importantly the syntax for invoking a signal. The fact that the Boost signal is an ordinary function object that can be called directly has important implications for interoperability (you don't need binders). NOTE: Boost.Signals documentation states that there are exceptions to using boost::signals::trackable, specifically the trackable base class is unable to manage connections created using Boost.Function or Boost.Lambda. This problem is stated to be resolved in future versions. Trackable Boost.Signals is at a bit of a disadvantage because the trackable class doesn't work with Boost.Lambda and Boost.Function. In this bsense, SigC library's implementation seems superior, if only because you don't have to think about limitations. Does libSigC++ not suffer from an analogous limitation, or did its documentation simply fail to mention it, or is just requiring you to do more work manually? The equivalency table for slot binders is misleading, I think. Boost.Signals has no direct coupling to Boost.Bind, and the fact that Boost.Bind doesn't provide certain binders doesn't mean you can't get them another way. For example, I think you can use Boost.Lambda or Phoenix to create them. As for the retype ... stuff, I don't know what libSigC++ does there. However, no explicit retyping is needed with Boost where the types concerned are implicitly convertible to the expected types. Hope this helps. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

POSIX regex library conflicts
by Andrew Dennison 20 Nov '04

20 Nov '04

My project hit an interesting snag yesterday. It turns out that in different areas of the project, one developer had been using the boost regex library, while the other was using the POSIX library. Since the boost regex library provides POSIX compatibility with boost/regex.h i suspect you may already be aware of this, but i'll mention it anyway, as i believe more could be done about this problem. regex.h uses #defines for certain numerical constants which are also declared in boost regex. This is a problem if both posix and boost are defined in the same project at the same time as the preprocessor will replace the boost definitions with the macro definition in regex.h (ie REG_EXTENDED = 1, among others). I appreciate that this case is somewhat handled by the compatibility header, but this isn't always an available solution. We were able to change headers, so this problem was solved, but this may not always be possible (ie third party software). Perhaps the developers could include some protection against this kind of error by checking to see if the offending constants are defined before the boost declarations are made and #undef-ing them as needed. This kind of error can be difficult to track down in mid-large projects. Regards, Andrew.

2 1