http://llvm.org/bugs/show_bug.cgi?id=16238

            Bug ID: 16238
           Summary: Modifying a deque from emplace_back produces incorrect
                    results
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
    Classification: Unclassified

>From my skimming into the standard, nothing specifically seems to prohibit
modifying a `std::deque` from inside `emplace_back`. Take this snippet for
example:

    #include <iostream>
    #include <deque>
    #include <string>

    using namespace std;

    struct foo
    {
        string m_marker;

        foo(deque<foo>& into, const string& marker, bool createInner = true)
        : m_marker(marker)
        {
            if (createInner)
            {
                cout << "Marker is " << m_marker << endl;
                into.emplace_back(into, "my other marker", false);
                cout << "Marker is now " << m_marker << endl;
            }
        }
    };

    int main()
    {
        deque<foo> foos;
        foos.emplace_back(foos, "my initial marker");

        cout << "There are " << foos.size() << " items in the deque:" << endl;
        for (foo& f : foos)
            cout << f.m_marker << endl;
    }

(listing also at http://stackoverflow.com/q/16955265/)

I would expect this as the result:

> Marker is my initial marker
> Marker is now my initial marker
> There are 2 items in the deque:
> my initial marker
> my other marker

However, this is what I get:

> Marker is my initial marker
> Marker is now my other marker
> There are 2 items in the deque:
> my other marker
>  

It looks like calling `emplace_back` from within a constructor itself called
with `emplace_back` causes the deque to overwrite the first item with the
second.

I couldn't find anything that specifically prohibits modifying the container
from `emplace` methods in N3337, although I can see why this could be a
problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs

Reply via email to