14

does std::string store data differently than a char* on either stack or heap or is it just derived from char* into a class?

Elofin
  • 141
  • 1
  • 3

3 Answers3

13

char*

  • Is the size of one pointer for your CPU architecture.
  • May be a value returned from malloc or calloc or new or new[].
    • If so, must be passed to free or delete or delete[] when you're done.
    • If so, the characters are stored on the heap.
  • May result from "decomposition" of a char[ N ] (constant N) array or string literal.
    • Generically, no way to tell if a char* argument points to stack, heap, or global space.
  • Is not a class type. It participates in expressions but has no member functions.
  • Nevertheless implements the RandomAccessIterator interface for use with <algorithm> and such.

std::string

  • Is the size of several pointers, often three.
  • Constructs itself when created: no need for new or delete.
    • Owns a copy of the string, if the string may be altered.
    • Can copy this string from a char*.
    • By default, internally uses new[] much as you would to obtain a char*.
  • Provides for implicit conversion which makes transparent the construction from a char* or literal.
  • Is a class type. Defines other operators for expressions such as catenation.
    • Defines c_str() which returns a char* for temporary use.
  • Implements std::string::iterator type with begin() and end().
    • string::iterator is flexible: an implementation may make it a range-checked super-safe debugging helper or simply a super-efficient char* at the flip of a switch.
Potatoswatter
  • 126,977
  • 21
  • 238
  • 404
5

If you mean, does it store contiguously, then the answer is that it's not required but all known (to me, anyway) implementations do so. This is most likely to support the c_str() and data() member requirements, which is to return a contiguous string (null-terminated in the case of c_str())

As far as where the memory is stored, it's usually on the heap. But some implementations employ the "Short String Optimization", whereby short string contents are stored within a small internal buffer. So, in the case that the string object is on the stack, it's possible that the stored contents are also on the stack. But this should make no difference to how you use it, since one the object is destroyed, the memory storing the string data is invalidated in either case.

(btw, here's an article on a similar technique applied generally, which explains the optimization.)

dcw
  • 3,371
  • 2
  • 20
  • 30
  • 6
    The C++0x committee found that all current implementations store contiguously, so they decided to firm up the language and make it a requirement. Sorry I don't have a reference to back it up. – Mark Ransom Apr 20 '10 at 03:50
  • 1
    @Mark Ransom: Good point, although that'll only apply in C++0x+; C++98/03 does not have that requirement – dcw Apr 20 '10 at 03:56
  • 3
    @Mark: Here is the reference you were looking for: http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/#comment-483 and http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530 – Carl Apr 20 '10 at 04:15
2

These solve different problems. char* (or char const*) points to a C style string which isn't necessarily owned by the one storing the char* pointer. In C, because of the lack of a string type, necessarily you often use char* as "the string type".

std::string owns the string data it points to. So if you need to store a string somewhere in your class, chances are good you want to use std::string or your librarie's string class instead of char*.

On contiguity of the storage of std::string, other people already answered.

Johannes Schaub - litb
  • 466,055
  • 116
  • 851
  • 1,175