I work with a VTK data type for my outputs. Since my data is becoming larger and larger, it\'s taking considerable time to write it in ASCII and that\'s what I have been doi
On all modern systems that I know of, the only difference between binary and text files is the treatment of newlines and end-of-file characters by the C runtime library. Specifically, on *nix systems, text and binary files behave exactly the same. On Windows, writing a '\n' to a text file causes a '\r' (CR) followed by a '\n' (LF) to be written to the actual file; reading a "\r\n" pair shows up as a single '\n'. Also on Windows, reading a '\x1A' (Ctrl-Z, EOF) from a text file signals the end-of-file condition. Binary files are read and written verbatim, with no conversion.
Reading your document, I notice that it specifies '\n' only (not "\r\n") at the end of the lines. That suggests that the correct approach is to read and write the header as a binary file, even on Windows.
As an irrelevant aside, some older systems (RSX-11 and VMS come to mind) had binary files that were wildly different, on disk, from text files. They also supported record-based and indexed files directly in the OS. However, they had modified versions of the open(), fopen() etc functions (and the equivalents in other languages) to handle the plethora of arguments that could be specified when opening a file. On such a system, you had to use the correct file mode every time.