- Boost-users - lists.preview.boost.org

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 22 Nov '04

22 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 22 Nov '04

22 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 21 Nov '04

21 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 21 Nov '04

21 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

Boost 1.32.0 released
by Aleksey Gurtovoy 20 Nov '04

20 Nov '04

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + NOTE: This is a stripped-down copy of the Boost 1.32.0 release + + notes. See http://www.boost.org for the full version. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Important - New Toolset Names ----------------------------- The names of some the Boost.Build toolsets have been changed to remove the "." (dot) character and to fix some other naming inconsistencies. For example, vc7.1 toolset was renamed to become vc-7_1. Please refer to the Supported Toolsets section of the installation guide for the complete list of the current toolset names. This change was made as a part of the effort to make the Boost distribution compatible with ISO 9660 level 2 requirements. New Libraries ------------- * Assignment Library: Filling containers with constant or generated data has never been easier, from Thorsten Ottosen. * Minmax Library: Standard library extensions for simultaneous min/max and min/max element computations, from Herv Brnnimann. * Multi-index Containers Library: Containers with multiple STL-compatible access interfaces, from Joaqun M Lpez Muoz. * Numeric Conversion Library: Optimized policy-based numeric conversions, from Fernando Cacciola. * Program Options Library: Access to configuration data given on command line, in config files and other sources, from Vladimir Prus. * Range Library: A new infrastructure for generic algorithms that builds on top of the new iterator concepts, from Thorsten Ottosen. * Serialization Library: Serialization/de-serialization of arbitrary C++ data structures to various formats including text, binary, and xml, from Robert Ramey. * String Algorithms Library: Collection of string related algorithms for case conversion, trimming, find/replace operations and more, from Pavol Droba. * Tribool: 3-state boolean type library, from Doug Gregor. Updated Libraries ----------------- * Compose: This deprecated library has been removed. * Graph: - Added bundled properties to the adjacency_list and adjacency_matrix class templates, greatly simplifying the introduction of internal vertex and edge properties. - The LEDA graph adaptors have been ported to LEDA 4.5. - Added algorithms for betweenness centrality and betweenness centrality clustering. - Added circle layout and undirected spring layout algorithms. * MPL Library: - Updated to use the Boost Software License. - New documentation, including a complete reference manual. - Major interface changes and improvements, many of which are not backward compatible. Please refer to the 1.32 changelog for the detailed information about upgrading to the new version. * Python Library: - Updated to use the Boost Software License. - A new, better method of wrapping classes with virtual functions has been implemented. - Support for the new Python Bool type, thanks to Daniel Holth. - Support for upcoming GCC symbol export control features have been folded in, thanks to Niall Douglas. - Improved support for std::auto_ptr-like types. - Components used by other libraries have been moved out of python/detail and into boost/detail to improve dependency relationships. - Miscellaneous bug fixes and compiler workarounds. * Signals Library: Introduced deterministic slot ordering, permitting slots to be connected at the beginning or end of slot groups or the slot list itself. Combiners may safely have state and are accessible from the signal. * Utility: class template result_of added. * Test Library: - namespace names gets shorten; old one still supported till next release. - added proper encoding of XML PCDATA. - support for wide string comparison implemented. For complete list of changes see Test Library release notes. Regression tests ----------------- This release has been extensively tested on a variety of different compilers and platforms. It is known to contain no regressions against the previous reference release on the compilers and configurations tested. Please refer to the corresponding regression reports at http://www.meta-comm.com/engineering/boost-regression/1_32_0 to see how well your compiler performs on the new Boost codebase. Acknowledgements ---------------- This release wouldn't have been possible without the dedicated effort of many, many members of the Boost community who generously contributed their outstanding expertise, time and energy to making it happen. For patches, bug fixes, troubleshooting, expert advice, and prompt responses to the release manager's requests we thank: David Abrahams, Misha Bergal, Jonathan Brandmeyer, Fernando Cacciola, Marshall Clow, Christopher Currie, Pavol Droba, Caleb Epstein, Eric Friedman, Jeff Garland, Michael Glassford, Doug Gregor, Joel de Guzman, Hubert Holin, Jaakko Jrvi, Hartmut Kaiser, Bronek Kozicki, Tarjei Knapstad, Toon Knapen, Aaron W. LaFramboise, Joaqun M Lpez Muoz, Christoph Ludwig, John Maddock, Paul Mensonides, Guillaume Melquiond, Thorsten Ottosen, Vladimir Prus, Robert Ramey, Rene Rivera, Gennadiy Rozental, Stefan Slapeta, Jonathan Turkanis, Pavel Vozenilek, Jonathan Wakely, Daryle Walker, Victor A. Wagner Jr. and Martin Wille. Also, our special thanks go to: John Maddock for the managing the effort of converting the majority of the Boost libraries to the Boost Software License, Eric Niebler and Joel de Guzman for taking on the important job of improving the Boost documentation's look and feel, and last, but not least, to our regression test runners, without whom we simply would never have released: Toon Knapen, Bronek Kozicki, Rene Rivera, Markus Schpflin, Stefan Slapeta, Victor A. Wagner Jr. and Martin Wille. Thank you everybody! -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Iterator nesting
by Rodrigo de Salvo Braz 20 Nov '04

