April 2012 - Boost - lists.boost.org

[concept_check] addable
by lcaminiti 23 Apr '12

23 Apr '12

Hello all, Does this Addable concept definition make sense to you? Is there any error? #include <boost/concept_check.hpp> template<typename T> struct Addable { // User-defined concept. BOOST_CONCEPT_USAGE(Addable) { return_type(x + y); // Check addition `T operator+(T x, T y)`. } private: T x; T y; void return_type(T const&); // Used to check addition returns type `T`. }; It's not making Sun's linker happy: "/opt/sunstudio12.1/bin/CC" -g -library=stlport4 -features=tmplife -features=tmplrefstatic -library=stlport4 -m64 -KPIC -o "/scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq" "/scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq.o" -Bdynamic -lrt -Bstatic -Bdynamic Undefined???first referenced symbol ??? in file void Addable<int>::return_type(const int&) /scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq.o ld: fatal: Symbol referencing errors. No output written to /scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq But the error might also be somewhere else in the program that checks the concept, I'm still debugging... Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-concept-check-addable-tp4572138p45… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 5

[filesystem] #6521 Directory listing using C++11 range-based for loops
by Beman Dawes 23 Apr '12

23 Apr '12

Ticket #6521 requests adding: class directory{ path p_; public: inline directory(path p):p_(p){} directory_iterator begin(){ return directory_iterator(p_); } directory_iterator end(){ return directory_iterator(); } }; so that that a range-based for loop can be used: for (auto itr : directory(".")) { cout << itr.path() << endl; } The above works as expected on GCC 4.6 and VC++ 11 beta. Is that the best way for filesystem directory iteration to support range-based for? Provide a class directory_tree for recursive iteration? --Beman

4 13

1.50 release calendar
by Vicente J. Botet Escriba 23 Apr '12

23 Apr '12

Hi, I would like to know the 1.50 release calendar so that I can plan with Anthony Williams the merge to release of Boost.Thread of version 3. Which is the last day to merge to release a big change? Thanks for all, Vicente

3 3

[range] Question about adapted range safety given C++11 auto
by Beman Dawes 23 Apr '12

23 Apr '12

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html claims: "Boost's range library focuses on defining a set of Range concepts that allow Containers to be Ranges. Because Containers are heavy-weight, this forces Boost to use references for all of their uses of Ranges, including Ranges that are captured by Range Adapters. This worked fine in C++98, where users couldn't name the types of the Range Adapters in order to declare local variables, but with C++11's auto keyword, users can now save adapted ranges. Since Boost's adapted ranges capture references to their arguments, which can be temporaries, this is no longer a safe design." Is this claim correct? If so, what's the real-world impact? --Beman

4 3

[context] [windows] Intel C++ and GCC Support?
by Joshua Boyce 22 Apr '12

22 Apr '12

I notice that Boost.Context only seems to support MSVC under Windows, and attempts to compile it under GCC or Intel C++ will fail because it's not correctly assembling fcontext_i386_ms_pe_masm/fcontext_x86_64_ms_pe_masm. e.g. Under Intel I get: intel-win.compile.asm > C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj '-c' is not recognized as an internal or external command, operable program or batch file. > -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DWINVER=_WIN32_WINNT_VISTA > -D_WIN32_WINNT=_WIN32_WINNT_VISTA -DBOOST_ALL_NO_LIB=1 > -DWINVER=_WIN32_WINNT_VISTA -D_WIN32_WINNT=_WIN32_WINNT_VISTA /Zi /Zd /W3 > -Fo > "C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj" > "C:\Users\Josh\Documents\code\boost-trunk\libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm" > ...failed intel-win.compile.asm > C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj... Whilst under GCC (via MinGW-w64) I get: Jamfile</C:/Users/Josh/Documents/code/boost-trunk/libs/context/build>.masm64 C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o 'ml64' is not recognized as an internal or external command, operable program or batch file. ml64 /c /Fo"C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o" "C:\Users\Josh\Documents\code\boost-trunk\libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm" ...failed Jamfile</C:/Users/Josh/Documents/code/boost-trunk/libs/context/build>.masm64 C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o... This occurs for both 64-bit and 32-bit compilation. Is this a known issue with a planned fix? Or is MSVC the only compiler supported under Windows? (I know it's a pain because GCC afaik uses a different assembly syntax... Not sure about Intel.) As an aside, Boost.Context does not yet seem to have an entry in Trac. Thanks.

