OK hold up. These are worries that are unfounded.
If you instantiate something like
list<myclass> mylist;
Then by default, the STL will use an allocator that is written and provided by the compiler writer working with ::operator new and ::operator delete (the free store). If you do something like this:
list<myclass*> myplist;
the allocator is still used, but you've added an extra layer of indirection. The allocator is only responsible for the myclass pointer and not the ultimate myclass object. So you get this headache as a result:
Having the STL containers carry raw pointers can make the STL useless, as you are now responsible for some memory management again. If you're concentrating on getting the easiest solution for yourself coded, then you are doing it wrong.
I doubt the object is entirely ignored as Substantiani says in his post, since the object is copied into a list node according to the manual page. To address the efficiency question, more importantly, a copy would seem necessary. If the list creates a copy of your object on the free store with the allocator, it can manage the object without worrying what exactly you passed it.
If the STL were stupid, this:
Code:
mylist.push_back( Dog( stuff ) );
would mean that a temporary object that is destroyed after the push_back call is a part of the list. So rather than be worried about efficiency that you can't or won't measure... it does at least work. If your concerns were actual concerns the STL would be even worse than it is.