20 Nov '04

Hello, Suppose I have a container of containers and would like an iterator that goes through all of their elements as if they are coming from a single container. I thought I would see some Boost class helping me to do that but I couldn't find anything like that. Can someone please tell me if that is true, and if not, which class can I use to that effect? (In fact this concept is more general and interesting. The objects in the first-level containers may not be containers but have members which are containers and whose elements I want to iterate through. Or they could be iterators. The general case should allow a parameterizable way of obtaining an iterator to the elements inside the second-level objects. This could again be a nesting iterator, allowing for arbitraty nesting. Since this is a fairly common need in programming, I was expecting something that did that in Boost.) Thanks, Rodrigo

2 1

Another weird boost::variant problem.
by Bo Peng 19 Nov '04

19 Nov '04

Dear list, I have a problem with apply_visitor of boost::variant. It seems to me that it can not accept a temporary variant variable that is returned from a function. Is this a bug? Here is a simple example: =================================== #include "boost/variant.hpp" using namespace std; #include <string> typedef boost::variant<double, string > Variable; #include <iostream> // a simple visitor that returns a variant. class variantPlusOne : public boost::static_visitor<Variable> { public: Variable operator()( double i) const { return Variable( i + 1 ); } Variable operator()( string str) const { return Variable( 0); } }; // apply_visitor in function form Variable func(Variable a) { return boost::apply_visitor( variantPlusOne(), a); } // a silly function. Variable me(Variable a) { return a; } int main() { Variable b("5"); cout << func(b) << endl; // OK cout << func(me(b)) << endl; // OK cout << boost::apply_visitor(variantPlusOne(), b ) << endl; // OK // cout << boost::apply_visitor(variantPlusOne(), me(b) ) << endl; // NO return 0; } ///////////////////////////// The error messages are: test.cpp:44: no matching function for call to `apply_visitor(variantPlusOne, Variable)' boost_1_31_0/boost/variant/detail/apply_visitor_unary.hpp:59: candidates are: Visitor::result_type boost::apply_visitor(Visitor&, Visitable&) [with Visitor = variantPlusOne, Visitable = Variable] boost_1_31_0/boost/variant/detail/apply_visitor_unary.hpp:75: Visitor::result_type boost::apply_visitor(const Visitor&, Visitable&) [with Visitor = variantPlusOne, Visitable = Variable] /////////////////////////////// Note that I can understand this behavior if the visitor takes reference arguments (and therefore expects a persistent variable) but my visitor pass argument by values. Thanks. Bo

1 0

boost::filesystem::path - where are the attributes?
by Pete 19 Nov '04

19 Nov '04

I'm not sure if I'm missing something or not, but I couldn't find anything in the filesystem documentation that allows one to retrieve file/directory attributes such as: Date created/last accessed/last modified Hidden System Read Only Link Etc. I'm particularly interested in portable file date accessors (hoping to find methods in the path class returning boost::posix_time::ptime). Are there any known workarounds?

2 2

function_traits of bind - functors possible?
by Roland Schwarz 19 Nov '04

19 Nov '04

Is it possible to use function_traits for functors that have been created with bind? I.e.: template<Function> foo (Function f) { typedef typename boost::function_traits<Function>::type fn_t; boost::signal<fn_t> sig; } .... foo(boost::bind(fobar, this, _1)); Apparently the above does not work, but I cannot figure out what I am missing. Roland

1 0

