Is there a std container, other than std::vector, which does not copy and destroy elements which are classes?

I know that std::vector::push_back() puts a copy in the vector. I am looking for a way or a std container which does not destroy the class members of an instantiated class.

I have a class, WindowsWindow with members,

private:
	GLFWwindow* m_pGLFWwindow = nullptr;
	EventHandler m_eventHandler;
	VertexArrayObject m_VAO;
	bool m_windowAvailable = true;
	std::uint8_t m_windowNumber = 0;
	std::string m_windowTitle = "";

Two of those members, viz., EventHandler, VertexArrayObject, are classes which themselves contain members which are classes.

When I std::vector::push_back() an instantiation of a WindowsWindow object into or onto a std::vector, all of the class member variables are destroyed since a copy is being made and then destroyed. Maybe the answer is to make a deep copy constructor for each class, which I have not tried.

I also tried,

std::vector<std::shared_ptr<WindowsWindow>> WindowsWindowVector;
std::shared_ptr<WindowsWindow> pmainWindow = std::make_shared<WindowsWindow>("Main Window", false);
...
WindowsWindowVector.push_back(pmainWindow);

Which fared no better.

1. Is there a std container I might employ which does not make, store and destroy copies of the elements being added?

2. Would a deep copy constructor for each class in question solve the problem?

3. Would a standard "C" style array work?

I have gotten into the habit of using std::vector in place of the "C" style array for non-class objects so this is all a new experience.

You have two problems here.

1. Your class is not copy-safe.

   This is a problem anyway. If you do not want your classes to have deep copy semantics, then that's fine they don't have to… but then it should be made safe to copy (by not owning & destroying the resources they refer to), or at least should be made non-copyable.

   Alternatively, as you say, make them deep-copyable (though this may not be what you want).

2. You're copying unnecessarily.

   push_back doesn't have to copy. There is a push_back(T&&).

   So, consider std::moveing your objects into the vector instead. With a properly implemented move constructor and move assignment operator in WindowsWindow, this will be very cheap.

   You could also emplace-construct the element directly.

Neither of these is std::vector's fault, and creating a replacement vector type that does not do this would only be a strange hack around your class's broken copy/move semantics.

tl;dr: properly implement copy and move semantics for your class.