The "passive" vs. "active" criticism is highly subjective. In general, I prefer a passive style, but not as an absolute rule. In English, there is nothing syntactically wrong with an active style and if that is what comes naturally to you, you might as well stick with it. Good quality writing done in an active voice is much nicer to read than bad quality writing in a passive voice. IMO many people are clearer when they use the active voice, and easily slide into incomprehensibility when they try to use the passive voice. WRT to technical documentation, I would rather read something that makes obvious sense in a "clunky" active voice rather than something ambiguous in a "less clunky" passive voice.
Is very clear, reads fine, and is in an active voice. If it ain't broke, don't fix it. I can almost promise you will go from clear to confusing, and concise to long-winded.
Streams natively work with standard data types, but streams also let you design your own classes so that you can use the same I/O system.
A few corrections I would make:
Loose the red bits.
The streams we are talking about here, are designed to fit almost any data-handling purpose imaginable.
This sentence is missing a verb.
The type of the character normal characters (char) or wide characters (wchar_t).
Understanding is mis-spelled, and the bit in bold needs fixing (maybe "the elements the design contains"?). I'd actually re-think or just remove the whole sentence.
Once you are familiar with element of the design contains and how to apply those concepts to design a robust I/O system for your software, an undestanding of what belongs where in the hierarchy will come naturally.
"other than as a character array."
You have to get the input characters into a recognizable data-type for it to be of any use other than a character array.
should be both using
Apart from that, it allows you almost limitless freedom to manipulate those streams using both Object Oriented interfaces and working directly on character buffers when necessary.
How about: "the stream is initialized using the appropriate type (...) and suitable modes set".
First, the stream is initialized with the appropriate type of values (like a std::string for a stringstream and the filename for an fstream) and suitable modes (like
Once you've what?
Once you’ve at the right location in the stream,
"to do for" should be "to do when". Subjectively, I'd loose the "often".
Handling Errors gracefully is often an important thing to do for building a robust system.
Lose the "to" at the end. Maybe "are generally when" might be better as "generally occur when".
The ‘errors’ or ‘signals’(eg: reaching the end of the file) in this case are generally when a stream encounters something it didn’t expect to.
"it" should be "this". lose "the".
The status of the stream can be obtained from the individual bits of the respective iostate object, but using the bool functions provided for that purpose makes it easier.
The good(), bad(), fail() and eof() functions provide information about the state and the clear() is used to reset the stream and clear the error.
Bold bit should be "exactly how" or just "the exact way".
They allow you a lot of control about the exact way how you want to read a value from the stream into the given variable
Should be "an approach which when combined". Lose "these" and "that". Probably then commas after which and streams to isolate the phrase more clearly. Subjectively, I'd replace "excellent" with "nice" or "clean".
an approach when combined with these streams that can lead to excellent, straightforward designs.
Not a grammatical point, but a logical one: the comparison is contrived since you are operating on a stringstream. You cannot operate on a C++ stringstream without these facilities, in any number of lines. But if the stringstream is supposed to represent a method or a data source, and if by "without such facilities" you mean "using vanilla C", the task is equally simple, 5-10 lines at most. If you mean something completely else, such as "using python" or "using a hatbox", you are just being silly.
This seemingly simple task would have taken at least 30 lines of code or more without such facilities.