Why isn't this a Contradiction? i.e What did I understand wrong?

[manasij7479]

The book "Thinking in C++(V2)" gives something like the following example:

int main() 
{
    ifstream in("a.cpp");
    while(in.get(*cout.rdbuf()))
        in.ignore();
    return 0;
}

It compiles and works correctly.

But my <streambuf> file says:

* -# Stream buffers can impose various constraints on the sequences
* they control. Some constraints are:
* - The controlled input sequence can be not readable.
* - The controlled output sequence can be not writable. <------------- [THIS is the line I'm talking about]
* - The controlled sequences can be associated with the contents of
* other representations for character sequences, such as external
* files.
* - The controlled sequences can support operations @e directly to or
* from associated sequences.
* - The controlled sequences can impose limitations on how the
* program can read characters from a sequence, write characters to
* a sequence, put characters back into an input sequence, or alter
* the stream position.
* .

But the code compiles and runs as expected.
Isn't cout's streambuf being written on in the example ?
Or..more likely...what punchline am I missing ?

[Elkvis]

* -# Stream buffers can impose various constraints on the sequences
* they control. Some constraints are:
* - The controlled input sequence can be not readable.
* - The controlled output sequence can be not writable. <------------- [THIS is the line I'm talking about]
* - The controlled sequences can be associated with the contents of
* other representations for character sequences, such as external
* files.
* - The controlled sequences can support operations @e directly to or
* from associated sequences.
* - The controlled sequences can impose limitations on how the
* program can read characters from a sequence, write characters to
* a sequence, put characters back into an input sequence, or alter
* the stream position.
* .

I think the truly operative phrase here is "Stream buffers can impose various constraints on the sequences they control."

it seems to me that the ones they list are a few of the options available, and that not all of them are present in every instance of a streambuf.

[grumpy]

Elkvis nailed it.

The word "can" means "able to" which, because it is not mandatory, is distinct from the meaning of "shall" which means "has to".

In some legal contracts, the word "shall" is used to state essential (non-negotiable) requirements, whereas "can" is used to state that something is desirable (nice to have, but negotiable)

[manasij7479]

....and that not all of them are present in every instance of a streambuf.....

.....whereas "can" is used to state that something is desirable (nice to have, but negotiable)....

Wouldn't that make using streambuf `s(and its children) very non portable ?
..if .. say the runtime library stops allowing something which a piece of code relied upon...
or if the code is compiled with a different compiler ?

[grumpy]

It can affect portability, yes.

The trick is to understand what can be relied on and what cannot. Using multiple compilers (and running your tests with each) can help with that.

Bear in mind that the quoted information is not from the standard. It is presumably a view of one library vendor about some qualities that may be acceptable.