April 2014 - Boost - lists.preview.boost.org

Status of Boost.Test library maintenance
by Kamil Witecki 11 Apr '14

11 Apr '14

Hello, I would like to ask what is current status of Boost.Test library. Looking at Trac there is number of open issues that are pending and not much is being done about these, even patches were proposed. Is the library not maintained anymore, what would be sad, or I just got false impression? In case of former what is the process of handing over maintenance of library so that it won't become abandoned? Pozdrawiam, Kamil Witecki.

1 0

Compile-time string comparing
by Anton Bikineev 11 Apr '14

11 Apr '14

Hi all. I think it's frequently asked question. If so, I'm sorry. Is there anything feature in Boost that allows to compare strings at compile-time? I know that it is easy-implemented with generalized constant expressions, but I'm primarily interested in compatibility of compilers. Thanks.

3 3

[align] Are you rewriting history with every push?
by Mostafa 11 Apr '14

11 Apr '14

Glen, Are you rewriting history or force pushing commits to "https://github.com/glenfe/align". I have a local repo set to track your remote and every time I pull to update to your new commits I get merge conflicts. In fact a new clone shows that the history for master has only one commit, the most recent one, when it should show at least three. Can you avoid doing this in the future? Thanks, Mostafa

2 1

Re: [boost] boost::optional -- updates for C++11 move semantics
by Chris Glover 10 Apr '14

10 Apr '14

On Wed, Feb 6, 2013 at 1:26 AM, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2013/2/5 Diggory Hardy <lists(a)dhardy.name>: > > Dear list, > > > > I wanted something like boost::optional, but with support for move- > > construction/assignment, so I went ahead and had a go at patching it. > > It is a really good addition for boost::optional library, which I'd love > to see. > As I know, current maintainer of Boost.Optional has not much time, so > may be someone will contact him and give a hand in maintaining > optional (Diggory, if you are interested, I think you can give it a > try and may be become a co-maintainer of optional, if Fernando > Cacciola agrees) > > > Attached is based on boost 1.49 (Ubuntu package). Could someone please > review? > > I've not contributed to boost before. The changes at least aren't too > > complicated, but: > > 1) I'm not entirely sure if the move constructor (line 636) and swap > function > > (line 1046) are implemented in the best way (also see line 279), > > 2) and I have no idea how is_[not_]reference_tag (line 486) works. > > 3) There should maybe also be a unit test. > > > > Of course, I am happy for my contributions to be published under the > boost > > licence. > > You may see this patch: https://svn.boost.org/trac/boost/ticket/1841 > It proposes same features (and there is an old comment from library > maintainer that he will take care of it) > If you wish, you may update this patch (change deprecated #ifdef > BOOST_HAS_RVALUE_REFS to #ifndef BOOST_NO_RVALUE_REFERENCES), add some > unit tests, and may be maybe update it to use Boost.Move. > > -- > Best regards, > Antony Polukhin > > Hi, This thread is more than a year old, but seems to have died. Does anyone know what the status of this is? I just ran into this today and it seems to me that with more move-only types out there, optional needs to support it. Is there anything I can do to help get it in? Thanks, -- chris

2 2

[Range] contains() for unsorted ranges?
by Albert Yiamakis 10 Apr '14

10 Apr '14

Hello, Wouldn't the library be well served by providing a contains() algorithm - with the same overloads/versions as find - for unsorted ranges? Surely, having to test against the range's end ruins the otherwise expressive syntax offered; especially when adaptors are involved and one has to test against the adapted range's end. Perhaps I am missing an obvious reason why not? Albert -- kojirion.github.io

4 4

