- Boost - lists.boost.org

[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

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 20 Apr '12

20 Apr '12

> >> I believe that a portable implementation of the proposed std::decimal > >> (eg Decimal Types for C++ would be useful. > Of course this is definitely something Boost needs in its tool chest. > But to 'sell' it to Boost, I think it is important to relate to commercial offerings and > previous proposals to WG21 C++ Standards. > > So say how and why you have done it differently? > > Paul I do not intend to create an implementation - I am simply wiring up the existing DecNumber, Intel Decimal Float implementations (both IEEE compliant) to the std::decimal interface. I believe the associated licences are compatible with boost being able to distribute this, but that would be the first thing to be checked. I have no idea how this differs from any other offering (apart from saying I hope it gives identical results to gcc's standard decimal) apart from pointing out I haven't found any C++ wrappers for the decimal floats that I would use 'off the shelf' in the same way I use boost libraries. I'm working on a somewhat blind assumption that if gcc is implementing this interface, it is probably the closest thing to what will eventually end up in the standard. If there are other implementations that do roughly the same thing, I'd be really interested to take a look, as I've no desire to reinvent the wheel!

2 1

Release branch merge
by Dave Abrahams 20 Apr '12

20 Apr '12

Since we're within the 7-week window, I'm asking permission to patch the release branch per the enclosed: -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[coroutine][context] coroutine_specific_ptr proposal
by Taylor Goodhart 19 Apr '12

19 Apr '12

With the context/coroutine library making great progress, in my mind it is only natural to wonder whether something analogous to thread local storage could be implemented for coroutines. I would propose using the existing thread_specific_ptr as a starting point. As for an initial design proposal, it seems to me like one could have a single static atomic integer in the constructor of coroutine_specific_ptr that is incremented for each new instance. This will allow each instance to know their index, and to also know the total number of pointers. Then when a new coroutine is created, a block of pointers of this size would be created and placed before stack memory. If a coroutine were to try to dereference a coroutine_specific_ptr then the index into this block would be looked up and if NULL, create a new instance on the heap. If not NULL, it would simply return the previously created value. Comments and feedback would be appreciated. If this seems like something people might use I'd be willing to take a crack at implementing it, provided Oliver's blessing. -Taylor Goodhart

1 0