- Boost - lists.boost.org

[BGL] All-pair problem on a subset of vertices
by Cosimo Calabrese 18 May '10

18 May '10

Hi to all, if we want to find the shortest distance between *every* pair of vertices in a graph, we can use the Jonson's or Floyd-Warshall's algorithm, obtaining a NxN matrix of distances, where N is the total number of the graph's vertices. The problem is: how can I do if I don't need the distance of *every* pair of graph's vertices, but I'm interested in only a subset of vertices? In other words, I would to obtain a MxM matrix, where M<N. In every case, I'm not interested in path from the pairs, but only in the distance. My solution is to execute M times the Dijkstra algorithm from every vertex of the subset, and to abort every exploration when I've founded the Mth vertex of the subset. Are there something of more efficent? My graphs contain approximately 12 millions of vertices, but I'm interested in a subset of 10.000 vertices. Thanks in advance, Cosimo Calabrese.

2 2

[Boost][Thread] Non-copyable boost::thread
by Belcourt, Kenneth 18 May '10

18 May '10

Hi, The Boost.Thread documentation points out that boost::thread is non- copyable but then goes on to provide rational for why it should be possible to return by value from make_thread_return_local(). Intel-11.1 on Darwin is a recent compiler that will not compile this code. [ from libs/thread/test/test_thread_return_local.cpp ] boost::thread make_thread_return_local(boost::thread::id* the_id) { boost::thread t(do_nothing,the_id); return t; } The same error message is generated in both debug and release builds on Darwin (though strangely it doesn't appear to be an error with Intel 11.1 on Linux). "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX - DBOOST_THREAD_USE_LIB=1 -I".." -c -o "/Volumes/Scratch/kbelco/boost/ results/boost/bin.v2/libs/thread/test/ test_thread_return_local_lib.test/intel-darwin-11.1/debug/threading- multi/test_thread_return_local.o" "../libs/thread/test/ test_thread_return_local.cpp" ../libs/thread/test/test_thread_return_local.cpp(16): error #373: "boost::thread::thread(boost::thread &)" (declared at line 111 of "../ boost/thread/detail/thread.hpp") is inaccessible return t; ^ Any ideas how to work around this failure? Thanks. -- Noel

3 10

feenablexcept doesn't exist on Darwin
by Christopher Jefferson 17 May '10

17 May '10

boost::test recently started using feenableexcept, which is not supported on Darwin / Apple. See https://svn.boost.org/trac/boost/ticket/4222 for patch. This bug is particularly annoying as it is causing many failures, as the problem is in the testing code.

3 2

Visual Studio 2010 Template Limits
by Daniel Larimer 17 May '10

17 May '10

I have written some code that makes heavy use of templates and which compiles just fine using g++; however, when I recently tried to compile the code in VC++ 2010 I got a fatal error C1063: compiler limit : compiler stack overflow. It directs me to this template... See reference to class template instantiation 'delegate<T1>::overloads<1,S0,ptr0>' being compiled The general code structure is... template<T1> class delegate { template<typename RTN, typename TY PARAM_TNS, RTN (TY::*m_ptr)(PARAM_PTS)> class method_impl<RTN (TY::*)(PARAM_PTS), m_ptr> : public method; // specialized for n with BOOST_PP_ITERATE (blows up even if n == 1) template<int, typename S0, S0 ptr0> class overloads<n, PARAM_TYPES> : public method_impl<S0,ptr0>, public method_impl<S1,ptr1> ... { }; }; I don¹t even need to instantiate delegate<ForSomeType>, simply including the header causes it to blow up. Considering the extent to which boost uses and ³abuses² templates I thought I would ask whether anyone here knows of some limitation or constructs which I must avoid? Is there some way to increase the ³stack² for VC++¹s CL program? Dan

2 1

[contract] Boost spoiled function declarations
by Lorenzo Caminiti 17 May '10

17 May '10

Hello all, I have been looking into other Boost libraries besides my Boost.Contract that spoil function declarations using macros. I found that both Boost.Parameter (approved) and Boost.Interface (under construction) significantly spoil function declarations. Boost.ConceptCheck also spoils function declarations but its REQUIRE macro has a very simple syntax so I am not comparing it with Boost.Contract. See examples below: Is Boost.Contract parenthesized syntax really more complex than Boost.Parameter or Boost.Interface? Boost.Contract (under construction) BOOST_CONTRACT_FUNCTION( (inline) (double) (sqrt)( (double)(x) ) (precondition)( (x >= 0.0) ) (postcondition)(result)( (result == x * x) ) ({ ... }) ) Note that the usual C++ syntax would have been essentially the same as above but without the extra parenthesis `()`. Boost.Parameter (approved) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { ... } Boost.Interface (under construction) BOOST_INTERFACE_BEGIN(IShape) BOOST_INTERFACE_CONST_FUNCTION0(GetX, int) BOOST_INTERFACE_CONST_FUNCTION0(GetY, int) BOOST_INTERFACE_CONST_FUNCTION0(GetArea, double) BOOST_INTERFACE_FUNCTION2(SetXY, void, (int, x), (int, y)) BOOST_INTERFACE_FUNCTION2(OffSetXY, void, (int, x), (int, y)) BOOST_INTERFACE_CONST_FUNCTION0(GetName, const char*) BOOST_INTERFACE_END(IShape) 1) While I recognize the ugliness of the Boost.Contract parenthesized syntax, I think it is actually simpler than Boost.Parameter or Boost.Interface syntax because it is essentially "the usual C++ syntax with all the tokens wrapped within parenthesis". 2) It is possible to provide Boost.Contract with macros similar to ones of Boost.Parameter. However, Boost.Parameter only supports const/non-const members while Boost.Contract also supports volatile, virtual, inline/extern, auto/register, function templates, and everything else. If specific macros were to be provided for all these different function traits plus their combinations, Boost.Contract will have a *lot* of macros. For example, just to support qv-qualifiers, Boost.Contract should provide CONTRACT_FUNCTION(), CONTRACT_FUNCTION_CONST(), CONTRACT_FUNCTION_VOLATILE(), CONTRACT_FUNCTION_CONST_VOLATILE(). Plus all these qv-qualifier macros will have to be combined with inline, virtual, etc -- the number of macros grows combinatorially in the number of function traits! Instead the parenthesized syntax allows you to specify or omit the function traits directly in the function declarations so all the traits can be combined as usual in C++ and with the use of one single macro CONTRACT_FUNCTION(). Regards, -- Lorenzo

