1

I was trying to write user defined object with std::vector.

I read that for User Defined classes, if Copy Constructor and Assignment Operator are public then only one can insert its object in STL container.
This is because of two reasons::

  1. All STL contains always stores the copy of inserted objects, not the actual one. So, whenever we insert any element or object in container then it’s copy constructor is called to create a copy and then this copy is inserted into the container.
  2. While insertion in std::vector it might be possible that storage relocation takes place internally due to insufficient space. In such cases assignment operator will be called on objects inside the container to copy them from one location to another.

why all STL container always stores the copy of inserted objects, not the actual one?
I couldn't understand the reason as to why they didn't allow the storing of the actual object. what was the disadvantage?
Sourav
  • 145
  • 1
  • 14
  • 5
    Value semantics is the key point of C++ container. – llllllllll Mar 19 '18 at 12:29
  • 2
    what do you mean with "copy" vs "actual object" ? The objects in the containers **are** the actual objects and if you want to can construct them in place. It just happens that because containers store values (not references or pointers) they **need** to make a copy when you push a value – 463035818_is_not_an_ai Mar 19 '18 at 12:30
  • So if the item wasn't copied; how would you push back the local-to-loop item without having UB? – UKMonkey Mar 19 '18 at 12:32
  • consider this extremely simplified "container": `struct single_int { int x; single_int(int y): x(y) {} };` there is no way to make it store the `int` you pass to it, but it stores a copy, because it is managing its own ressources – 463035818_is_not_an_ai Mar 19 '18 at 12:35
  • maybe the question can be answered properly if you explain how you think it should work "to store the actual object instead of a copy", because currently it isnt clear what you mean by that – 463035818_is_not_an_ai Mar 19 '18 at 12:38
  • 1
    You can store (smart) pointers to the objects, [construct them in-place](http://en.cppreference.com/w/cpp/container/vector/emplace) inside the container, [`std::move` them into the container](http://en.cppreference.com/w/cpp/container/vector/push_back), or insert copies of them. It's all up to you. – Bo Persson Mar 19 '18 at 12:48
  • FWIW starting in C++ you can directly construct objects in the containers and when they grow (if applicable) they will move them around instead of copy as long as the object is `nothrow` moveable. – NathanOliver Mar 19 '18 at 12:57
  • A copied object _*is*_ an object. There is no difference between a copied object and an "actual" one. Indeed, what comprises an object _is defined_ by what its copy-contructors and assignment operators do. This is different than Java or Python where a name refering to an object references it through a hidden pointer. When you want that kind of semantics, you can use references& or pointers. See "unique_pointer" and "shared_pointer". – Jive Dadson Mar 19 '18 at 13:15

1 Answers1

2

The standard containers in C++ allocate memory that they manage. If your program creates an object, then that object is in another memory place, so to be part of the container, a copy is made in the memory of the container.

Instead of copying, moving could have been done, but in a lot of cases, that would not be more efficient and sometimes it could even be quite inconvenient.

A good solution to avoid copying is to create the object directly in the container with the emplace-functions.

About the vector growing, because it is possible that the new vector has to be at a different memory address and the memory contains the objects, they have to be moved or copied. This answer shows how you can make the vector move upon resizing.

stefaanv
  • 14,072
  • 2
  • 31
  • 53
  • Actually, since C++11 push_back of std::vector can also accept rvalues. So moving values in is possible, in addition to the possibility to have copies added to the vector. – kaba Jan 03 '20 at 01:26