On Sat, 9 Aug 2008 10:39:30 +0200, "Giovanni Dicanio"
<gdicanio@_NOSPAM_email_DOT_it> wrote:
What about using std::vector< shared_ptr< string > > instead of std::vector<
string > ?
This should make the reallocation and deep-copy problems less important,
correct?
It'll be the same then as for CString, i.e. depending on the
implementation, shared_ptr will use InterlockedXXX operations at best and
CRITICAL_SECTION operations at worst to make copying thread-safe. If the
goal is to be faster than map, I wouldn't go that way, because it would be
trading ease of implementation for a less than maximal speed increase.
Also, depending on the implementation of shared_ptr, it might also
sacrifice much of the memory usage improvement. That is, if shared_ptr
dynamically allocates an int to represent the reference count, the
shared_ptr overhead is similar to map node overhead and might even be worse
fragmentation-wise compared to a map that uses a pool allocator. I really
would try to stick to storing simple types in a vector for a problem like
this.
short string optimization is applied. Using a shared_ptr such as the one