How to write ASCII and BINARY data to the same file at the same time

Question

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 doing so far.

I need to change that into binary format but the problem is the file has some headers (see http://www.vtk.org/VTK/img/file-formats.pdf) that need to be written in ASCII even for binary files.

Now I don't have enough experience with binary formats and my first try was to open two streams via

ofstream asciiWriter(file_name.c_str());
ofstream binWriter(file_name.c_str(), ios::app | ios::binary);

problem is the output seems to be disorganized and asciiWriter and binWriter are not outputting in the correct order and so I cannot post-process my file in ParaView. One thing I tried was to use asciiWriter.flush() and binWriter.flush() whenever I'm done with header/data writing but that does not help either.

What should I do?

PS: I do not want to use the VTK package itself ... its HUGE and adds to my code dependency!

Answer 1

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.