[FWD: [serialization] anybody interested in freelancing? - forward-compatibility improvement needed
by Andrzej Horoszczak 10 Apr '14

10 Apr '14

1 0

Re: [boost] [graph/adjacency_list] edge have many costs
by Jeremiah Willcock 10 Apr '14

10 Apr '14

On Tue, Apr 8, 2014 6:59 AM PDT aymen kaabi wrote: >Good morning, > > >I want to create a graph that their egdes have array of cost ( i dont mean >bundle property) because i want to create this graph and try dijikstra for >every cost values . >can i have an example. > >example: graph have 2 edge 1->2 ( cost 1,2,3,4,7) > 2->3(cost 2,5,3,8,9) > >thanks for your helps Edges can have arbitrary properties, so you can create a graph whose edge weight property is a container type. What are you planning to use the multiple weights for? For some uses, parallel edges between the same vertices might make sense to consider as well. -- Jeremiah Willcock

2 1

Re: [boost] [BGL] Visual Studio 12 finish_edge() failure, general BOOST_TTI_HAS_MEMBER_FUNCTION failure?
by Jeremiah Willcock 10 Apr '14

10 Apr '14

On Tue, Apr 1, 2014 1:12 PM PDT Michael Behrns-Miller wrote: >On 4/1/2014 8:45 AM, Edward Diener wrote: >> On 4/1/2014 4:50 AM, Michael Behrns-Miller wrote: >> On 4/1/2014 4:40 AM, Michael Behrns-Miller wrote: >>> On 3/31/2014 6:30 PM, Edward Diener wrote: >>> On 3/31/2014 1:27 PM, Michael Behrns-Miller wrote: >>>> ... >>>> Here's how BGL defines it: >>>> >>>> ------------- >>>> >>>> BOOST_TTI_HAS_MEMBER_FUNCTION(finish_edge) >>>> >>>> template <bool IsCallable> struct do_call_finish_edge { >>>> template <typename E, typename G, typename Vis> >>>> static void call_finish_edge(Vis& vis, const E& e, const G& g) { >>>> vis.finish_edge(e, g); >>>> } >>>> }; >>>> >>>> template <> struct do_call_finish_edge<false> { >>>> template <typename E, typename G, typename Vis> >>>> static void call_finish_edge(Vis&, const E&, const G&) {} >>>> }; >>>> >>>> template <typename E, typename G, typename Vis> >>>> void call_finish_edge(Vis& vis, const E& e, const G& g) { // Only >>>> call if method exists >>>> do_call_finish_edge<has_member_function_finish_edge<Vis, >>>> void>::value>::call_finish_edge(vis, e, g); >>>> } >>> >>> The invocation of has_member_function_finish_edge has to match the >>> member function signature which you are invoking. If the member >>> function signature for finish_edge is: >>> >>> void finish_edge(const E&, const G&); >>> >>> then your invocation for do_call_finish_edge must be: >>> >>> do_call_finish_edge >>> < >>> has_member_function_finish_edge >>> < >>> Vis, >>> void, >>> boost::mpl::vector >>> < >>> const E&, >>> const G& >>> > >>> > >>> ::value >>> >::call_finish_edge(vis, e, g); >>> >>> or >>> >>> do_call_finish_edge >>> < >>> has_member_function_finish_edge >>> < >>> void Vis::* (const E&,const G&) >>> > >>> ::value >>> >::call_finish_edge(vis, e, g); >>> >>> >>> _______________________________________________ >>> Unsubscribe & other changes: >>> http://lists.boost.org/mailman/listinfo.cgi/boost >>> >>> Thank you Edward. >>> >>> The instantiation code was not mine, that is what is done by the BGL, >>> here: >>> >>> boost\graph\depth_first_search.hpp >>> >>> The instantiation code does not seem to match your recommendation. >>> This simple DFS test fails: >>> >>> https://svn.boost.org/trac/boost/attachment/ticket/9770/test.cc >>> >>> So it sounds like BGL needs some patching to match your format. It >>> should change from... >>> >>> do_call_finish_edge<has_member_function_finish_edge<Vis, >>> void>::value>::call_finish_edge(vis, e, g); >>> >>> to... >>> >>> do_call_finish_edge<has_member_function_finish_edge<void Vis::* (const >>> E&,const G&)>::value>::call_finish_edge(vis, e, g); >>> >>> Does that sound correct? >> >> On the newer code, Visual Studio 12 gives me: >> >> boost_1_55_0/boost/graph/depth_first_search.hpp(86): error C2182: >> 'abstract declarator' : illegal use of type 'void' >> >> I am the developer for TTI. In your test case the actual VIZ struct has templated member functions, so I do not think has_member_function will find your templated functions. TTI is a compile-time mechanism for producing compile-time code. But even if it does not find the member functions at compile-time TTI should not produce a compile-time error so I definitely want to look at this situation. >> >> As to why Visual Studio 12 gives that error I need to be able to reproduce your compile steps. I am an absolute novice with the Boost graph library. I think I need to build the library first, then run your test against it. >> >> Jeremiah Willcock produced the changes in graph using TTI so he may have had a very good reason for using the original has_member_function signature, although it looks wrong to me on purely a TTI basis. Hopefully he will chime in on his change. >> >> >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > >Thanks Edward, appreciate the feedback, I'll be monitoring. In the meantime my workaround of making finish_edge() non-optional is working for me. But of course I'd prefer not to have to change boost code before using. :-) > >Sure appreciate all you guys do to develop and maintain the libraries, boost is just fantastic. I wanted a way to test for equivalent signatures for the finish_edge member (copy vs. const ref, for example). I probably believed/saw somewhere that the syntax I used would do that. Is there a way to get a general "call ability" test for a member function using TTI? -- Jeremiah Willcock

2 1

Error running ip_multicast (and ip_multicast_select) regression tests
by Chris Cooper 09 Apr '14

09 Apr '14

When I run the ip_multicast (and ip_multicast_select) regression tests for boost 1.55 on my Mac, they fail with these errors: ip/multicast.cpp:165: error in "ip_multicast_runtime::test": 49, Can't assign requested address ip/multicast.cpp:181: error in "ip_multicast_runtime::test": 49, Can't assign requested address I’m new to IPv6, but it looks like the regression test is making sure that IPv6 is available (multicast.cpp lines 128-132), and then it’s trying to join a IPv6 multicast group (lines 163-165) and leave it (lines 179-181), and failing both times. I’m not sure how to check whether multicast is enabled for IPv6 on this machine (which I’ve seen online as a possible reason for this failure), but then it seems like the regression test is not so great if it can fail due to the environment of the host computer instead of an actual bug in the boost library. Are there other reasons why this test would fail? Is there a way I can check whether multicast over IPv6 is allowed on this machine? Is there a recommended way to disable one particular subtest like this one? A #ifdef kind of thing? Thanks, Chris

1 0

[context] Don't hard-code the assembler
by Steven Watanabe 09 Apr '14

09 Apr '14

AMDG This commit: https://github.com/boostorg/context/commit/7534fe5d1c01e7f543d86607770e9c46… makes it impossible for me to run b2 --with-context msvc-12.0 outside of the visual studio command prompt. Please just use the assembler that the toolset provides. In Christ, Steven Watanabe

8 22