- Boost-users - lists.boost.org

[1.46.0 beta 1] [SourceForge] SourceForge mirror sync system broken
by Beman Dawes 01 Feb '11

01 Feb '11

The SourceForge mirror sync system has broken down. Other projects are affected, not just Boost. The files up there are probably good and the download problems should clear once the mirrors are synced again, the S/F folks say. Some projects say their files are back online, but as of a few minutes ago the Boost stuff still seemed broken and/or running so slowly as to be effectively broken. --Beman

3 4

[boost.test] benchmarking support
by Marco Craveiro 01 Feb '11

01 Feb '11

hi boosters, i've been looking for benchmarking support for unit tests, but googling didn't produce any obvious results (and a wealth of spurious matches, so i may have missed something). what i have in mind is something akin to cppbench but for boost.test: http://blog.quibb.org/cppbench/ basically, something that allows repeating each test a number of times, and then time the total execution time per test. is this available? if not, can anyone recall any discussions on the subject? many thanks for your time, marco -- Constraint has encouraged not only economy, but also a certain elegance of design. -- Dennis Ritchie

3 4

[Review][Move] Boost.Move Review Results
by Michael Caisse 01 Feb '11

01 Feb '11

---------------------------- Executive Summary ---------------------------- Ion Gaztañagas' Boost.Move library was reviewed from May 10th, 2010 through May 24th, 2010. The original review manager was OvermindDL1 who later went missing. Eleven individuals joined the discussion with the author. Six reviews were submitted: - 5 reviews ACCEPT - 1 review CONDITIONALLY ACCEPT Ion indicated he would meet the "conditional requirements" which easily satisfies a community vote of: Boost.Move library ACCEPTED ---------------------------- Overview ---------------------------- The Boost.Move library is a highly anticipated addition to the Boost collection. The primary motivation is to introduce usable move functionality in "a portable syntax between C++0x and C++03 compilers"; however, as Vicente Botet articulated, "Most people think that this is an emulation library, but it is more than that as it implements most of the C++0x Move semantics classes and functions." Reviewers' comments: - "This library is long overdue!" [Terry Golubiewski] - "The tutorial is well written." [Vicente Botet] - "Compared to my adobe based move implementation, I think yours is superior." [Daniel James] - "There is a lot of ingenuity in making the move emulation work, and Ion has made it very accessible and managed to make differences between C++03 and C++0x vanish behind macros and free functions." [Jeff Hellrung] An active discussion included: - exposing boost::rv<T> publicly - The merits of fully defining requirements of boost::rv<T>& - Duplicated functionality found in MPL and Type Traits - The necessity for two emulation modes - The merits of macros - Library author usage of Boost.Move - Non-throwing move constructors - Various potentially useful type traits - Other move implementations While it is unfortunate that a timely review result was not published, it did provide an opportunity to discuss some of the concerns raised in the review with actual users of the library. One such concern was the "two emulation modes." At some point in the discussions it became classified as "Safe vs. Fast". When coined with that bias "safe" would be the preference; however, further investigation and inquiries of actual users showed the "fast" version is perfectly acceptable as the default. Additionally, "safe" is a misnomer considering that one mode is not any safer than the other. Each mode has benefits and limitations as enumerated by Ion in the documentation and review responses. The past six months of use would indicate that defaulting to the "fast" version, as preferred by Ion, is in practice a good decision. Thank you Ion for this well thought out and excellent submittal. Thank you reviewers for expending time and energy to further Boost. Without those who are dedicated to review submitted libraries, the entire process and Boost itself falls apart. The community will benefit from the effort each of you put into this library. Best regards - Michael Caisse ---------------------------- Summary of changes ---------------------------- The following changes are planned based on discussions from the review: -- Conditional Acceptance -- 1. "Two Emulation Mode" documentation typos must be resolved. The descriptions, requirements and limitations need to be perfectly clear for the end user. -- Other Issues -- 1. The class rv should be public and documented. 2. is_movable should be renamed and the documentation clarified. It should only be enabled in C++03. A possible alternative name is has_move_emulation_enabled. 3. Nearly all reviewers voiced a preference that the move library should use existing functionality from MPL and TypeTraits libraries. While on one hand this creates a dependency between move and other libraries it results in reuse of accepted and well tested libraries. If a non-coupling option is also provided, it should not be the default. 4. Additional traits discussed. Resolution: add to TypeTraits library as actual use-cases are found. 5. Provide a boost/move.hpp that includes boost/move/move.hpp 6. Document the interaction of the two emulation modes. 7. Include example for making a container "movable". 8. Two emulation modes - Ion was hopeful that reviewers would have a uniform opinion that would result in a single mode. The trade-offs identified by Ion in the documentation were apparent to all reviewers; however, different conclusions were drawn and consensus was not met. The granularity of control was a common issue with nearly all reviewers. Therefore, keep both emulation modes with Optimized as the default and the granularity of control at or more "local level" than the macro provides (class level). 9. emulation_limitations.html: s/overaloading/overloading/ 10. Fully qualify enable_if ( ::boost::emable_if ) 11. Optimized version of forward should use identity so it will not try to deduce T. 12. Make sure required headers are mentioned for tutorials. 13. is_class in is_movable template< class T> struct is_movable : mpl::and_< is_class<T>, mpl::not_< is_rvalue_reference<T> >, is_convertible< T, rv<T>& > > {}; - or - another solution to is_movable problems with references. 14. On throwing move constructors, Ion should follow as close to the standard's behaviour as possible. This can be revisited after the initial release since it is a performance optimization. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

