- Boost - lists.boost.org

[thread] Full scale breakage on gcc, cxx, acc
by Markus Schöpflin 22 Oct '07

22 Oct '07

Hello, changeset 40191 introduced a full scale breakage of the thread library. I committed the following fix: http://svn.boost.org/trac/boost/changeset/40277. Could the author please check if this is OK? Markus

3 2

[callback abstraction]Determining interest for proposal
by Miguel Tadeu 22 Oct '07

22 Oct '07

I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations: - when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus ) and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements. Thanks, Miguel Tadeu

7 10

[Fusion] Onward towards 2.1
by Joel de Guzman 21 Oct '07

21 Oct '07

Hi, Well, heads up. I'm doing lots of refactorizations. It all started with the include dependency bug noted by John Maddock. There's a nasty cyclic dependency happening somewhere that I tried to track. Along the way, I caught unwanted dependencies that stem from violations of the modular design of fusion that allows (by protocol) only acyclic module relationships. A bit of refactorizations after, the new layer/module hierarchy is (hight to low): mpl algorithm | functional container | view | adapted | tuple sequence iterator support This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 8

Bind and MSVC 8 SP1
by Ben Pope 20 Oct '07

20 Oct '07

Hi, I just started testing Boost 1.34.1 and have found this piece of code produces a warning, which was not present in Boost 1.33.1: --- #include <boost/bind.hpp> struct Foo {}; struct Bar { Foo GetFoo() { return Foo(); } }; int main() { Bar bar; boost::bind(&Bar::GetFoo, bar); } --- 1>boost\boost.1.34.1\boost\boost\bind.hpp(1575) : warning C4180: qualifier applied to function type has no meaning; ignored 1> boost\boost.1.34.1\boost\boost\bind.hpp(1609) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=Foo (__thiscall Bar::* )(void), 1> I=1 1> ] 1> test1\test1.cpp(16) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=Foo (__thiscall Bar::* )(void), 1> A1=Bar 1> ] It seems to pick this specialisation: template< class M, class T > struct add_cref< M T::*, 1 > { typedef M const & type; //bind.hpp(1575) }; When I would have thought this one more appropriate: template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; // bind.hpp(1580) }; Any ideas? Thanks, Ben

4 6

Attn: users of minimal.hpp and boost/test/included headers
by Gennadiy Rozental 20 Oct '07

20 Oct '07

Hi, Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included. This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0. Gennadiy

5 10

[dynamic overload] proof of concept implementation - new version available
by Marco 20 Oct '07

20 Oct '07

I uploaded to boost vault a new version of my implementation of Boost.Overload: /overload-mrcec/overload-0.2.1.zip , link: http://tinyurl.com/37647m Boost Overload behaves as an overloaded Boost Function. Actually it wraps multiple Boost Function objects of different signatures. What's new: I only fixed some issue after testing the code on more compilers. This is the current status: compiler OS test ------------------------------------------- gcc 4.1.2 under Linux pass intel 9.1 under Linux pass mingw 3.4.2 under Windows pass mingw 3.2.3 under Windows fail MS VC++ 8.0 under Windows pass MS VC++ 7.1 under Windows fail I arranged this and previous version in boost vault in a specific folder: /overload-mrcec You find a description of each version in the file README_FIRST.TXT, link: http://tinyurl.com/32hv3p You can read a preliminary introduction to boost overload here: http://tinyurl.com/3xtbyl The documentation has been kindly written down by Dean Michael Berris. You can read an informal tutorial here: http://docs.google.com/Doc?id=dfxvjncs_1x6456m Please report any bug, compiler issue, comment and suggestion. They are really appreciated. Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

2 2

[test] Another Boost.Test failure.
by John Maddock 20 Oct '07

20 Oct '07

There are more Boost.Test failures coming through caused by the recent changes - this time Intel-10 on Win64 is failing most of the math lib tests with: http://tinyurl.com/2quy5h John.

3 6

[test] Changes break Borland support
by John Maddock 20 Oct '07

20 Oct '07

The recent changes to Boost.Test have broken Borland support, see for example: http://tinyurl.com/34wlps Starting to get frustrated yours, John :-(

3 4

[intrusive] Looking for some advice on intrusive splay trees
by Ion Gaztañaga 20 Oct '07

20 Oct '07

Hi to all, Lately I've been trying to implement splay trees for Intrusive. Excerpt taken from en.wikipedia.org/wiki/Splay_tree: "A splay tree is a self-balancing binary search tree with the additional unusual property that recently accessed elements are quick to access again. It performs basic operations such as insertion, look-up and removal in O(log(n)) amortized time. For many non-uniform sequences of operations, splay trees perform better than other search trees, even when the specific pattern of the sequence is unknown. The splay tree was invented by Daniel Sleator and Robert Tarjan." As most of you know, splay trees splay (rebalance) the tree also on searches, so that the target node is placed as root, yielding to better search times for frequently searched nodes (cache effect). The implementation I've taken as model is taken from the article written by Ralf Mattethat for C++ Users Journal (September 2005) titled "Implementing Splay Trees in C++" (http://www.ddj.com/architect/184402007) Following usual STL-like implementations I've used left and right pointers of the header to point to the leftmost and rightmost node respectively. Several intrusive rbtree implementation tricks and optimizations can be easily reused for splay trees so I think we can have a useful intrusive splay tree. My main issue is related to constness and thread-safety. I would like to offer a STL-like interface (that is, the interface actually implemented for other Intrusive containers like set, multiset and rbtree), but take in care that the tree will rebalance in each find/lower_bound/upper_bound operation so those operations couldn't be const members unless we declare the header as mutable. I plan to add optional (runtime) rebalancing for each operation (for example, the user could call find() without rebalancing if he doesn't want to alter the cache effect, or just needs more predictable search times). iterator it = splay_tree.find(a);//Splay operation performed iterator it = splay_tree.find(a, dont_splay);//No splay Allowing const overloads (casting the constness away internally) with splaying (rebalancing): const_iterator it = const_splay_tree.find(a); //Splaying performed would break usual de-facto thread-safety guarantees for STL and Intrusive containers (read-only access from different threads is thread-safe). So the main question is: what approach do you think would be better? ¿Just splay in const operations and put a thread-safety warning? ¿Make const versions non-splaying? ¿Don't offer const versions of search functions? Regards, Ion

5 7

Re: [boost] [callback abstraction]Determining interest for proposal
by Miguel Tadeu 20 Oct '07

20 Oct '07

Files are in source forge: http://sourceforge.net/projects/abstractcall/ - formating needs real polishing - want to make some changes...just don't know how, yet - comments are very wellcome, 'cos even if it's not accepted, I'll be using this in my projects

1 0