std::vector<char> vs. std::string

This is a discussion on std::vector<char> vs. std::string within the C++ Programming forums, part of the General Programming Boards category; I'm in a situation where I could save copying some memory if I could use a std::vector. The question is, ...

  1. #1
    Registered User
    Join Date
    Oct 2005
    Posts
    88

    std::vector<char> vs. std::string

    I'm in a situation where I could save copying some memory if I could use a std::vector. The question is, what's the difference between, for instance, a std::vector<char> and a std::string? As far as time/space efficiency, is there any?

  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,738
    Vector, I surmise, is an array implementation built for efficiency and safety as opposed to the C variety. It's not an incredibly far-fetched idea to use a vector of chars, because that is sorta what happens in C, but there is a heuristic you can use based on the fact that std::string has lots of member functions to do string work.

    Almost always use a string unless you have a very good reason for not doing so. Like, using a vector<char> for your grades isn't such a terrible idea: a letter grade isn't really much of a string and you probably won't need string functions.

    As for a performance boost... well, even if there was one, not everything in programming concerns performance.

  3. #3
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    The major differences:

    1. std::string has a huge number of string-related functions which make it easy to manipulate strings.

    2. std::vector, on the other hand, is guaranteed to be contiguous in memory -- that is, &data[x + 1] = &data[x] + sizeof(data[x]). std::string has NO guarantee that it is contiguous in memory.

    So, for example, say you're using an API call that fills a character buffer. You'd need to use the vector, not the string.
    Last edited by Cat; 12-14-2006 at 09:12 PM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    > As far as time/space efficiency, is there any?

    There are a few, I reckon. But they only become important when you try to use a vector as a string, or a string as a vector.

    Another issue other than the ones already provided concerns how C++ reserves memory for both vector and string. A string doesn't necessarily retain its capacity once assigned while a vector must (given of course the assignment doesn't go over the current capacity). I'm not sure why strings behave this way, but the standard specifies this. It's important to retain the thought.

    But it all boils down to not trying to use one type as the other. Meanwhile, both string and vector constructors allow for an easy and quick construction of a vector<char> from a string and the reverse.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Vectors are extremely rigid in their implementation. They have to be a continuous block of memory, which means that all implementations look more or less the same.

    Strings are far, far more flexible. They give fewer guarantees but potentially better performance.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    aoeuhtns
    Join Date
    Jul 2005
    Posts
    581
    One example of a difference is the std::string library generally used with gcc, which uses copy-on-write.
    There are 10 types of people in this world, those who cringed when reading the beginning of this sentence and those who salivated to how superior they are for understanding something as simple as binary.

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,422
    Quote Originally Posted by Rashakil Fol
    One example of a difference is the std::string library generally used with gcc, which uses copy-on-write.
    One trade-off of such implementations is that they are not thread safe (or, at least, it is fairly difficult to ensure thread safety in situations where strings are shared between threads).

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    GNU's is indeed not fully threadsafe.

    The language currently does not quite allow for a fully threadsafe CoW std::string implementation. The sad thing is that I think they expected it would be possible, and it only turned out it wasn't after C++ was standardized.


    However, another very popular std::string implementation technique is the small string buffer. Basically, you make a buffer of, say, 16 characters in the std::string object itself. Only if the string grows longer than that do you have to allocate dynamically.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    Is it because of a possible copy-on-write implementation that the standard doesn't require std::string to retain capacity() over assignments?
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    That would probably be one of the reasons, yeah. But generally all such restrictions limit the flexibility of the implementation.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #11
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    *nods* I always wondered about that one. Thanks.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #12
    Registered User
    Join Date
    Jun 2005
    Posts
    6,422
    People may wish to look at this article by Herb Sutter, on this and similar issues. Essentially the message is that various types of optimisations that work well in a single-threaded scenario become either costly or incorrect in a multithreaded scenario.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 13
    Last Post: 12-14-2007, 02:34 PM
  2. std::string: Has my compiler gone nuts??
    By Andruu75 in forum C++ Programming
    Replies: 9
    Last Post: 09-28-2007, 04:02 AM
  3. Improving my code
    By rwmarsh in forum C++ Programming
    Replies: 14
    Last Post: 07-08-2006, 11:18 AM
  4. Debugging help
    By cuddlez.ini in forum C++ Programming
    Replies: 3
    Last Post: 10-24-2004, 07:08 PM
  5. DLL and std::string woes!
    By Magos in forum C++ Programming
    Replies: 7
    Last Post: 09-08-2004, 12:34 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21