I have the following string:
index 0 1 2 3 4 5 6 7
std::string myString with the content of "\xff\xff\xff\x00\xff\x0d\x0a\xf5"
When I’m refering to myString[3], I get the expected ‘\x00’ value.
But when I’m referring to myString[5], I get two values “\x0d\x0a” instead of just ‘\x0d’.
Even more interesting is the myString[6] value, which is the ‘\xf5’. This time it’s like the \x0d didn’t exist and the correct position was referenced.
My question would be: what is so special about the \x0d character in a std:string object? How come it is skipped when indexing? It’s like counting this way:
index 0 1 2 3 4 5 5 6
std::string myString = "\xff\xff\xff\x00\xff\x0d\x0a\xf5"
As a comment, the ‘\x0d’ character is the 13th ASCII character “carriage return” and ‘\x0a’ is the line feed character.
UPDATE: Can it be that std::string considers “\x0d\x0a” as a single character and thus occupies only one position in the string? Is this ‘\x0d’ a “mystery” character with regard to std::string?
ADDITIONAL INFO: http://en.wikipedia.org/wiki/Newline
Are you sure this is happening with
std::string?std::string::operator[]returns aconst char &, so how can it be returning two chars ('\x0d'and'\x0a')?That said,
"\x0d\x0a"is usually used for line endings under Windows, whereas only'\x0a'is used under Linux, so conversion of the former to the latter is relatively common under Windows — for example, I’m thinking of the behaviour offopenwhen called with"wt". I would guess something similar is happening to you.Edit: Based on your comments on the original question, I think I can guess what’s going on.
I believe your string doesn’t really contain what you think it contains. You’re being misled because the mechanism you’re using to output the string to a file (probably
ofstream?) is performing end-of-line translation. This means that a'\n'(the Unix end-of-line code) is being translated to'\r\n'(the Windows end-of-line code). The purpose of end-of-line translation is to make code more portable between operating systems. You can inhibit it by opening the file in binary mode; forofstream, this is done by specifying theios_base::binaryflag when you open the file, but this flag is not set by default.(See this Wikipedia article for more information on end-of-line markers on different operating systems.)
This is what I believe is going on. Your string actually contains
You’re outputting it something like this:
Because of the end-of-line translation expalined above, the
'\x0a'inmyString[5]is being output as'\x0d\x0a', and that’s what is confusing you.