- Boost - lists.boost.org

Is Boost Broken?
by Robert Ramey 08 Oct '12

08 Oct '12

At Boost Con 2010 I made a presentation in which I suggested changes in boost to permit it to continue to prosper. This presentation was titled: "Is Boost Broken?" Here's the video link - but it doesn't seem to work any more http://blip.tv/boostcon/robert-ramey-is-boost-broken-4166775 And the slides http://www.rrsd.com/software_development/boost/BoostCon2010/boost_con_2010.… And a thread of the discussion in the aftermath. http://boost.2283326.n4.nabble.com/quot-Is-Boost-Broken-quot-post-script-td… The response was encouraging but sorry to say that note much concrete has come of it ... until now. I've implemented most of these ideas as a website - Boost Library Incubator - www.blincubator.com which is intended to help library authors and provide a place where libraries can be developed prior to the review process. This touches on just about all of Boost workflow and initiatives in one way or another. This includes Modularization, Documentation standards and preperation, Testing and Test Reporting, Deployment. Probably the main underlying ideas here are: a) Decoupling and Modularization of libraries in general and boost in particular. b) Workflow to improve code quality b) leverage on "free" tools, technologies, and facilities to get most bang for the buck. As a "teaser", I've included a new library "safe numerics" which addresses a long running sore in the C language. It's a serious proposal for a library, but my main interest is to have a prototype to develope the next concept. I'm very much tempted to comment on the current state of development of web technologies - the that would take me waaaay of topic and we'll leavel that for another time. Looking forward to feedback from boost enthusiasts. Robert Ramey

3 3

[type_traits] common_type and SFINAE
by Lorenzo Caminiti 08 Oct '12

08 Oct '12

