STLport 5.2: Revert stringstream::str change
Brought to you by:
complement
Menu
▾
▴
#112 STLport 5.2: Revert stringstream::str change
The behaviour of basic_stringbuf::str(const basic_string &) has changed in STLport 5.2 and is now different from previous STLport versions and other compilers like gcc and Visual C++.
Even though I agree that the new behaviour is more useful, it's different from what other commonly used C++ compilers do. This makes the new behaviour useless in portable code. I suggest reverting this change. The patch should do that unless I've missed something (the original changeset is quite large and includes other large changes).
Patch incorrect. My code in STLport incorrect too. Current draft say a bit more clear about this problem then std 2003, I will follow draft's treatment:
void str(const basic_string<charT,traits,Allocator>& s);
2 Effects: Copies the content of s into the basic_stringbuf underlying character sequence and initializes
the input and output sequences according to mode.
3 Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character
and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::in is true, pptr()
== pbase() + s.data() holds, otherwise pptr() == pbase() is true. If mode & ios_base::in is
true, eback() points to the first underlying character, and both gptr() == eback() and egptr() ==
eback() + s.size() hold.
See [master 5d9177f]. Wanted: backport to STLport-5.2.
To follow the current wording of the C++0x draft, you would also need to remove the "if (_M_mode & (ios_base::app | ios_base::ate))" case. But I think that there's an error in the C++0x draft.
I have filed a comment suggesting to replace the "mode & ios_base::in" test with one that tests "mode & (ios_base::ate | ios_base::app)", possibly leaving the "ios_base::app but not ios_base::ate" case unspecified (as there's currently no agreement among C++ implementations in this case).
I won't make a backport of your change on the master branch to STLport-5.2 as I'm expecting the C++0x draft to change such that it will require a behaviour like the one of STLport-5.1, or of STLport-5.2 with the STLport-5.2.1-revert-stringstream-init patch.
Well, I try to follow sense in implementation, at least in case when standard (or draft) not clear. Plauger of cause is authority figure. But, from other side, I don't want to play lemming's role. Let's wait (motives, directives, explanations, errata, new treatment ... ). May be you ask WG21 about incomplete/contraversal words in draft?
C++0x is currently in some kind of a public review phase. The comment I've filed was to Anthony Williams of the BSI, and it has already been added to their list. However, I don't know when the comments on the list will be discussed and a response can be expected. See http://www.justsoftwaresolutions.co.uk/cplusplus/c++0x-now-at-fcd.html for more information.