Talk:cpp/string/basic string/size

#include using namespace std; int main { string s = "ab\0\0"; cout << s.size << '\n'; return 0; }
 * 1) include

This prints 2 not 4

Shouldn't this phenomenon be explicitly mentioned, that everything after a \0 is stripped?
 * it is not stripped by, it is stripped by the constructor (overload 5 in std. I suppose it makes sense to have a note there (added) --Cubbi (talk) 11:22, 21 July 2016 (PDT)

Complexity unspecified in C++98/03
I added that the complexity was specified only since C++11. Did I miss any DR that retroactively applied to C++98/03, or other guarantees in the standard? 85.18.102.222 06:12, 2 August 2017 (PDT)
 * Core language defects generally apply to prior standards. This is a library though:
 * Library defects that fix unimplementable earlier specifications apply to that unimplementable specification (naturally).
 * Defects that change observable behavior sometimes apply retroactively and sometimes don't: we have to look at the actual standard library implementations to see what they did (there are only 3, not hard to do).
 * Defects that reaffirm what every library already did.. I don't really see the benefit of revboxing but I wouldn't fight against it or for it unless enough of the admins decide on a policy. There's an upcoming LWG 3004 asking to specify that std is also a constant time operation. Will it make sense to say it could be non-constant prior to C++20 when in fact it never was?
 * All that said, string::size complexity spec was not introduced as a defect report, it was introduced through a paper n2923 and that discussion does not apply to your edit. --Cubbi (talk) 06:52, 2 August 2017 (PDT)
 * Defect or not, this basically confirms the status quo. Unless there were actual implementations having a non-constant-time size, I would prefer to not revbox it, and instead add a separate note saying that the standard technically didn't specify the complexity pre-C++11. T. Canens (talk) 11:57, 3 August 2017 (PDT)