FW: Leak when using boost threads under VC .NET using statically linked CRT
by alansa＠ati-uk.com 19 Nov '04

19 Nov '04

The following code leaks memory for each iteration of the loop for (;;) { boost::thread t(func); t.join(); } void func() { cout << "------" << endl; } If I replace func with func2 void func2() { try { throw 1; } catch {} } then it still leaks. But if I say fill up a vector with stuff or just return there is no leek. The interesting part is that it doesn't leak if use the version of threads built using the CRT as a .dll rather than static link. I also believe that the actual culprit is somewhere in boost.function since the code for boost.thread is so straight forward. I'm currently using boost 1.30 so it might have already been addressed in newer versions. Can anyone help?

2 1

Signals & Slots
by Foster, Gareth 19 Nov '04

19 Nov '04

I think if you just follow through the different typical tasks you might undertake with the two libraries as Murray wrote: " 1. Create a signal 2. Connect a slot (callback function) to a signal. 2.2 For a member method. 2.3 For a non-member or static function. 3. Disconnect a slot. 4. Bind an extra parameter, so that e.g. a slot with 4 parameters can be used with a signal with 3 parameters. I don't personally find the more complex adaptors interesting. " Then write up a document where, in each case, the code needed for both libraries is given, and then I small discusion about any differences or similarities. Perhaps in each case, giving some approximate figure to indicate the similarity would be useful. Presumably, this could then end up in the appendix of, or being referenced by, a proposal for a standard signals/slots interface. I don't know what is involved to be honest. I suppose, it needn't be just the one person doing the comparison, there are four tasks in the list (and maybe a few more besides), so four people could spread the work load, and maybe a 5th could add final conclusions and draw together the others notes. Cheers all, Gaz -----Original Message----- From: libsigc-list-bounces(a)gnome.org [mailto:libsigc-list-bounces@gnome.org] On Behalf Of Carl Nygard Sent: 18 November 2004 19:20 To: Doug Gregor Cc: libsigc-list(a)gnome.org; boost-users(a)lists.boost.org; gtkmm-list(a)gnome.org Subject: Re: [sigc] Re: [Boost-users] Signals & Slots 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. I'm in a reasonably sane position to do this, although only time will tell if what comes out is useful to anyone or not. Regards, Carl _______________________________________________ libsigc-list mailing list libsigc-list(a)gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list

1 0

SV: [Boost-users] Manual in pdf?
by Daniel Lidström 19 Nov '04

19 Nov '04

) ) Daniel Lidström writes: ) > Hi, ) > ) > is the manual available in pdf or postscript? Or is there a way ) > to print it? The online manual is not very printer-friendly. ) ) Daniel, ) ) I assume you are talking about Boost-wide PDF (some of the Boost ) libraries/tools provide a standalone one on their own). In that case, ) it's not available for 1.31; we are working on making it available in ) the upcoming 1.32.0, which is due in a couple of days. ) How about the Spirit manual? Will it be available in printable format with 1.32.0? Thanks! -- Daniel

2 1

Spirit help (again)
by Cory Nelson 19 Nov '04

19 Nov '04

Okay, I'm trying to learn Spirit and I've got the grammar down. I've tried looking at the documentation but still can not find out how to make a custom parser (that will let me use the [action] operator). Could someone give an example of a pascal string parser (one byte for length, string follows) to get me started? -- Cory Nelson http://www.int64.org

4 5

MPL Library
by Edward Diener 18 Nov '04

18 Nov '04

I have bit the bullet and am attempting to get my head around the MPL library. I realize there is a book out by Messieurs Abrahams and Gurtovoy, I believe, but I thought I would tackle the boost documentation first. A few questions: 1) Is the documentation up to date ? 2) There are three separate documents to study, it seems, all giving information about the MPL library, a white paper circa 2002, a reference, and a mini-tutorial. Is the information in these in sync with each other ? The reason I ask is that the white paper/mini-tutorial mentions if_<> and apply_if<> but the reference does not mention them at all.Are they just understood intrinsic metafunctions that need no reference, or what ? If the former, are there more of these intrinsic metafunctions and, if co, what are they and what do they do ? 3) A number of the topics in the reference documentation mentioned in generalized overviews of the various sections have no specific links. Does this mean that they were never implemented ? Seems dubious in a number of cases. I would seriously like to figure out how MPL works and play around with it, but I feel stymied with what is in the boost docs.

3 6

