June 2011 - Boost - lists.boost.org

[1.47.0][MPI] Showstopper
by KTC 18 Jun '11

18 Jun '11

Both the release & trunk version of MPI no longer compile on Microsoft Windows with Microsoft Compute Cluster Pack. With 1.46.1: ===============MPI Auto-configuration=============== Found Microsoft Compute Cluster Pack: C:\Program Files\Microsoft Compute Cluster Pack MPI build features: <include>/C:/Program Files/Microsoft Compute Cluster Pack/Include <address-model>64:<library-path>/C:/Program Files/Microsoft Compute Cluster Pack/Lib/amd64 <library-path>/C:/Program Files/Microsoft Compute Cluster Pack/Lib/i386 <find-static-library>msmpi <toolset>msvc:<define>_SECURE_SCL=0 MPI launcher: "C:\Program Files\Microsoft Compute Cluster Pack\Bin\mpiexec.exe" -n ==================================================== .... Currently: D:/src/boost-release-test/boost/tools/build/v2/tools\mpi.jam:249: in mpi.init rule path.make unknown in module mpi. D:/src/boost-release-test/boost/tools/build/v2/build\toolset.jam:38: in toolset.using D:/src/boost-release-test/boost/tools/build/v2/build\project.jam:888: in using C:\Users\KTC\user-config.jam:5: in modules.load D:/src/boost-release-test/boost/tools/build/v2\build-system.jam:257: in load-config D:/src/boost-release-test/boost/tools/build/v2\build-system.jam:399: in load-configuration-files D:/src/boost-release-test/boost/tools/build/v2\build-system.jam:555: in load D:\src\boost-release-test\boost\tools\build\v2/kernel\modules.jam:283: in import D:\src\boost-release-test\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build D:\src\boost-release-test\boost\boost-build.jam:17: in module scope KTC Created ticket on Trac: <https://svn.boost.org/trac/boost/ticket/5618>

3 5

[unordered] equal_range is O(bucket_count()), not O(size())
by Brad Higgins 18 Jun '11

18 Jun '11

TR1 specifies that unordered_multimap::equal_range(k) worst case complexity is O(size()). However, in practice, I find that the worst case performance of boost unordred_multimap's equal_range is O(bucket_count()). Is this known? I believe the issue is with the second iterator returned by equal_range(). Specifically, if there are sparse elements in the hash table, the implementation may have to traverse many buckets to find the second iterator. I have a test that demonstrates the issue. The test makes 2 runs over an unordered_multimap, each using the same number of elements. In the second run, it calls rehash() in order to grow the bucket count by a large amount. Notice that the first run is quite fast, while the second run takes more than 10 seconds. Here are the results from my test: ---- $ ./main rehash(0) insert 1000 elements built hash, with 1543 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:00.001366 rehash(5000000) insert 1000 elements built hash, with 6291469 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:10.818002 ---- Here is my code for the test: ---- #include <iostream> #include <boost/unordered_map.hpp> #include <boost/date_time/posix_time/posix_time.hpp> typedef boost::unordered_multimap<size_t, size_t> hash_int_type; typedef hash_int_type::iterator hash_int_itr; typedef std::pair<size_t, size_t> hash_insert_type; void run_test(const size_t data_size, const size_t rehash_size) { hash_int_type hash; std::cout << "rehash(" << rehash_size << ")\n"; hash.rehash(rehash_size); std::cout << "insert " << data_size << " elements\n"; for (size_t i=0; i<data_size; i++) { hash_insert_type ins(i,i); hash.insert(ins); } std::cout << "built hash, with " << hash.bucket_count() << " buckets and " << hash.size() << " elements. Now, get some ranges\n"; boost::posix_time::ptime start(boost::posix_time::microsec_clock::local_time()); for (size_t i=data_size-1; i!=0; i--) { typedef std::pair<hash_int_itr, hash_int_itr> ret_pair; ret_pair ret = hash.equal_range(i); if (ret.first != ret.second) { hash.quick_erase(ret.first); } } boost::posix_time::ptime stop(boost::posix_time::microsec_clock::local_time()); boost::posix_time::time_duration diff_time(stop-start); std::cout << "time to obtain " << data_size << " elements: " << diff_time << "\n"; } int main(int argc, char* argv[]) { run_test(1000,0); run_test(1000,5000000); return 0; } ----- Thanks, Brad

2 3

[type_traits] Reverting support for clang 3.0 intrinsics
by Daniel James 18 Jun '11

