- Boost - lists.preview.boost.org

[TTI] macro to "box" types for subsequent traits extraction?
by Rein Halbersma 07 May '14

07 May '14

Hi everyone, this is my first post to this mailinglist, so I hope I follow the proper conventions around here (yes, I did read the Discussion Policy). I have a small feature request for the Type Traits Introspection library: a macro BOOST_TTI_BOX_TYPE(U) that defines a class template box_type<T> with a nested typedef named "type" that equals T::U. Rationale: because box_type<T> is a metafunction that can be supplied to mpl::eval_if, this facilitates user-defined traits that extract a nested type U, but can fall back to a (user-defined) default type. This mimics the C++11 allocator_traits that also provide defaults for allocators that lack certain nested typedefs or other properties. Small self-contained example: http://coliru.stacked-crooked.com/a/76b9abf4aaf00350 One could probably also define similar "boxing" macros to go along with the has_template and other introspection tools in TTI. Would this be considered a useful feature? Rein

3 4

[locale] Who owns/has commit access to review/merge a pull request?
by Chris Stylianou 07 May '14

07 May '14

I have a pull request on boost::locale (on the develop branch), but it appears there has no activity in this repository since the SVN -> Git migration occurred. Who actually maintains boost::locale? I would really like to have this pull request review and then hopefully merge, so that it makes the 1.56 release :) -- View this message in context: http://boost.2283326.n4.nabble.com/locale-Who-owns-has-commit-access-to-rev… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 5

Constant iterator of Single Pass Range
by Jan Hudec 07 May '14

07 May '14

Hello All, The documentation of [Single Pass Range][1] in Boost.Range says that there should be both `iterator` and `const_iterator` associated types and both const and non-const overloads for `begin` and `end`. However if it is really a single-pass range, I don't see a way to implement a `const_iterator` that would work on `const` reference to the range, because the `operator++` of the iterator involves calling a non-const method of the range. For example the `std::istream_iterator::operator++` calls `std::istream::operator>>`, which is non-const and so there is no `const_istream_iterator`. The `istream_range` cheats around this a little, because the range is a wrapper around the stream, not the stream itself. But when I have similarly behaving class that I can make itself be a range, do I really have to work around this using a wrapper, or can the requirement be relaxed in practice? [1]: http://www.boost.org/libs/range/doc/html/range/concepts/single_pass_range.h… -- Jan Hudec <bulb(a)ucw.cz>

4 8

[1.56] Release status?
by Joaquin M Lopez Munoz 06 May '14

06 May '14

Hi, Seems like Boost 1.56 release schedule has been postponed sine die. Is there any blocking issue with the SVN->Github transition that the release depends upon? Thank you, Joaquin M López Muñoz Telefónica

3 2

Help transfer type_index library to the boostorg
by Antony Polukhin 06 May '14

06 May '14

Hi, TypeIndex library was accepted into the Boost. Only a few minor issues remain unfixed so it's time to transfer the library to the boostorg. Unfortunately I have no permissions to do so. Could someone help? -- Best regards, Antony Polukhin

2 2

marking regression test failures as expected
by Andrzej Krzemienski 06 May '14

06 May '14

Hi, I noticed in the regression tests results taht some failing tests are marked as "fail*" in greyish color indicating that the failure is expected along with the explanation why. E.g., http://www.boost.org/development/tests/develop/developer/output/teeks99-03a… Question: how can I indicate that the new failure is expected in the same manner? Regards, &rzej

3 3

Anyone driving from/to Denver?
by Sebastian Redl 06 May '14

06 May '14

Hi, I could only get my bonus miles flights to Denver, not Aspen, so I'm wondering whether anyone else is only flying from/to Denver and driving the rest of the way. I would be interested in sharing that car. Please let me know. Sebastian

3 3

[atomic] Constraints on failure_order?
by Bjorn Reese 05 May '14

05 May '14

According to [1]: "The compare_exchange_weak/compare_exchange_strong variants taking four parameters differ from the three parameter variants in that they allow a different memory ordering constraint to be specified in case the operation fails." According to std::atomic there are some constaints on failure_order. Is this also the case for boost::atomic? [1] http://www.boost.org/doc/html/atomic/interface.html

2 1

[asio] intergrate with message loop how to
by microcai 05 May '14

05 May '14

on platform windows, asio is using IOCP. and IOCP handel got signaled when there is pending events thus we can use MsgWaitForMultipleObjectsEx to wait on both the message queue and the IOCP. when we get a message, call PeekMessage and then DispatchMessage just like the mornal message loop. when we get IOCP singaled, call boost::asio::io_service::pull_one() and we processed the IO events ! by this way, we can have a thread that does both GUI and IO. that's very handy for non-performance critical applications. but, we can't access to the IOCP HANDLE used by asio. that's said. very said. on platform Linux, asio is using epoll. we can get X11 socket, and use asio to monitor that socket, and again calls X11 functions when the socket gets ready. thus, we can intergrate X11 message loop with asio, that's fine. if we are using gtk, it is more convinent to have epoll fd monitored by glib first, and then goes to run asio::io_service::pull_one(). again, that required access to epoll fd used by asio. if asio can expose these internal HANDLE or fd , that'll going to be more powefull !