Key iterators
by Chris Goller 18 Nov '04

18 Nov '04

I'm just getting into boost and I really like it. I would like to iterate over keys of a multimap. so it would look like this: std::multimap<type, type>::key_iterator i = map.beginkey(); i != map.endkey(); i++ at each i++ it would move to the next key. -or- for_each(map.beginkey(), map.endkey(), whatever); Is this possible with the boost iterators? Thanks, Chris

5 5

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

18 Nov '04

On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote: >> Very simple explanation here: my comments were about libsigc++ 1.2. > > It would be best for us to ignore them then. The differences are quite > large. Yes, please ignore them. >> I've glanced briefly at libstdc++ 2 > > For the record, Doug almost certainly means "libsigc++" instead of > "libstdc++". Correct. >> and was pleasantly surprised. I'd >> like to look into it further, but do not have the time now. I've been >> saying for a while that the Signals interface is not ready for >> standardization because we only had the one implementation (in Boost) >> and that it was not solid enough for standardization. However, with >> libstdc++ 2 adopting a similar interface, we might be able to converge >> on a single, solid interface for Signals & Slots within the C++ >> Standard Library. Library Technical Report 2 is open for submissions, >> and signals & slots have been on the wish list since the beginning... >> >> In any case, a thread titled "Boost Signals & Slots vs. libsigc++" is >> treading on dangerous territory :) > > I doubt that Boost Signals and libsigc++ 2 are significantly different. My cursory review of the libSIGc++ 2 reference documentation seems to indicate that the interfaces are similar. > A comparison should probably start by looking at the application code > needed to > 1. Create a signal > 2. Connect a slot (callback function) to a signal. > 2.2 For a member method. > 2.3 For a non-member or static function. > 3. Disconnect a slot. > 4. Bind an extra parameter, so that e.g. a slot with 4 parameters can > be > used with a signal with 3 parameters. I don't personally find the more > complex adaptors interesting. 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. > Please do try to warn us if Boost Signals seems near to being > approved. We > would like to try porting gtkmm to it then. There is no current effort to write a proposal to bring the Boost.Signals interface to the C++ committee (that I know of). If this does happen, it will be _after_ we have a detailed comparison of both libraries and, of course, I will announce it on both the libSIGc++ and Boost mailing lists. Doug

1 0

Re: [Boost-users] Signals & Slots
by Foster, Gareth 18 Nov '04

18 Nov '04

Doug, This is what murray had to say on the GTKmm list (future correspondance, if any, to be on the libsigc++ list), it's a very pleasing response I'm sure you will agree. Perhaps you could qualify you last statement though, that one seems to have murray a little stumped. Cheers! Gaz -----Original Message----- From: Murray Cumming [mailto:murrayc@murrayc.com] Sent: 18 November 2004 09:50 To: Foster, Gareth Cc: 'gtkmm-list(a)gnome.org'; libsigc-list(a)gnome.org Subject: Re: [Boost Signals & Slots] Vs [libsigc++] Questions comparing boost::signal to libsigc++ belong on the libsigc++ mailing list. I'm CCing it. boost::signal was developer in cooperation with Karl Nelson, the main original libsigc++ developer. Also, the libsigc++ 2 API was redesigned to be as much like boost::signal as possible, so that gtkmm can easily switch to boost::signal if it becomes an API-stable dependency or it is added to the C++ Standard Library. gtkmm has a long-standing policy of not reimplementing things when we can just reuse them. This part makes no sense to me. It would have to be explained properly before we could comment: " Basically, libsigc++ is a monolithic entity covering single and multiple-target callbacks, slots, and slot binding, Signals tackles only the multiple-target callbacks, relying on other Boost libraries (especially Function and Signals) to do most of the work, so it integrates cleanly with the rest of Boost. " Murray > Hello all, > > As you will see in the forward email below, I was chatting to a bloke who > works on boost::signal, I wondered how this stacked up against libsigc++, > and whether there was any chance it could be used in GTKmm and suchlike. A > GTKmm developer did pop up on the boost list and make the valid point that > API stability would be a major issue, nevertheless, I thought I'd send > this > out, and see what people here had to say. As I said on the boost list, I > am > thinking more ... > >> "hey, what do you think to this lads" than an outright "you should be > using Boost heathens!" > > I hope such discussion isn't offtopic. > > Thanks all! > > Gaz > > > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: 17 November 2004 15:49 > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Signals & Slots > > > On Nov 17, 2004, at 9:20 AM, Foster, Gareth wrote: >> I was just reading some mention of bugs in boost::signal, > > They weren't actually bugs :) > >> is this >> implementation in competition with libsigc++? i.e. does it aim to do >> the >> same job, but under a different license, or is there perhaps some >> fundamental design difference between the two? > > The Signals library aims to be much more flexible than libsigc++ and to > have an interface that is more comfortable for Boost. For instance, > slots are just function objects with similar signatures (like > Boost.Function, because Function is used in Signals), one can combine > the results of calling multiple slots into a single return value via an > arbitrary function object, and the lifetime of signals & slots is > automatically tied to "trackable" objects used in bind expressions to > build slots. > > Basically, libsigc++ is a monolithic entity covering single and > multiple-target callbacks, slots, and slot binding, Signals tackles > only the multiple-target callbacks, relying on other Boost libraries > (especially Function and Signals) to do most of the work, so it > integrates cleanly with the rest of Boost. > > Doug > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > _______________________________________________ > gtkmm-list mailing list > gtkmm-list(a)gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list > Murray Cumming murrayc(a)murrayc.com www.murrayc.com www.openismus.com

