|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| STL and the map template |
|
X-G
Member #856
December 2000
 |
Yeah, if you're spending time trying to make your stuff faster by switching [x] for table.insert, you really suck at optimizing. -- |
|
Kibiz0r
Member #6,203
September 2005
 |
Quote: Hm? I was always under the impression that it would go into a container just fine. The copy constructor transfers ownership of the pointer'd object, which will break a lot of container functions. --- |
|
ImLeftFooted
Member #3,935
October 2003
 |
Quote: The copy constructor transfers ownership of the pointer'd object, which will break a lot of container functions. Which functions break? |
|
Kibiz0r
Member #6,203
September 2005
|
Perhaps "a lot" was too brash. Really, just some of the <algorithm> functions. Only ones I'm sure of are the copy() functions, though I suspect fill() uses a copy constructor. According to http://www.awprofessional.com/articles/article.asp?p=30642&seqNum=9&rl=1, a container of auto_ptrs ought to give you a compiler error. I wouldn't know, I pretty much only use boost::shared_ptr. --- |
|
ImLeftFooted
Member #3,935
October 2003
|
Quote: Only ones I'm sure of are the copy() functions, though I suspect fill() uses a copy constructor. Pretty much every container type uses the copy constructor. What makes them "fail" is that the 'copied from' elements go to NULL. Which isn't really failing, it just means you have to know what you're doing. The Linked Article said: In fact, the standard defines auto_ptr in such a way that it's illegal to instantiate an STL container with an auto_ptr element type; such usage should produce a compile-time error (and probably a cryptic one, at that). However, many current implementations lag behind the standard. This is the interesting point here. Lets assume 'element type' means the type in vector<type>. Okay, I did some research. Apparently his not the only guy claiming this. Heres an article on auto_ptr. The Article said: So the standards committee bent over backwards to do everything it could to help you out: The Standard auto_ptr was deliberately and specifically designed to break if you try to use it with the standard containers (or, at least, to break with most natural implementations of the standard library). To do this, the committee used a trick: auto_ptr's copy constructor and copy assignment operator take references to non-const to the right-hand-side object. The standard containers' single-element insert() functions take a reference to const, and hence won't work with auto_ptrs. So looks like the standards committee doesn't like auto_ptr in container types. Thats a shame. I have to say I disagree with them. |
|
|
1
2
|
