No. I am not "arguing quality of implementation issues". I'm actually explaining the issues--both what is standard and what you can expect. Obviously, you don't understand. Is it my fault? Or is it yours? Did I fail to explain it? Or are you ignorant?
[/Quote]The standard requires particular observable behaviours;[/Quote]
Except where it doesn't--"implementation defined".
Wrong. The standard demands specific performance and specific efficiency in many cases. Indeed, it is rare that it doesn't specify the required performance and efficiency characteristics.
it does not specifically mandate issues related to quality of implementation (eg performance, efficiency).
Wrong. The C and C++ standard actually mesh very well regarding this behavior. A conforming implementation of 'std::basic_string' may allow embedded nulls--and possibly embedded elements of every other domain value. However, a conforming implementation must terminate the data returned by 'std::basic_string::c_str()' with a 'charT()' which is obtained through the target type as associated with traits of either 'char' or 'wchar_t'. For either of these the result must be equivalent to the associated C standard string terminator where specified. In practice this means that 'std::basic_string' implementations may contain embedded terminators, regardless of value, but that invalidates the results of 'std::basic_string::c_str()'. (That the terminator is virtually always null is just a bonus.)
Since std::string's can contain embedded NULLs (i.e. more than one zero-valued byte) it is a fair call that implementation of a std::string will handle terminating bytes differently than one would expect assuming C-style strings.
It is your fault if your implementation gives you incorrect results from using the interface wrong. Such behavior doesn't invalidate the implementation or relate to the standard in any way. The standard can't force you to use the interface correctly.
Technically correct, but again flawed. The 'std::basic_string::c_str()' and 'std::basic_string::data()' methods are constant methods. The value returned by these methods must remain valid until a subsequent call to a non-constant method is made. So, such an implementation is logically flawed and mechanically unsound even if conforming in this way because the data returned would have to be cached and later released by the instance of 'std::basic_string'.
There is also nothing (except, again, quality of implementation concerns) stopping the c_str() method being implemented with allocation/deallication, copy, and set
Correct. If you mutate 'std::basic_string' in any way most of the previously reported state is considered invalid. Again, the 'std::basic_string::c_str()' and 'std::basic_string::data()' methods are defined as constant methods and are absolutely logically constant operations.
this is one reason why changing a std::string invalidates, as far as the standard is concerned, any value previously returned by c_str(), any iterators, etc etc.