- Boost - lists.boost.org

Is the bellman_ford_shortest_paths function missing an overload with the root vertex?
by Geoff Hilton 28 Nov '08

28 Nov '08

Quick question, was the fact that there is no bellman_ford_shortest_paths overload in the BGL that allows for the specification of the root vertex intentional? I'm using MSVC9 and tried using the named parameters overload but it won't compile. Ditto for dijkstra_shortest_paths and dag_shortest_paths actually. Here's what I have that won't compile with (twice) the error message: error C2248: 'Weight<long long>::Weight': cannot access private member declared in class 'Weight<long long>' c:\program files\boost\boost_1_37_0\boost\graph\bellman_ford_shortest_paths.hpp 155 class ShortestPathBellmanFordForward: public ShortestPathFunction { public: virtual ~ShortestPathBellmanFordForward(){} virtual AlgoResult operator()( const vertex_descriptor startingVertex, const WeightComparer<long long>& comparer, Graph& graph) const { const size_t numVertices = boost::num_vertices(graph); AlgoResult retval; retval.first = PredecessorMap(numVertices); retval.second = DistanceMap(numVertices); vertex_index_prop_t vindex = get(boost::vertex_index, graph); boost::bellman_ford_shortest_paths(graph, numVertices, weight_map(boost::get(&EdgeProp::weights, graph)). predecessor_map(boost::make_iterator_property_map( retval.first.begin(), vindex)). distance_map(boost::make_iterator_property_map( retval.second.begin(), vindex)). root_vertex(startingVertex). distance_combine(WeightCombiner<long long>()). distance_compare(comparer)); return retval; } }; Thanks, Geoff

1 2

Mingw testing
by Vladimir Prus 28 Nov '08

28 Nov '08

There seem to be no trunk tests running for gcc on windows (mingw). Did I miss something? Assuming I'm not, it would be really great to see mingw tested, as this is becoming a commonly used thing these days. Is anybody willing to do mingw testing? Thanks, Volodya

2 1

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir.Batov＠wrsa.com.au 28 Nov '08

28 Nov '08

*** What is your evaluation of the design? Unfortunately I have serious reservations about the interface. Like, 1. "uuids" namespace seems unnecessary and burdensome. The generator classes can be introduced inside boost::uuid. 2. handling "char const*", "wchar_t const*", std::basic_string-based arguments should be templated/generalized. 3. Using a separate "generator" class to create a new UUID seems unorthodox as I feel the standard way of calling a constructor would be more inline with the standard C++ practices. Like boost::uuids::basic_uuid_generator<boost::mt19937> gen2; boost::uuid id(gen2); instead of boost::uuids::basic_uuid_generator<boost::mt19937> gen2; boost::uuids::uuid u2 = gen2(); That way boost::uuid id; // Works as Linux uuid_generate(); boost::uuid id(gen2); // Works as Linux uuid_generate_random(); 4. The default uuid() creating a "null" UUID is too subtle, wide open for misinterpretation and in fact counter-intuitive. For example, my (and many others that I know) interpretation of that constructor is like Linux uuid_generate() was called behind it. The creation of an invalid/null UUID needs to be explicitly stated with something like boost::uuid id = boost::uuid::null(); boost::uuid id = boost::uuid::invalid(); then "is_null()" method would be somewhat expected/justified. 5. I'd expect to be able to use "if (!uuid) then..." rather than "if (uuid.is_null()) then...". 6. to_wstring() does not seem to belong to the class. I understand it is conveniend but I fdo not feel that is core UUID functionality and, therefore, should (and can) be handled by other means. *** What is your evaluation of the implementation? I am OK with the implementation with a few comments. 1. Unfortunately, it does not seem to provide time-based construction. I read explanations why not but the usefulness of such a simple concept very much depends on its completeness. 2. I was surprised to see NULL used and postincrements. 3. A lot of raw numbers around the code. 4. I am very suspicious of using std::streams as from what I know they are not exactly fast. *** What is your evaluation of the documentation? Well, in all honesty I do not feel like the uuid.html file supplied with the package (uuid_v13.zip) can be considered as adequate documentation. Explanations seem scetchy. Links seem broken (like "see operators.hpp" points to a non-existing "operators.htm"). *** What is your evaluation of the potential usefulness of the library? I certainly think such a facility needed. *** Did you try to use the library? With what compiler? Did you have any problems? Tried with MSVC8 with results similar to already reported. Iseems like at least some of the warnings (like "warning C4244: '=' : conversion from 'int' to 'char', possible loss of data") need to be addressed. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a couple of hours with it. *** Are you knowledgeable about the problem domain? Well, I consider myself a "knowledgeable user". I certainly will not be able to claim to be intimately familiar with the generation algorithms. *** Conclusion: The UUID concept is most certainly very useful and such a facility is an essential gadget in everyone's toolbox. However, there are many implementations around (OpenLDAP, Linux, Windows to name a few). For boost::uuid to be accepted and used instead other alternatives it needs to be as complete as its competitors and to stand out -- to be superior in interface, convenience or something. In a couple of hours I spent with boost::uuid I unfortunately did not manage to get that impression. Therefore, I am reluctantly voting against its acceptance in its present form. Thanks, Vladimir.

2 1

Making a new contribution - weak_hash_map
by Yoni Lavi 28 Nov '08

28 Nov '08

