Question about emplace_back()

Oct 19, 2013 at 4:58am
My understanding is emplace_back() will neither copy nor move objects. It constructs the object in-place. So following code should compile:

class Person {
public:
Person(string name) { }
Person(const Person&) = delete;
};

int main() {
vector<Person> persons;
persons.emplace_back("George");
}

But it didn't. It errors “reference a deleted function Person(cont Person&)"

I tried it with GCC 4.7, VS2012, VS2013, and all failed. What is wrong?

Oct 19, 2013 at 5:24am
While std::vector::emplace_back doesn't require either of those things to be defined, std::vector does require it's elements to be either copy or move constructable.

[edit: On the other hand, std::deque has no such requirements. http://ideone.com/y3dL8b Although, the number of methods you can use that don't require one or the other is limited.]
Last edited on Oct 19, 2013 at 5:30am
Oct 19, 2013 at 5:49am
Thanks a bunch, cire. It puzzled me for a while. I knew that if I declared my own copy constructor, the default move constructor will be deleted. But I didn't know even if I just declare the copy constructor to be deleted, the default move constructor will also be deleted. It doesn't quite make sense to me.
Oct 19, 2013 at 6:36am
> It doesn't quite make sense to me.

The whole issue of implicitly generated move constructors were the subject of intense debate during the standardization process.

It started with Scott Meyers pointing out in comp.lang.c++ that the original proposal for implicit generation of move constructors could break C++03 class invariants.
https://groups.google.com/forum/#!topic/comp.lang.c++/1R1igvCYs8o

Eventually, a solution based on Rani Sharoni’s idea was what was adopted by the committee. Summarised by Herb Sutter in this blog post ('Restricting implicit move generation'):
http://herbsutter.com/2010/12/08/trip-report-november-2010-c-standards-meeting/
Topic archived. No new replies allowed.