Just come up with this question. Any hint?
+12
A:
classes that can't be copied. STL containers require objects to be copyable since the container owns a copy of that object, and needs to be able to move it around.
Chris H
2010-03-18 05:25:44
Though *pointers* (and smart pointers) to classes that can't be copied are OK.
Dean Harding
2010-03-18 05:28:53
Except `std::auto_ptr`. Don't do it! `std::tr1::shared_ptr` is okay though.
Nate
2010-03-22 19:30:45
+4
A:
Depending on the operations you perform, you oftentimes need a default constructor in addition to being copyable for objects stored in containers. For objects passed to algoriths, there are other requirements, like being callable or incrementable. The requirements are well documented.
Dennis Zickefoose
2010-03-18 06:22:28
+9
A:
My favourite thing not to put into a STL container is an std::auto_ptr... very bad things happen. .. mostly unexpected loss of objects I think.
In general anything that is not copyable can't go into a container - you'll get compile errors. Something with abnormal copy semantics (like auto_ptr) should not go in a container (but you probably wont get any compiler errors). As the container is free to create various temporary copies.
I think that without a "sane" default constructor and assignment operator you are also in for some pain.
Michael Anderson
2010-03-18 06:48:31
+2
A:
The class may not throw exceptions in the destructor ...well no class ever should throw in the destructor
smerlin
2010-03-18 07:09:07
A:
Depends on the container, for more information, section 23 of the Standard specifies the requirements for all containers and methods.
To be safe though, you should assume that the following are always required: Default Construction and Copy construction
Ramon Zarazua
2010-03-18 17:31:26