Re: a further question

[Dietmar Kuehl <dietmar_kuehl at yahoo dot com>]

Hi Graziano,

I didn't see your question before (did you mail me directly or ask on Stackoverflow)? 

Anyway:
1. Your program has undefined behavior: you cannot read from and write to the same file stream without a seek between reading and writing or between writing abd reading. The seek can be to the sane position but it is required! Especially high performance implementations will depend on the seek unless the encoding requires writing a sequence to finish a shift state.
2. Conceptually, the input and the output sequence of s file stream share one position. Other stream buffer may not share the positions, e.g., I think the string streams do nit share a position.
3. The difference between binary and non-binary I/O only affects Windows in practice: there the text line end sequence "\r\n" gets replaced by a "\n" in text mode but not in binary mode.

Dietmar

> On 27 Nov 2013, at 10:23, Graziano Servizi <Graziano.Servizi@bo.infn.it> wrote:
> 
> Hi,
> 
> I'm Graziano Servizi.
> 
> I wrote to you five days ago (by the way I didn't yet receice any answer) and I have one more question, about the C++ I/O library in the
> 4.8.2 version of the compiler.
> 
> In an I/O stream (declared as an instance of fstream and opened for
> both INPUT and OUTPUT accesses) the so called "get" and "put" areas are driven through TWO distinct indicators, independent from each other, OR
> aren't?
> 
> In the following short code
> 
> // code begins
> # include <iostream>
> # include <fstream>
> using namespace std;
> 
> 
> int main(  )
> {
>  fstream f("file", ios::in | ios :: out | ios :: app | ios :: binary);
>  char z = 'Z', c;
>  f . get(c);
>  cout << c << endl;
>  f . put(z);
>  f . seekp(4);
>  f . get(c);
>  cout << c << endl;
>  f . put(z);
> }
> 
> // code ends
> 
> where "file" is a disk file containing just
> the 26 lowercase letters and a single trailing newline (file size = 27 bytes), I got the following standard output
> a
> e
> while the "file" got two capital Z's appended.
> I would expect that, since the stream is opened in ios::app mode for
> writing, hence the f.seekp(4) would correctly be IGNORED.
> 
> But why the second f.get(c) yields c == e ?
> Nobody moved (I suppose) the indicator of the "get" area (or not?).
> I expected 'b' as the value got for c in the second call of the get function... where am I wrong? It appears that seekp has moved the
> get indicator as it would be done if seekg would be called...
> 
> In addition I NEVER have understood the usefulness of the ios :: binary
> openmode flag: I always (ALWAYS, in my tests, I mean) got the SAME behaviour regardless of its presence or absence...included the present
> case.
> 
> Sorry for my (may be) pedantic questions, but YOU said in the web pages
> that any testing of the compiler is welcome...
> 
>                                 G. Servizi
>                                 Associate Professor
>                                 of Mathematical Physics
>                                 University of Bologna
> 
> 
>