Boost C++ Libraries: Ticket #2823: [fusion] vector copy constructor copies sequence members in different order on different platforms

attachment set

dkomisar@… — Tue, 03 Mar 2009 17:45:21 GMT

attachment → test.cpp

dkomisar@… — Mon, 23 Mar 2009 15:38:26 GMT

Took a look at the code and it looks like this is due to function call arguments being called in different orders on different platforms, so there's not much that can be done. I think that this really needs to be highlighted (at least mentioned) in the docs somewhere.

I could be wrong though, I'm not very good at reading PP-intensive code.

Dean Michael Berris — Mon, 29 Nov 2010 03:32:48 GMT

It looks like a compiler bug, should this be marked as wontfix appropriately, and have a different issue for the documentation changes? Joel?

Joel de Guzman — Mon, 29 Nov 2010 03:41:01 GMT

Dean, it's not a compiler bug. This is a known problem. The order of evaluation of function call arguments are undefined accd' to standard. Need further to look into this.

René Rivera — Mon, 29 Nov 2010 04:12:43 GMT

I've run into this problem recently, and bugged Hartmut about it on IRC. My solution to the implementation defined behavior that makes all fusion sequence operations have an unpredictable execution ordering. My solution was to create my own version of fusion::as_list that has a guaranteed execution order. The key being to make copies of the sequence values in the correct ordering. Which boils down to changing fusion::detail::build_cons<First,Last,false>::call(...) from:

static type
call(First const& f, Last const& l)
{
    return type(*f, next_build_cons::call(fusion::next(f), l));
}

To:

static type
call(First const& f, Last const& l)
{
    typename result_of::value_of<First>::type v = *f;
    return type(v, next_build_cons::call(fusion::next(f), l));
}

Dean Michael Berris — Mon, 29 Nov 2010 09:13:06 GMT

Replying to grafik:

The key being to make copies of the sequence values in the correct ordering. Which boils down to changing fusion::detail::build_cons<First,Last,false>::call(...) from:

...

To:

...

Interesting. Let me try that locally and run the tests -- unfortunately I cannot test on multiple platforms. I'll attach the patch for testing.

attachment set

Dean Michael Berris — Mon, 29 Nov 2010 09:21:35 GMT

attachment → boost-fusion-issue2823.diff

Patch as proposed by Rene, applies to r66834.

Marshall Clow — Fri, 07 Jan 2011 01:18:14 GMT

(In [67745]) Applied patch; refs #2823; will merge to release once tests cycle

owner changed

Marshall Clow — Fri, 07 Jan 2011 01:21:21 GMT

owner changed from Joel de Guzman to Marshall Clow

owner changed

Marshall Clow — Fri, 07 Jan 2011 01:56:42 GMT

owner changed from Marshall Clow to Joel de Guzman

On-list, Steven Watanabe wrote:

> result_of::deref would be better. There's no reason to make an extra copy. (Although this code looks pretty copy-happy to begin with).

Joel says that he will take it from here; assigning back to him. However, the patch that I applied does fix the bug.

Dean Michael Berris — Fri, 07 Jan 2011 02:05:51 GMT

I've updated the patch (made against the latest in Trunk, 67745) which implements the suggestion. Please see the new attachment.

attachment set

Dean Michael Berris — Fri, 07 Jan 2011 02:06:38 GMT

attachment → boost-fusion-issue2823-2.diff

Updated patch to take Steven's suggestion.

Marshall Clow — Sat, 08 Jan 2011 18:47:45 GMT

Fix merged to release branch in [67792]; Joel will optimize more.

status changed; resolution set

Joel de Guzman — Fri, 12 Jun 2015 06:52:39 GMT

status new → closed
resolution → fixed