- Boost - lists.boost.org

[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 22 Apr '12

22 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 21 Apr '12

21 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

[shared_ptr] [intel] Compile Errors with '#include <atomic>'
by Joshua Boyce 20 Apr '12

20 Apr '12

Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have). The problem is simple to repro: #include <atomic> #include <boost/shared_ptr> int main() { } The problem has been reported previously, but even in the latest version of the compiler (created and released well after the bug report) the problem seems to remain: http://software.intel.com/en-us/forums/showpost.php?p=160114 Here is a patch which I have used locally to successfully work around the problem, but I get the feeling that there is a better solution I'm overlooking... http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-shared_ptr-intel-fix-… Has anyone else run into this problem who has come up with a better solution? Alternatively, if this is as good as it's going to get (maybe using a BOOST_WORKAROUND would be better so it can be disabled when/if the issue is fixed), would anybody be able to apply this to trunk? Thanks.

1 1