win32 api
by Gianni Ambrosio 01 Feb '11

01 Feb '11

Hi All, I'm working on a piece of code that should run on a special real-time kernel that supports only a minimal set of win32 api. I would like to use boost sockets and threads but it seems there are some dependencies on win32 api not supported by that system (i.e. WSARecvFrom, WSASend, WSASocketA, WSAStringToAddressA). Is there a way to build boost libs with some options so that the C socket calls are used instead? I'm asking too much? Regards Gianni

2 4

Planar Embedding of a Graph
by Nitin Gangahar 01 Feb '11

01 Feb '11

Hi all! I am totally new to the Boost Library. I just wanted to know if BGL supports finding if a graph is planar or not and also the planar embedding of a graph. Thanking you, Nitin Gangahar

2 2

Compiling Boost
by Bhushan Inamdar 31 Jan '11

31 Jan '11

Hi all, I have installed Boost 1.44 and I have a program from a tutorial I am trying to compile with out success. The program is as follows: =============================================================================== #include <iostream> #include <vector> #include <algorithm> #include <boost/shared_ptr.hpp> using namespace::std; struct Boost_Example { Boost_Example(int _x) : x (_x) { } ~Boost_Example() { std::cout << "Destroying Boost_Example x = " << x << "\n"; std::cout << endl << endl << " "; system("PAUSE"); cout << endl << endl; } int x; }; typedef boost::shared_ptr<Boost_Example> Boost_ExamplePtr; struct Boost_ExamplePtrOps { bool operator()(const Boost_ExamplePtr &a, const Boost_ExamplePtr &b) { return a->x < b->x; } void operator()(const Boost_ExamplePtr &a) { std::cout << " " << a->x; } }; int main() { std::vector<Boost_ExamplePtr> Boost_Example_Vector; Boost_Example_Vector.push_back(Boost_ExamplePtr(new Boost_Example(3))); Boost_Example_Vector.push_back(Boost_ExamplePtr(new Boost_Example(2))); Boost_Example_Vector.push_back(Boost_ExamplePtr(new Boost_Example(1))); // std::cout << endl << endl; std::cout << " Original Boost_Example_Vector" ; std::for_each(Boost_Example_Vector.begin(), Boost_Example_Vector.end(), Boost_ExamplePtrOps()); std::cout << "\n"; // std::sort(Boost_Example_Vector.begin(), Boost_Example_Vector.end(), Boost_ExamplePtrOps()); std::cout << endl << endl; std::cout << "Sorted Boost_Example_vector: " ; std::for_each(Boost_Example_Vector.begin(), Boost_Example_Vector.end(), Boost_ExamplePtrOps()); std::cout << " \n"; // std::cout << endl << endl << " " ; system("PAUSE"); std::cout << endl << endl; // return 0; } ============================================================================= Just create an empty VC++ project and add a source file to it. Then paste this code in the source file. I believe that, if Boost is correctly installed on one's machine, this should compile correctly. For additional information, I have set up the include and lib directories as under: includes: $(BOOST_ROOT)boost libs $(BOOST_ROOT)stage\lib $(BOOST_ROOT)libs $(BOOST_ROOT)bin.v2 In the above paths, $(BOOST_ROOT) is added to "System Variables" under the "Environment Variables" as C:\Program Files\boost\boost_1_44_0 where it is installed. Shall a "\" be added in the end? Or shall this variable be added to "Path variables" instead of "System variables"? I believe that my environment is rightly setup. But I am still having problems building a simple console application. I am using Visual Studio 2008 on Windows 7. Please let me know, what to do and where to check for the missing block? Thanks and regards, Bhushan

2 1

Problems with testing a putatively successful build using cygwin
by Ted Byers 31 Jan '11

31 Jan '11

