Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The problem is that ostream does not clean up the stream buffer in its destructor:</p> <p><a href="http://www.cplusplus.com/reference/iostream/ostream/~ostream/" rel="nofollow">http://www.cplusplus.com/reference/iostream/ostream/~ostream/</a></p> <blockquote> <p>[...] Note that it does not destroy nor performs any operations on the associated streambuf object.</p> </blockquote> <p>So you have to clean up the streambuf somewhere else. The easiest thing is to make your stampbuf object a member variable of stampstream - then its destructor gets called automatically when your stampstream is destructed.</p> <p>The constructor of the base class ostream gets called before member variables get constructed, so the constructor of ostream ends up looking at an unconstructed stampbuf object if you pass the stampbuf object as a parameter to the ostream constructor. So instead do not pass the stream buffer to the constructor, set it inside the constructor, after the stampbuf has been construct using rdbuf:</p> <p><a href="http://www.cplusplus.com/reference/iostream/ios/rdbuf/" rel="nofollow">http://www.cplusplus.com/reference/iostream/ios/rdbuf/</a></p> <p>This presents the problem that your stampbuf gets destructed before the base class does, so the destructor of ostream is going to be looking at a deconstructed stampbuf. That is normally unacceptable, but since the page for ~ostream above guarantees that ~ostream does not do anything with the stream buffer, it is fine in this case. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. CO@BoPersson Interesting. Is it guaranteed by the standard that ostream::ostream does nothing with the passed in buffer, or is this just something that happens to work on some (or even all current) implementations? [This page](http://www.cplusplus.com/reference/iostream/ostream/ostream/) does not specify such a guarantee, but of course that doesn't prove anything.
      singulars
    2. COThe standard would say that the constructor does not touch the buffer precisely in order to allow the technique that you are suggesting. The same reason it specifies that the destructor does not touch the buffer (if cplusplus.com can be trusted). If you compile on another std library or even the next minor revision of your current standard library, it would be conforming for that upgrade to crash your program if there is no language in the standard to allow passing in an unconstructed buffer. Is there any advantage to outweigh the risk here?
      singulars
    3. COI bet the standard does not require the passed-in buffer to be not constructed, so I don't know how it is relevant that fstream and stringstream have to pass in their buffers? For example if you use multiple inheritance and privately derive from the buffer you can make the buffer be constructed first, or you could call new and get the buffer constructed first that way. There is no reason that I can see that std::fstream would need to pass in an unconstructed buffer.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload