- Boost - lists.preview.boost.org

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 02 May '14

02 May '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 29

Spam in tickets
by Antony Polukhin 02 May '14

02 May '14

Hi, Could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/9963<https://svn.boost.org/trac/boost/ticket/7108> ? -- Best regards, Antony Polukhin

4 3

[graph] dijkstra algorithm object
by alex 30 Apr '14

30 Apr '14

Dear Jeremiah and Boost list, I'd like to suggest for inclusion in Boost Graph Library an algorithm object version of dijkstra shortest path algorithm. The following is an example how it can be used, assuming some graph, source node(s) and threshold distance: auto dijkstra make_dijkstra_object(graph, source_range); while(dijkstra()) { auto v = dijkstra.get_vertex(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(get(distance_map, v) > threshold) break; } It is very close to what Jeremiah suggested 2 years ago: http://lists.boost.org/Archives/boost/2012/07/195300.php The main advantage for me is the possibility to interweave several shortest path searches. The algorithm object makes use of the stackless coroutine in Boost ASIO, which means it is relatively lightweight. However, on a large graph the algorithm object still takes about 20% more time than the normal dijkstra_shortest_path. The operator() progresses the algorithm to the next control point. Control points can correspond to all places where breadth_first_search invokes its visitor, but it is specified in compile time at which potential control points the algorithm actually yields. The default is to halt at the finish_vertex control point only. The make_dijkstra_object function can take all parameters through bgl_named_parameters, including the priority queue and the color map, which the existing dijkstra_shortest_path does not support. The code is part of the following project: http://code.google.com/p/resumable-dijkstra The algorithm object is defined here: http://code.google.com/p/resumable-dijkstra/source/browse/trunk/resumable-di jkstra/blink/graph/dijkstra_object.hpp I look forward to hear if there are any takers this time. Best wishes, Alex

1 0

[MPI] Fix can be merge to master
by Ben Pope 30 Apr '14

30 Apr '14

Please merge https://github.com/boostorg/mpi/commit/a7a2501242e78c65df9ff82c67dcad1f016b… to master. Should fix mpi and graph_parallel Ben

1 2

Request for comments on break up ‘Application’ into 2 libraries.
by Renato Forti 30 Apr '14

30 Apr '14

Hi All, Following suggestion of Niall Douglas, I am thinking in split the ‘Boost.Application’ in 2 libraries: - - Boost.Application - Boost.Shared_Library Thus, the ‘plug-in systems’ will be detached of ‘Boost.Application’ core and will become one new library, and ‘Application’ stay only providing abstraction of an application (no more plugin system) I will detach this part: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applic… Anyone have any comment/advises about it? Any suggestion? Anyone disagrees? I await your comments, thanks! -- ReTF

4 3

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

Linker error, Windows 7, one specific function from one specific library
by Chris Cooper 28 Apr '14

28 Apr '14

I’m trying to get the boost 1.55 regression tests to build on my Windows machine (msvc-10.0), and nearly all of them build fine but a few of them: pool.pool_msvc_compiler_bug_test pool.test_bug_1252 pool.test_bug_2696 pool.test_bug_3349 pool.test_bug_4960 pool.test_bug_5526 pool.test_msvc_mem_leak_detect pool.test_pool_alloc pool.test_simple_seg_storage pool.time_pool_alloc Give this error : pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ) pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat@system@boost@@YAXXZ) If my libraries were completely wrong, I would expect everything to fail, and many more unresolved symbols, but it’s just this one symbol that is confusing the linker. The command line I’m using to build these tests is: b2 toolset=msvc-10.0 --without-mpi --build-dir=C:\temp address-model=64 variant=release link=static threading=multi --dump-tests test_bug_1252 Which compares favorably with the command lines I’m using to build the libraries: b2 -j4 --without-mpi --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --without-mpi --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install b2 -j4 --with-math --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --with-math --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install I inherited the build scripts, so I’m not sure why b2 is being called 4 times, is that a problem? Should I merge the “--without-mpi” into calls 3 and 4, and get rid of calls 1 and 2? Why is it having trouble with just this one symbol? Thanks, Chris

2 1

Announcing the student program for Meeting C++ 2014
by Jens Weller 28 Apr '14

28 Apr '14

Hello C++ and Boost Community, today I have the honor to announce the student program for Meeting C++ 2014: > The Meeting C++ Student program will enable 50 students to attend Meeting C++ 2014 plus 3 exclusive workshops organized by think-cell one day before the conference on December 4th. So, for students this will be a 3 day conference! After the workshops you will be invited to the student dinner by think-cell. Further details at http://meetingcpp.com/index.php/newsreader/items/meeting-cpp-2014-the-stude… kind regards, Jens Weller

1 0

[graph] Undocumented function bron_kerbosch_all_cliques
by Javier Dehesa 28 Apr '14

28 Apr '14

Looking for clique search algorithms in BGL, I've found out that there exists the function bron_kerbosch_all_cliques, but that there is not documentation for it. The implementation fo the algorithm can be found here http://www.boost.org/doc/libs/1_55_0/boost/graph/bron_kerbosch_all_cliques.… and there is even an example program using it http://www.boost.org/doc/libs/1_55_0/libs/graph/example/bron_kerbosch_print… Also, it seems to define a "clique visitor" concept that is not documented either. Is there any reason for it? Maybe there is some problem with the implementation? Or is it just missing documentation? I've run some toy examples and it seems to work, but I can't tell if there would be a problem with large graphs. -- Javier Dehesa

2 1

Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 27 Apr '14

27 Apr '14

On 23 Apr 2014 at 14:33, Paul A. Bristow wrote: > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: but I > don't have any much better ideas. Perhaps someone else has? To clarify the issue to everyone else, TypeIndex is in a rather unusual bind with regard to what namespace to use. Ideally I think we'd all agree that boost::type_index would be best, but then one of the issues raised last peer review was that there shouldn't be a boost::type_index type as could conflict with std::type_index, and if we hold that to be wise, then surely the same rationale applies for a boost::type_index namespace as well. So we end up with boost::typeind, which I don't think makes anyone happy, but it is safe. > IMO, the frequency of use of the namespace bti is probably so low that spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable Noted. > > 8. Do you think the library should be accepted as a Boost library? > > Yes. Thanks Paul for the vote and quick turnaround. I was worried that the review announcement had got lost. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 7