I tried the following: ./bootstrap.sh --exec-prefix=/usr/local ./bjam --layout=versioned --build-type=complete cd status ../bjam And I was planning the following if the result of the above was acceptable. ./bjam install However, every time I have tried this, it stops part way through, at the following the last few lines: ../boost/iterator/iterator_facade.hpp:514: warning: type qualifiers ignored on function return type gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/thread ing-multi/regress/test_unicode.o In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14, from ../boost/date_time/posix_time/ptime.hpp:12, from ../boost/date_time/posix_time/posix_time_types.hpp:12, from ../boost/thread/thread_time.hpp:11, from ../boost/thread/locks.hpp:12, from ../boost/thread/pthread/mutex.hpp:12, from ../boost/thread/mutex.hpp:16, from ../boost/thread/pthread/thread_data.hpp:12, from ../boost/thread/thread.hpp:17, from ../boost/thread.hpp:13, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp: 22, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_unicode.cpp:21: ../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/thread ing-multi/regress/test_overloads.o In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14, from ../boost/date_time/posix_time/ptime.hpp:12, from ../boost/date_time/posix_time/posix_time_types.hpp:12, from ../boost/thread/thread_time.hpp:11, from ../boost/thread/locks.hpp:12, from ../boost/thread/pthread/mutex.hpp:12, from ../boost/thread/mutex.hpp:16, from ../boost/thread/pthread/thread_data.hpp:12, from ../boost/thread/thread.hpp:17, from ../boost/thread.hpp:13, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp: 22, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_overloads.cpp:1 2: ../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/thread ing-multi/regress/test_operators.o In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14, from ../boost/date_time/posix_time/ptime.hpp:12, from ../boost/date_time/posix_time/posix_time_types.hpp:12, from ../boost/thread/thread_time.hpp:11, from ../boost/thread/locks.hpp:12, from ../boost/thread/pthread/mutex.hpp:12, from ../boost/thread/mutex.hpp:16, from ../boost/thread/pthread/thread_data.hpp:12, from ../boost/thread/thread.hpp:17, from ../boost/thread.hpp:13, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp: 22, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31, from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_operators.cpp:1 2: ../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant gcc.link ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/thread ing-multi/regex_regress_threaded.exe The last gcc.link statement above has been the last statement in the cygwin bash console for about 12 hours now. I am rather surprised that either bjam or a test program it is running can stop like that and not have bjam detect it and respond appropriately. Is there a way to prevent this from happening? I know (from having tried it), that I can terminate this and re-execute bjam in status, and that that will finish, but doing that doesn't tell me what fraction of tests succeeded. Rather, it tells me only about those targets that were found, and their result, during the current executin. Obviously, it will ignore all the tests that had been performed previously. I also see a lot of files created in status during the test. Is there a script that will process the contents of status and tell me at least the sort of info provided in the table on " http://www.boost.org/development/tests/trunk/developer/summary.html"? Thanks Ted

1 0

[1.46.0 beta 1] Release 1.46.0 beta 1 available
by Beman Dawes 31 Jan '11

31 Jan '11

Boost release 1.46.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains one new library, Interval Containers, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_46_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

2 1

getting a return value from a bind?
by pedro chaparro 31 Jan '11

31 Jan '11

hi , i have on my code something like boost::thread thrd(boost::bind(&myioTCPLTE,TCPmsg)) function myioTCPLTE return a string value, bu i dont now how to get it to store in a different variable from the main code!! Could anyone help me? thanks -- Pedro Alonso Chaparro Valero R&D Engineer Ciudad Politecnica de la Innovación iTEAM - Mobile Communications Group Polytechnic University of Valencia C\ Camino de Vera S/N, Edificio 8G 46022 Valencia, Spain

2 1

Re: [Boost-users] [Asio] Socket Read/Write Thread-Safety (Timothy Liang)
by Marat Abrarov 31 Jan '11

31 Jan '11

> The 'boost::asio::async_read(...)' and 'boost::asio::async_write(...)' > functions might call async_read_some and async_write_some concurrently in > some scenarios, as they do not synchronize accesses to the stream object > that I'm passing to them as a reference. A look in their implementations > confirms this: if the stream's async_read_some or async_write_some didn't > satisfy the completion condition, it tries again, using the same reference > to the stream object. With multiple threads calling > io_service::run_one(), the result can be one thread calling > async_read_some while another is calling async_write_some at the same > time. This seems to prevent me from using async_read and async_write at > all, so I'm wondering if the stream has some undocumented thread-safety > guarantees, or if there's a proper way to achieve the same effect. RTFM. Really, RTFM. Use boost::asio::io_service::strand and don't worry about synchronization. http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/overview/core/stran ds.html You can use async_read and async_write simultaneously (but note "Thread Safety" for used asio class) with strands easily. Yes, with multiple threads running boost::asio::io_service::run on the same boost::asio::io_service object. What amazing laziness in reading asio docs :) - all of the latest questions about Boost.Asio have respective answers in documentation. Marat Abrarov.

2 1