#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).


    • assigned_to: nobody --> complement
    • status: open --> open-rejected
  • 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.

    • status: open-rejected --> closed-rejected
  • Jan Echternach
    Jan Echternach

    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?

  • Jan Echternach
    Jan Echternach

    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.