String class vs dynamically allocated array

String class should be preferred over dynamically allocated array due to following limitations of dynamically allocated arrays:
  1. Whenever user calls new operator, it becomes her/his responsibility to delete it as well to avoid memory leaks. 
  2.  User must ensure that correct form of delete is called. For a single element allocation delete should be used and  for an array allocation delete[] should be used. If wrong version is used it may result into undefined behavior. 
  3. User has to make sure that there is single delete for one allocation. 
string class provides function c_str() for backward compatibility with C API's that expects char* as argument. Hence there is no reason for not to use string in place of array of char.

But, in Multi-threaded environment, there can be performance issues with string class because of reference counting(wiki link) optimization. Basically, reference counting optimization can eliminate unnecessary memory allocations and copying of characters. But in multi-threaded environment, time saved by avoiding unnecessary allocations and copying is dwarfed by time spent on behind the scenes for concurrency control.

Hence in multi threaded environment, user has following options :
  1. Check for library implementation of string class if it allows you to disable reference counting optimization.
  2. check for alternative implementation of string class that do not have reference-counting optimization that can be checked in copy constructor of class. 
  3. consider using vector<char> instead of string.  String class' member functions will not be available but most of the functionality is available through STL algorithms.    
Option 1 & 2 are not even solutions that are just checking string class or library implementation. Option 3 is a real solution.

Hope you’ve found this post useful. Let us know what you think in the comments.

References : Effective STL by Scott Meyer


No comments:

Post a Comment

Thanks for your valuable inputs/feedbacks. :-)