3 9

[Proto] Errors due to narrowing conversions in matches.hpp
by Michel Morin 22 Apr '12

22 Apr '12

Some tests of Boost.Phoenix fail on clang trunk in a C++11 mode due to narrowing conversions of non-type template arguments, which are prohibited in C++11. Specifically, the narrowing conversions occur at Line 354 and 363 in boost/proto/matches.hpp. They can be simply resolved using `static_cast<bool>(...)`. Regards, Michel

2 3

[thread] Do we need thread_group now?
by Vicente J. Botet Escriba 22 Apr '12

22 Apr '12

Hi, now that we have Boost.Container and Boost.Thread (trunk) uses Boost.Move, boost::thread_group has less sense. I was thinking on replacing it by some generic algorithms as join_all, interrupt_all that work with generic containers so that the user can use the best containers adapted to her own needs. typedef boost::container::vector<boost::thread> thread_vector; { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } join_all(threads); } { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } interrupt_all(threads); } Could boost::thread_group be deprecated once these generic algorithm are released? Or, is there something really useful on the thread_group class that needs to be preserved or even improved? Best, Vicente

7 13

[iterator] iterator-category logic
by Jeffrey Lee Hellrung, Jr. 21 Apr '12

21 Apr '12

I'd like to ask Boosters' opinions on this. boost::iterator_facade determines the iterator_category via the logic outlined in http://www.boost.org/doc/libs/1_49_0/libs/iterator/doc/iterator_facade.html… In particular, if (a) CategoryOrTraversal is a Boost traversal tag; and (b) Reference is not a "real" C++ reference (i.e., a proxy reference); then iterator_category is at best convertible to std::input_iterator_tag. This ends up being surprising to users who use boost::iterator_adaptor (note that, by default, iterator_adaptor passes the Boost traversal tag of the adapted iterator down to iterator_facade) to adapt, say, a pointer, define their adapted iterator to return a proxy reference, and find out that their standard library functions don't recognize their adapted iterator as a random access iterator. The usual workaround tends to be to just override the iterator_facade logic yourself to use a more refined iterator_category and hope your standard library functions don't barf. For better or for worse, the present logic in iterator_facade is strictly (more or less) correct given the C++03 iterator requirements, but I just looked up the N3290 draft of C++11 and it appears that any requirements that *i return a real reference have been dropped, thus allowing for proxy references in all iterator categories. (a) Am I interpreting the C++11 iterator requirements correctly? (b) If so, should iterator_facade's iterator-category logic be reworked to account for the new requirements? (c) If so, how should it be determined when to use the C++03 requirements and when to use the C++11 requirements? Thanks, - Jeff

3 3

[review schedule] Broken link to Coroutine documentation
by Mateusz Loskot 21 Apr '12

21 Apr '12

Hi, There is Coroutine library by Oliver Kowalke proposed for review. The link to Documentation points to...the review schedule at http://www.boost.org/community/review_schedule.html Is there any chance to have it fixed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost.Variant swap performance
by David Sankel 21 Apr '12

21 Apr '12

It seems as though Boost.Variant doesn't take advantage of pointer swaps when it comes to use of recursive variants. In the attached file I declare a simple int list type and include two implementations of a function that adds an int to the front of a list. The first implementation, I would expect to be O(N) on the size of the list and the second implementation to be O(1) on the size of the list. Unfortunately, the output I get is: unoptimized ilPushFront: 129 unoptimized ilPushFront w/ larger list: 363 optimized ilPushFront: 211 optimized ilPushFront w/ larger list: 653 Any ideas why this might be happening? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

2 3