Quote:Original post by Telastyn

Quote:Original post by nprz
I wouldn't rely on that. you are most likely going out of bounds.
cout << x.at(0) << "\n";

would changing it to that cause it to exit?

a vector might treat an int differently because storing a bunch of pointers to int would be pretty wasteful. just because it doesn't crash doesn't mean it is correct :)

Ah, yes, the change does blow it up.

It was just confusing, since I tried with ints to see if it was a problem with string use or with vector use. Since the ints worked, I spent a bunch of time trying to figure out what was wrong with elementary string use...

I have made that mistake before as well. I usually use the at function with vectors since I'd rather have it crash and be able to trace it than overwrite something it isn't supposed and keep running (although possibly abnormally).

reserve() just makes the capacity at least that size, so if you do a lot of insert it will not have to resize and copy data over and over again. resize fills the data in the vector.

Quote:Original post by Telastyn
It was just confusing, since I tried with ints to see if it was a problem with string use or with vector use. Since the ints worked, I spent a bunch of time trying to figure out what was wrong with elementary string use...

Yes it would work because ints are POD-types and std::basic_string is not, since std::vector separates allocation/deallocation and construction/destruction for efficiency, std::vector::reserve deals with allocation only.

For non-POD types constructor needs to been invoked on the the uninitialized memory as not only does it initialize it, typically special set-up code is run but you don't do this yourself as std::vector handles it when you do say push_back/front, this is what you can logically think is going on:

#include <cstddef>#include <new>#include <string>using std::string;//....std::size_t N = ...;string* v = static_cast<string*>(::operator new(sizeof(std::string) * N)); //allocates only::new(&v[0]) string("foo"); // placement new, constructs 1 element only// ... you can now use element 1.v[0].~string(); // destroys 1 element only::operator delete(v); // deallocates only

You don't need to invoke constructors for POD-types, and they don't have destructors (or they are trivial destructors) so you dont invoke them (or you don't need to in the case of trivial destructors).

I guess i've come into this abit to late [grin].

[Edited by - snk_kid on June 11, 2005 6:08:38 PM]