18 Jun '11

Hi, As discussed here: http://lists.boost.org/Archives/boost/2011/06/182574.php Changeset #72423 is incorrect, since it's based on the clang version number which is not a reliable indicator of feature support: https://svn.boost.org/trac/boost/changeset/72423 So I think it should be reverted. Daniel

1 0

[array] assignment and constructor coherency
by Vicente Botet 18 Jun '11

18 Jun '11

Hi, Boost.Array defines the following assignment template (* typename U *) array(* T,N *)& operator=(const array(* U, N *)&); as std::copy(rhs.begin(),rhs.end(), begin()) Even if the standard doesn't provides this conversion assignment, for coherency purposes, shouldn't we have also the copy constructor template (* typename U *) explicit array(* T,N *)(const array(* U, N *)&); Best, Vicente P.S. Please replace (* and *) by angle brackets. -- View this message in context: http://boost.2283326.n4.nabble.com/array-assignment-and-constructor-coheren… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

C++ AMP
by Neal Becker 17 Jun '11

17 Jun '11

Interesting: http://techreport.com/discussions.x/21134

5 7

Re: [boost] [1.47.0] Release branch now closed
by Rene Rivera 17 Jun '11

17 Jun '11

Sorry this should have gone to the list... On 6/17/2011 10:05 AM, Jim Bell wrote: > > > On 6/17/2011 9:37 AM, Rene Rivera wrote: >> On 6/17/2011 8:58 AM, Jim Bell wrote: >>> >>> On 1:59 PM, Rene Rivera wrote: >>>> The release branch is now close, i.e. the release is frozen, for >>>> further changes. This means that commits to the release branch will >>>> fail without explicit authorization. >>> >>> >>> The Boost.Thread patch for Mingw-64 is crucial for that important >>> platform.<https://svn.boost.org/trac/boost/ticket/4849> >>> >>> It has been patched into the trunk for three months without complaint, >>> and just needs to be shepherded to the release branch. >>> >>> Could you please do this? >> >> I'm not sure what you are asking. > > > I'd like a maintainer or release manager to merge the patched trunk > files into the release branch. > boost/detail/interlocked.hpp > libs/thread/src/win32/thread.cpp > libs/thread/src/win32/tss_pe.cpp > > > See<https://svn.boost.org/trac/boost/changeset/70383> Since I don't know enough to judge the code itself at this instant.. Could others please comment on the above? Is the thread maintainer around? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 11

[interval] implicit versus explicit conversions
by Vicente Botet 17 Jun '11

17 Jun '11

Hi, The current interface of boost::interval defines the following implicit conversions interval(T const &v); template(* class T1 *) interval(T1 const &v); template(* class T1, class Policies1 *) interval(interval(* T1, Policies1 *) const &r); I was wondering if some/all of these shouldn't be declared explicit. Any thoughts? Best, Vicente P.S. Please replace (* and *) by angle brackets. -- View this message in context: http://boost.2283326.n4.nabble.com/interval-implicit-versus-explicit-conver… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

operator+ and void*: differences between g++ and msvc
by Frédéric Bron 17 Jun '11

17 Jun '11

Hi, I am trying to perform an exhaustive testing of the operator traits. I came to the following issue: this code yields an error with msvc and only a warning with g++: int lhs=0; void* rhs=0; lhs + rhs; * msvc (Visual C++ 2010 Express): error C2036: 'void *' : unknown size warning C4552: '+' : operator has no effect; expected operator with side-effect * g++ (4.5.3): warning: pointer of type 'void *' used in arithmetic The standard says: "Either both operands shall have arithmetic or enumeration type, or one operand shall be a pointer to a completely defined object type and the other shall have integral or enumeration type." So it seems to me that an error should be issued by g++. What is your understanding of the standard? If this is so, do you suggest me to file a bug to g++? Frédéric

3 4

Re: [boost] [Boost-users] [Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 17 Jun '11

17 Jun '11

Hi, Attempt #2. Please see attached diffs and test case. Cheers, Vitaly

1 0

[review] Heaps
by Andrew Sutton 17 Jun '11

17 Jun '11

All, Just a reminder that the Tim Blechmann's Heap library is being reviewed. The more reviewers we have, the higher quality libraries we get :) The review is scheduled to end today, but I'd like to extend it through the Monday (June 12) because a) I announced it 2 days late and b) I'd like to solicit more feedback on the library. Andrew

2 3