4 4

Win32: Overloaded std::min and std::max
by boost＠dalvander.com 18 Nov '04

18 Nov '04

Hi all, A day ago I stumbled upon a problem using std::min and std::max when having included any boost header file on Win32 machine. The following code should not compile, according to the C++ standard: float f = 47.9999f; long l = 47L; std::max(f, l); // This should fail as the arguments aren't of the same type. But using boost (and Microsoft Visual C++ .NET 2003), it magically did. I tracked down the problem and found a 'fix' in <boost_1_31_0/boost/config/platform/win32.hpp> that looks like this: -----8<----------8<----------8<----------8<----------8<----- #ifdef BOOST_MSVC #include <algorithm> // for existing std::min and std::max namespace std{ // Apparently, something in the Microsoft libraries requires the "long" // overload, because it calls the min/max functions with arguments of // slightly different type. (If this proves to be incorrect, this // whole "BOOST_MSVC" section can be removed.) inline long min(long __a, long __b) { return __b < __a ? __b : __a; } inline long max(long __a, long __b) { return __a < __b ? __b : __a; } // The "long double" overload is required, otherwise user code calling // min/max for floating-point numbers will use the "long" overload. // (SourceForge bug #495495) inline long double min(long double __a, long double __b) { return __b < __a ? __b : __a; } inline long double max(long double __a, long double __b) { return __a < __b ? __b : __a; } } using std::min; using std::max; # endif -----8<----------8<----------8<----------8<----------8<----- I think that that block of code should be removed as it is illegal to overload any function in the standard library, according to the C++ standard, and that it also makes illegal code to compile. Cheers, Dalle

2 1

RE: [Boost-users] Signals & Slots
by Foster, Gareth 18 Nov '04

18 Nov '04

Cheers Doug, I was thinking more of a, "hey, what do you think to this lads" than an outright "you should be using Boost heathens!" :) Sound advice nontheless mate, I'll keep you posted. Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 17 November 2004 20:25 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Signals & Slots On Nov 17, 2004, at 11:34 AM, Foster, Gareth wrote: > Thanks for the reply Doug, do you mind at all if I forward this to the > GTKmm > mailing list? Go ahead. > I would like to ask them what they think of your > implementation. I hope to use GTKmm (which uses libsigc++ of course), > and I > think boost is great, so I'd be interested to see if maybe the GTKmm > devs > could be using boost more etc. I'm sure you get the idea, main thing > is, I > don't want it to look like I am trying to start a slaging match (hence > me > asking first) :) I would suggest learning quite a bit about both libsigc++ and Boost.Signals before you try to suggest to anyone that they make such a switch, because it will surely require a significant amount of effort and may change the semantics of GTKmm considerably. Doug _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

uBlas bindings in boost 1.34
by Thomas Lemaire 18 Nov '04

18 Nov '04

dear list, looking at http://www.meta-comm.com/engineering/boost/1_32_0_draft/ it seems that uBlas bindings to LAPACK, ATLAS,... are not included in the 1.32 release, but it has been annouced on this list that they would be... Am I wrong ? What happened ? cheers, -- thomas

3 3