I'd like to contribute a C++ class template that implements something similar to java.util.WeakHashMap; it uses boost::intrusive::iunordered_set and boost::pool::fast_pool_allocator internally. This is the first time I'm looking to get into boost development in general. I'm not aware of any trivial way to implement this using existing components of the boost library, but I could have easily overlooked something so let me know if I am mistaken. I'd also like to know if there's any interest in such a contribution at all - anyone else thinks this class could be useful? Briefly, given a key space and value space, the class provides a way to lookup (and optionally create) values by a unique key, in a thread safe manner. A smart pointer to the entry (<key, value> pair) is returned from the lookup/create function. The tricky part is to make such entries automatically destroy themselves when no longer in use. The set itself cannot store a shared_ptr or the use count would never reach zero; it has to rely on weak_ptr and try to lock() it. There is also a race condition that needs to be taken care of (lock() may fail if refcount just dropped to zero in another thread). Lastly, it also has to handle the case where the weak_hash_map is destroyed but its entries persist, and again this needs to be properly synchronized. The implementation makes use of insert_check and insert_commit to implement a "create-or-get" function as well. I have also written an intrusive smart pointer type and that made it possible to use raw pointers instead of the weak_ptr's in the implementation. It's not that this stuff is rocket science as much as it involves lots of boilerplate code (e.g. making an entry hasher out of a key hasher, key/entry and entry/entry equality from key/key equality, resizing the hash table automatically, synchronization, allocation... the class I've written takes care of a lot of the ugly details. If anyone's interested, please fill me in on the process of making such a contribution? Thanks.

1 0

[utility/swap] boost::swap release update
by Niels Dekker - mail address until 2010-10-10 27 Nov '08

27 Nov '08

As far as I'm concerned, the boost::swap utility is now ready to be used within other Boost libraries, at the release branch. Joseph Gauterin has merged the utility from the trunk to the release branch two weeks ago, and its release regression page is now entirely green: http://www.boost.org/development/tests/release/developer/utility-swap_.html Just to remind you: The boost::swap utility makes it easier to swap two objects of the same type in a generic and efficient way, because it tries to find the most appropriate swap overload by argument-dependent lookup (ADL), whenever applicable. Thereby it works around the issues some compilers appear to have regarding ADL. The boost::swap utility also supports swapping built-in arrays. The utility was developed with help from David Abrahams and Steven Watanabe. See also: http://svn.boost.org/svn/boost/branches/release/libs/utility/swap.html http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp BTW, I've just added a boost::swap overload to the release version of Fernando Cacciola's value_initialized (utility/value_init.hpp), which is actually implemented by calling the boost::swap utility: https://svn.boost.org/trac/boost/changeset/49967 According to the following ticket: https://svn.boost.org/trac/boost/ticket/2243 Unswappably yours, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Boost.Future & review of C++0x accepted libraries implementations
by vicente.botet 27 Nov '08

27 Nov '08

Hi, The Anthony Future + Packaged task proposals have been adopted by the C++ Standard. Is there a sense to review both Futures libraries together? Can we accept the Braddock library if it not conforms to the standard? As the interface and the design rationale for libraries already adopted by the C++ Standard such Chrono seem to be out of the scope of a review, which is the contents expected for such libraries to be adopted? Do we need a different review process? BTW, the threadpool library uses Braddock Future library. Thanks, Vicente

5 14

[regex] Matching space - help needed
by Roman Yakovenko 27 Nov '08

27 Nov '08

Hello. I have some strange problem and have no idea how to solve it or where to look father. I have two regular expressions: (\s) ( ) //<== this one contains single space between brackets. I use match algorithm and as a argument I pass string with single space. In the product, the first regular expression (\s) doesn't work, while the second does. I created stand-alone tester - both expressions work as expected. Using proc file system, I compared environment variables, specifically LANG is set to "en_US.UTF-8". Both executables load same Boost.Regex shared library. I am using GCC 3.3.3, on RedHat. The boost version is 1.34. Searching the web didn't help too. Any help is appreciated. Thank you. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

3 8

boost::signals2 performance
by Hansi 27 Nov '08

27 Nov '08

I have made now a lot of tests with the new signals2 library. The only thing because I don't want to use it now, is because it is really slow... I have made now performance tests with the dummy_mutex which is included. I have found out the about 50% of the time that it takes to call 10000000 is inside in slot_call_iterator---->lock_next_callable function. Here the follwing lines takes the 50% of the executing time: lock_type lock(**iter); tracked_ptrs = (*iter)->nolock_grab_tracked_objects(); I hope that one has an idea how it can be made it faster... Best regards Hansjörg

2 2

[interthreads] Library under development
by vicente.botet 26 Nov '08

26 Nov '08

Hi, If the Boost community is interested in the InterThreads library I could work on to complete for submission. InterThreads ------------------- :Author: Vicente J. Botet Escribá :Download: Boost Vault: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=intert…> Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads Html doc included only on the Vault :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Best regards, Vicente

1 0

[preprocessor] half-open or closed ranges?
by Eric Niebler 26 Nov '08

26 Nov '08

I've noticed an inconsistency with how the preprocessor library handles integer ranges. Consider this: #define M0(Z,N,DATA) N BOOST_PP_REPEAT_FROM_TO(1,3,M0,~) This treats the range 1,3 as half-open. It generates the sequence "1 2". But consider this: #define BOOST_PP_LOCAL_MACRO(N) N #define BOOST_PP_LOCAL_LIMITS (1,3) #include BOOST_PP_LOCAL_ITERATE() This treats the range 1,3 as closed. It generates the sequence "1 2 3". Why the difference? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1