1 0

[MSM] move to trunk
by Michael Caisse 17 May '10

17 May '10

Hello Christophe - I hope you had an uneventful trip home after boostcon. I am starting to use MSM 2.1 this week in a project. I have gotten the tarball from the sandbox; however, it would be convenient to use the library from the svn trunk so I can monitor changes before release. Do you have a time line for checking in the library to trunk? Thank you for your time. Take care - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Namespace for a Boost Hashing Library
by Scott McMurray 17 May '10

17 May '10

I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community. The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256). Some possibilities: - boost::hashes Following the usual boost method of a plural namespace when a class exists. - boost::hash_algo or boost::hash_algorithms Following the string_algo precedent. - boost::hashing or boost::hashing_algorithms Using a gerund for a change. - boost::digests or boost::message_digest Using the name of the result of a hash, rather than the process. - boost::fingerprint (or boost::dactylogram) An alternative name for the result of a hash. - Something else better that you come up with Some complaints raised about those options: - boost::hashes or boost::hashing or boost::digests It's hard to remember when namespaces aren't singular as usual (especially for the first two, when the library doesn't provide anything named "hash"). - boost::hash_algo It would be better to not use an abbrev. - boost::hash_algorithms or boost::hashing_algorithms or boost::message_digest Shorter namespaces are generally preferred, where possible. - boost::fingerprint (or boost::dactylogram) Implies a particular use and certain minimum length of result. Which one(s) do you prefer or dislike? Thanks, ~ Scott McMurray

10 15

www.boost.org: update link to boost Jam 3.1.18 instead of 3.1.17?
by Wolfgang Fertsak 17 May '10

17 May '10

Hi, I just noticed that the link to Boost Jam in the download-section in www.boost.org still points to Version 3.1.17, although 3.1.18 is available since march... Best regards, Wolfgang

1 0

[Boost.Thread] Patch for Intel on Darwin
by Belcourt, Kenneth 17 May '10

17 May '10

Hi, The thread library is failing to build with Intel on Darwin with this error. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/ Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel- darwin-11.1/debug/threading-multi/pthread/thread.o" "../libs/thread/ src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ The fix is to test for Apple and Intel before the GNU test. Index: libs/thread/src/pthread/thread.cpp =================================================================== --- libs/thread/src/pthread/thread.cpp (revision 61969) +++ libs/thread/src/pthread/thread.cpp (working copy) @@ -381,6 +381,10 @@ { #if defined(PTW32_VERSION) || defined(__hpux) return pthread_num_processors_np(); +#elif defined(__APPLE__) && defined (__INTEL_COMPILER) + int count; + size_t size=sizeof(count); + return sysctlbyname("hw.ncpu",&count,&size,NULL,0)?0:count; #elif defined(_GNU_SOURCE) return get_nprocs(); #elif defined(__APPLE__) || defined(__FreeBSD__) This has been tested on Darwin and Linux. Okay to commit? -- Noel

2 1

[website] [1.43.0] broken link
by Mostafa 17 May '10

17 May '10

FYI, The following webpage: http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference.ht… has a broken link at the "Overview" section, ie, http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/ov… -Mostafa

3 3