2 1

[TypeIndex 3.0] Review Manager's Report
by Niall Douglas 04 May '14

04 May '14

Dear Boost, The second round of peer review of proposed Boost.TypeIndex finished on Wed 30th, and here is the review manager's report. My thanks to the five reviewers who took the time and trouble to submit full reviews, plus to everyone else who commented. Votes regarding acceptance: 4 voted to accept TypeIndex into Boost immediately. 1 voted to accept into Boost with conditions. Overall: I recommend immediate acceptance into Boost. Conditions: 1. No one liked the present boost::typeind namespace, almost anything else would be better. I see the namespace has already changed in the develop branch to boost::typeindex, so I think this is already solved. Other common comments: * More than one reviewer mentioned how they liked the docs. * More than one reviewer expressed a desire for an ability to programmatically parse through type specifier strings. I agree with Antony that that is another library which isn't TypeIndex (something Boost.Spirit based which works directly with mangled symbol string representations, representing them as a partial AST - preferably also with a libclang compatible backend - would be great, but that is a totally different library and TypeIndex 3.x provides extensibility for such an additional function). * More than one reviewer sought some method of preventing link if you mix up incompatible uses of TypeIndex and/or with RTTI. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

when can a trac ticket be considered closed
by Andrzej Krzemienski 04 May '14

04 May '14

Hi Everyone, Sorry for the silly question; at which point in Modular Boost Library workflow should I close a Trac ticket? Is it when I commit the relevant changes to branch master? Regards, &rzej

4 6

[GSoC, MPL11] Community probe
by Louis Dionne 04 May '14

04 May '14

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

8 21

[thread] shared_spinlock_t idea or faster shared_lock
by Antony Polukhin 02 May '14

02 May '14

Hi, This is just a refining of idea that was once implemented and worked well. The idea was to make shared spin lock. Here is some pseudo-code: class shared_spin_lock { atomic_max_uint_t state_; lock_shared() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { reader_wait(); // waiting for writer to finish continue; } auto new_state = snapshot + 1; } while(!CAS(state, new_state)); } unlock_shared() { --state; } lock() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { writer_wait(); // waiting for other writer to finish continue; } auto new_state = snapshot.set_writer_bit(); } while(!CAS(state, new_state)); // we have set the writer bit, now waiting for readers to finish while (state_.readers_count) ; // busy loop, can we do better? writer_started(); } unlock() { auto snapshot = state_.reset_writer_bit(); writer_finished(); ASSERT (snapshot.has_writer_bit_set()); } }; When all the *_wait() and writer_*() functions do nothing we get a shared spinlock. Now if we add helper mutex and make all the *_wait() functions to lock and unlock mutex; writer_start() - lock the mutex; writer finished() - unlock the mutex... we get a simplified shared_mutex that is faster (in theory) than current implementation. Is there an interest in such shared_spinlock_t? Any comments, suggestions? -- Best regards, Antony Polukhin

6 6

Misuse of warnings-as-errors?
by Chris Cooper 02 May '14

02 May '14

I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course! I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”. But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc. Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere? Thanks, Chris

7 6

[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

Re: [boost] Why no non-null smart pointers?
by Jeff Hill 29 Apr '14

29 Apr '14

Ross MacGregor wrote > "Johan Råde" < > rade@.lth > > wrote in message > news:ft10ag$6nn$ > 1@.gmane > ... > > I know it is an insane idea to suggest changing the entire > boost::smart_ptr library to a boost::smart_ref library, but I > think it may actually be the right thing to do. Does anyone > agree? I also find the nill state of shared_ptr to be a liability when designing interfaces. The primary purpose of shared_ptr when used in an interface context is to convey ownership, and almost always it feels wrong to also provide simultaneously an option to convey ownership of nothing. The poor user is left with the responsibility of testing every shared_ptr he has received for null state before using it, but its easy to forget and the compiler provides no assistance. Ultimately, the library interface based on shared_ptr is more error prone, less likely to be easy to use, and therefore arguably suboptimal. Of course no one suggests that shared_ptr should (or could) be changed in ways that impacts backwards compatibility, but I have to agree with the author of the post that this issue can be identified as a legitimate cause for concern. Jeff -- View this message in context: http://boost.2283326.n4.nabble.com/Why-no-non-null-smart-pointers-tp2642959… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 12

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

[testing] gcc 4.9 test failures
by Andrey Semashev 27 Apr '14

27 Apr '14

Hi, I'm seeing lots of test failures on BP x86_64 C++11 gcc-4.9.0~c11. http://www.boost.org/development/tests/develop/developer/log.html The test logs don't show any errors. Is it possible to see the complete build log?

2 1