Console I/O in C++
"C originally left I/O to compiler implementers. One reason for this was to give implementers the freedom to design I/O functions that best fit the hardware requirements of the target computer." - C++ Primer Plus.
I want to know what exactly this means?
How would people benefit from this approach?
What disadvantage do i have today with c++ committee deciding over the i/o objects and classes...and not asking the implementers to do it?
By implementers the author means the people who make the operating system right?
Any help appreciated..
I want to know what exactly this means?
How would people benefit from this approach?
What disadvantage do i have today with c++ committee deciding over the i/o objects and classes...and not asking the implementers to do it?
By implementers the author means the people who make the operating system right?
Any help appreciated..
It was generally thought, before C++, that portable I/O simply cannot be done. Each compiler must implement it the way they see fit.
C's I/O streams are implementation-defined objects of struct type FILE, which maintain all the stream info (stream buffer, stream error flags, character width, parse state, I/O mode, stream position) in implementation-defined manner. C I/O functions use and return a pointer to this struct and aren't even allowed to access its members directly, let alone come up with their own. In addition C I/O functions access localization information (what is whitespace, what characters to use for decimal points, etc) from the locale, which is managed entirely by the OS.
In C, there is no way to write your own stream, no way to provide your own parsing or formatting rules, no way to provide your own localization routines.
C++ took C streams and locales and implemented them as an extensible library, so that the programmers have control over everything. That wasn't today, the C++ I/O library was created back in 1985 (although it went through a lot of improvements in 1998)
PS: while that sentence isn't particularly wrong, I recommend a better book
C's I/O streams are implementation-defined objects of struct type FILE, which maintain all the stream info (stream buffer, stream error flags, character width, parse state, I/O mode, stream position) in implementation-defined manner. C I/O functions use and return a pointer to this struct and aren't even allowed to access its members directly, let alone come up with their own. In addition C I/O functions access localization information (what is whitespace, what characters to use for decimal points, etc) from the locale, which is managed entirely by the OS.
In C, there is no way to write your own stream, no way to provide your own parsing or formatting rules, no way to provide your own localization routines.
C++ took C streams and locales and implemented them as an extensible library, so that the programmers have control over everything. That wasn't today, the C++ I/O library was created back in 1985 (although it went through a lot of improvements in 1998)
PS: while that sentence isn't particularly wrong, I recommend a better book
Last edited on
It means what is says.
In the early days of computers did not have an OS. This is in fact still the case for certain embedded applications, which are also often programmed in C. So since HW was all different I presume the idea was not to include any I/O functionality in the C standard (not all that illogical).
Nowadays it's the OS that hides the HW from the application.
No, the author means compiler implementers.
In the early days of computers did not have an OS. This is in fact still the case for certain embedded applications, which are also often programmed in C. So since HW was all different I presume the idea was not to include any I/O functionality in the C standard (not all that illogical).
Nowadays it's the OS that hides the HW from the application.
No, the author means compiler implementers.
Topic archived. No new replies allowed.