Hello all, common_type<T, U>::type is defined in a way that gives a hard compiler error if T and U do not have a common type (this is also how common_type is implemented in C++11). An alternative design (I'm not sure if implementable) would have been to not define the type member in case T and U have no common type. This way I could use SFINAE to detect if common_type<T, U>::type does not exist and therefore if T and U have not common type -- so to implement N3351's concept Common<T, U>. Is there a way to implement this alternative design? Thanks. --Lorenzo

8 22

[graph] kick out or replace transitive_reduction()?
by Johannes Lorenz 08 Oct '12

08 Oct '12

Hi, shall the transitive_reduction function (transitive_reduction.hpp) of boost_graph ever be used? I ask because * I can find no docs about it * It is unhandy to use, since the nodes are permuted (in opposite to transitive_closure(), which offers a version with *constant* permutation) * I've found bugs in the header, which were stated to be bugs by the original author (asked him via email) If this function should not be used, I'd write a very simple one, using the formula from [1]. Note that this will only work for DAGs, but that's better than nothing. What do you think? Regards, Johannes [1] http://en.wikipedia.org/wiki/Transitive_reduction#Graph_algorithms_for_tran…

1 0

[1.52.0] Beta release candidates available
by Marshall Clow 08 Oct '12

08 Oct '12

Release candidate files for 1.52.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 61a852c923c7e27d84fd2e6336d787f2 *boost_1_52_0_beta1_rc1.tar.gz 956fb476326ee634225c683612493fdd *boost_1_52_0_beta1_rc1.tar.bz2 703663eca3122152031c5555e26845c0 *boost_1_52_0_beta1_rc1.zip b277b6f36ead9df9a0754c868956f30c *boost_1_52_0_beta1_rc1.7z Thanks, --The release managers

5 6

[TTI] library now status?
by osyo manga 07 Oct '12

07 Oct '12

Hi. What is the state of Boost.TTI ? I seem to have not changed for more than one year in boost-svn. Thanks.

2 1

[exception] boost::throw_exception vs deriving from boost::exception
by John Salmon 07 Oct '12

07 Oct '12

I'd like to use Boost.Exception's error_info capabilities in an existing code base. It seems to me that I have two choices: 1 - find all the 'throw my_except(...)' in the code base and replace them with boost::throw_exception(my_except(...)). 2 - find all the struct my_except{...} definitions in the current code base and replace them with: struct my_except: virtual boost::exception {...} I find #2 more appealing for the following practical reasons: - there are fewer locations to change. Exceptions are defined less often and in fewer places than they are used. - there is less to remember. Developers who write new throw expressions need to remember nothing. Developers who define new exceptions must remember to derive them from boost::exception, but this is much less common. Are there reasons I should prefer boost::throw_exception instead? I can only think of one: boost::throw_exception also adds N2179 support via enable_current_exception. This isn't a current concern, but our compilers (gcc and clang) already support N2179 directly, so we can use std::current_exception rather than boost::current_exception if the need arises. Are there other reasons to prefer boost::throw_exception? Thanks John Salmon

3 2

[Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE
by Michel Morin 07 Oct '12

07 Oct '12

First, thanks Eric for fixing incompatibility between Phoenix and decltype-based result_of. This is really a great fix! I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1 The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support? P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it? Regards, Michel

2 4

[lexical_cast] exception type for overflow
by Jochen Wilhelmy 06 Oct '12

06 Oct '12

Hi! i would expect that lexical_cast<uint16_t>("65536") and numeric_cast<uint16_t>(lexical_cast<int>("65536")) would throw the same exception boost::numeric::positive_overflow. but lexical_cast throws a bad_lexical_cast. is it possible to change lexical_cast so that it also throws positive_overflow if the error comes from the overflow and not from the lexical parsing? -Jochen

3 2

[countertree] Formal Review Request
by Francisco José Tapia 05 Oct '12

05 Oct '12

Hi all, I would like to request a formal review of the library “Countertree + Suballocator” [countertree] Project location ( zip file with code and documentation) : https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip Quick view of documentation with code download : https://dl.dropbox.com/u/8437476/works/countertree/index.html For the people who don't know this project, this is a description : *COUNTERTREE* This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . Based on this tree we have : - With unordered information we have vectors (countertree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. - With ordered information, we have in the countertree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) *SUBALLOCATOR* In the allocation of equal size elements ( as in STL list, set, multiset,map and multimap), when the number of elements grows, many allocators begin to have speed problems. For to improve the speed, many allocators request to the Operating System big chucks of memory ( pool allocators). With this, the allocator don't need request memory to the operating system for each allocation. But many allocators don't return well the unused chucks of memory to the Operating System and the memory used by the allocator is the maximum used, never decrease . The *suballocator is a solution to these problems*, and others memory problems described in the suballocator page. The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator request memory to the allocator, and return to it when unused. The suballocator replace to the allocator in the allocation of equal size elements With the suballocator a) *We have a very fast allocation* *(around 2 times faster than the std::allocator of GCC 4.7, CLANG 3.0 and 3 times than Visual Studio 10 *See details in the *Suballocator Benchmark*)* b) *Return the suballocator return memory to the allocator, this can use in the allocation of others types of data or for return to the *Operating System, decreasing the memory used by the program, *( as you can see in the *Suballocator Benchmark *)* c) *You can use with any allocator if it is according with the STL definition*. The suballocator provides speed and memory management to any allocator. d) Even the time of the allocation is a small part of the time spent in the insertion in a std::set, the suballocator obtain time reductions over over the 30% respect the std::allocator. The secret is the cache performance due to the data locality improvement. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace countertree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance for big number of elements It is fast, useful and easy to understand and use,. They are the like the STL classes with a few additional functions. This library is designed thinking in programmers with a basic knowledge of C++. As I say in the documentation, if you know the STL classes vector, set , multiset, map , multimap and allocator, you know more than 95% needed for to use this library. I showed the library to several friends and colleagues, and one of them said me “If your potential users are not experts, and they need more than 5 minutes to understand what's the goal of the library and what they can do with it, many of them leave the page.... , and the library”. The first page of the documentation explain the library, the reasons and what can do. And in the next pages show the details and how can do in a a easy way. I had checked this code with GCC 4.7 , CLANG/LLVM 3.0 and Visual C++ 10 ( all with 32 and 64bits.). In code of the project is composed by the code of the classes, the test programs, the benchmarks programs used and mentioned in the documentation, and several examples of the code I had checked all the requirements for to request the review. But I am not sure if all is OK. If you miss something or something is wrong , please , mail me and I will correct as soon as possible Sincerely yours Francisco Tapia fjtapia(a)gmail.com

4 9

[graph][heap][coroutine] interruptable dijkstra shortest path function
by Alex Hagen-Zanker 05 Oct '12

05 Oct '12

[apologies for double posting, send it to wrong list before] Hi, A few months ago I posted here to gauge interest for an interruptable and resumable version of the dijkstra_shortest_path algorithm. The initial response was positive, but Jeremiah considered the proposed solution lacking compared to an algorithm object model that inverts the control over the algorithm, Additional to my original solution, I now have two implementations of the algorithm object model. 1. Visitor based interruption. This is my original approach. It separates the algorithm into an init and main function. The main function asks the visitor if it should be halted afer each iteration. After halting, the main function can be used to resume the calculation. auto dijkstra = make_dijkstra_object(graph, named_parameters); dijkstra.init_from_sources(sources); dijkstra.expand( interruptor); dijkstra.expand( other_interruptor); auto distance_map = dijkstra.get<vertex_distance_t>(); auto color_map = dijkstra.get<vertex_color_t>(); 2. Algorithm object implementation. This was suggested by Jeremiah. The algorithm object iterates from control point to control point in the algorithm. Giving at each stop access to the intermediate results of the algorithm. The two implementations are: a) Using the [Coroutine] library that is currently under review to step in and out of the function. b) Fragmenting the function into many subfunctions that are chained together and the other works by fragmenting the original algorithm into a number of small interlinked functions starting at one control point and returning at the next. The interface of a and b is exactly the same and it works like this: auto dijkstra = make_dijkstra_object(graph, sources, named_parameters); while(dijkstra.next() ) { control_point cp = dijkstra.get_control_point(); vertex u = dijkstra.get_u(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(cp == cp_finish_vertex && get(distance_map, u) > 42) { cout << "far enough" << endl; break; } } auto distance_map = dijkstra.get<vertex_distance_t>(); The algorithm object offers most flexibility for interweaving multiple searches. The visitor based solution on the other hand is more efficient. The latter has no loss in performance compared to the existing dijkstra functions. The coroutine algorithm object was extremely easy to implement but it is not very efficient. Does anybody have a suggestion how that can improve? Besides these interruptable and resumable shortest path searches, there are a few more advantages to the implementation. a. All dijkstra parameters are bundled in a light-weight dijkstra_state object that is returned by algorithms, giving direct access to all results of the algorithm, for instance: auto dijkstra_state = dijkstra_shortest_paths(graph, sources, no_named_parameters() ); auto distance_map = dijkstra_state.get<vertex_distance_t>(); b. Named parameters (old style) are also used for the priority queue and the color map c. Boost.Heap mutable queues can be used with Boost.Graph via the named parameter interface. It doesn't help performance now, but may be a good base for experimentation. d. Separation of the dijkstra shortest path algorithm in init and main function makes it easier to provide custom initialization. For instance: multiple sources or only re-initializing changed vertices Can anybody use this? The latest version is here: http://people.pwf.cam.ac.uk/ahh34/dijkstra.zip Kind regards, Alex p.s. below are timings for a large graph: bimba_6M.obj... 2090 ms. Boost Graph Library 2121 ms. With interruption visitor 5601 ms. With Coroutine(*) 2621 ms. With fragmented functions (*) 2840 ms. With Boost.Heap (*) halting at all control points of the dijkstra visitor

8 21