Talk:C++ string handling

message: just curious if string class accepts null characters. I would assume it does.  —Preceding unsigned comment added by 66.102.196.17 (talk) 00:56, 28 February 2008 (UTC)
replies: text: I dug around in the gcc header files and found the following in basic_string.h: 1. String really contains _M_length + 1 characters: due to 21.3.4 must be kept null-terminated. But I am still not sure what that means fully. Guess I will have to test it. Kind of a lot to go through for a curiosity. I am starting to think it would have to be possible though, or how else would someone do binary file i/o.  —Preceding unsigned comment added by 66.102.196.44 (talk) 03:03, 7 March 2008 (UTC)

text: It appears to. It's not easy to add them, though, because string foo = "asdf\0asdf"; just sets foo to "asdf" because the null terminator means the string constructor never sees the second half of the string. But you can do str.push_back('\0') and the length will increase and you can put non-null characters after the null terminator. —Ben FrantzDale (talk) 03:19, 8 March 2008 (UTC)

text: No need to check anything or experiment. std::string does support \0. It's in the standard. Of course, C strings still do not. 194.237.142.20 (talk) 15:05, 19 March 2010 (UTC)

text: Also string.assign("asdf\0asdf", 9) will make the string contain the null byte.Spitzak (talk) 19:49, 19 March 2010 (UTC)
thread_title:  null characters 

message: "when two c-strings are compared, it is implementation defined as to whether the contents or addresses are compared."
Huh? No, it's not implementation defined, it's definitely an address compare. The only freedom is that in:
  char *p1 = "hello";
  char *p2 = "hello";
... the compiler is allowed to share the two, i.e. p1==p2 *maybe*.
— Preceding unsigned comment added by 204.15.64.190 (talk) 22:48, 3 December 2008‎
:The compiler will never been allowed to do so unless p1 and p2 are totally not touched in the later code. Otherwise changing p2 will inevitably change the content of p1 at the same time. --LunarShaddowღIvy (talk) 12:12, 2 November 2013 (UTC)
thread_title:  incorrect 

message: Hi, I am currently considering renaming this article to conform to a common convention for C++ Standard Library components. The full discussion can be found here. decltype 09:47, 6 March 2009 (UTC)
thread_title:  Renaming this article to follow a consistent convention 

message: Most operations are described as handling bytes.
Nonetheless, from my understanding, strings can also possibly be made from char16_t and char32_t.
So we might write:
    * string::at – Accesses specified code unit with bounds checking.
    * string::operator[] – Accesses specified code unit
    * string::front – Accesses the first code unit
    * string::back – Accesses the last code unit
    * string::data – Accesses the underlying array
— Preceding unsigned comment added by 86.75.160.141 (talk) 20:19, 5 November 2012 (UTC)
replies: text: The object is then a "std_string<T>" and not what C++ headers call "string". I think it is enormously clearer to describe byte strings first and then point out that the template can be reused for other objects.Spitzak (talk) 23:08, 5 November 2012 (UTC)
replies: text: Now we got u16string and u32string in C++11, cheers. --LunarShaddowღIvy (talk) 12:14, 2 November 2013 (UTC)
thread_title:  bytes, char16_t and char32_t 

message: The fact that std::string cannot use copy-on-write, according to the standard, is interesting. But I am having a hard time finding references and details.
Though I can find many statements that it is not allowed, I cannot find a pointer to a document saying "the C++ standard was changed to disallow cow strings", including perhaps a date and/or C++ standard version number.
Also I clearly remember learning about this as a difference and big argument between users of MSVC and G++. One of them used COW and the other didn't. I thought it was G++ that did not use COW, but looking at papers it appears this may be incorrect, there are many references to G++ being "late in implementing conforming std::string without COW". I cannot find anything about MSVC++, but I find it believable that I had this backwards and it was MSVC that was slower. Anybody know the details?Spitzak (talk) 02:58, 7 January 2016 (UTC)
thread_title:  COW history 

message: This article would benefit from some text mentioning the new (C++14?) string literals that use a normal string literal suffixed with an "s", e.g.
    using namespace std::literals;
    auto mystring = "mystring"s;  — Preceding unsigned comment added by Raybellis (talk • contribs) 10:33, 15 January 2016 (UTC)
thread_title:  string literals