Unformatted I/O

Programming Language & Its Applications — Virtual Functions and File Handling, NEC licence examination syllabus (Nepal Engineering Council).

Unformatted I/O

Moving characters and bytes with no conversion — get, put, getline, read, write.

🌍 Where this lives: unformatted I/O is what you use when the bytes matter more than their meaning. Copying a JPEG, computing a file's checksum, reading a network packet header, implementing a text editor that must preserve every space and tab exactly — none of those can afford >>, because >> silently eats whitespace and converts. It is also how you read a password without echoing it, and how wc and md5sum work. Search "why getline is better than cin >> for strings" — the answer is the first thing that goes wrong when a user types a two-word name.

Formatted versus unformatted

FORMATTED ( << and >> ) · CONVERTS between text and internal types "87.5" <-> double 87.5 · >> SKIPS leading whitespace, then STOPS at whitespace · affected by width, precision, fill and all the flags · returns the stream (chainable) UNFORMATTED ( get, put, getline, read, write, ignore, peek ) · NO conversion — characters and bytes move verbatim · whitespace is ordinary data · unaffected by formatting flags · returns the stream, or the character, depending on which WHY >> IS WRONG FOR TEXT: std::string name; std::cin >> name; /* user types: Ram Bahadur */ → name == "Ram" the rest stays in the buffer std::getline(std::cin, name); → name == "Ram Bahadur" ✔ That one difference is the most common beginner bug in C++ console programs, and the reason every input-heavy program uses getline.

The character functions

int get(); read ONE char, return it as int, or EOF (−1) at end istream& get(char &c); read into c; the stream converts to false at end istream& get(char *buf, int n); up to n−1 chars, STOPS at '\n' and LEAVES it istream& get(char *buf, int n, char d); custom delimiter istream& getline(char *buf, int n); like get, but CONSUMES the '\n' istream& putback(char c); push a char back into the buffer int peek(); look at the next char WITHOUT consuming it istream& ignore(n, delim); discard up to n chars or until delim streamsize gcount(); how many chars the last unformatted read actually got ostream& put(char c); write ONE char ostream& write(const char *p, streamsize n); n raw bytes WHY `int c = in.get()` AND NOT `char c`: get() returns EOF, which is −1. A char cannot hold −1 distinguishably on a platform where char is unsigned — so char c; while ((c = in.get()) != EOF) never terminates. Use int. This is the same trap as C's fgetc, and it is worth stating in an exam answer. get(buf,n) vs getline(buf,n) — the ONE difference: get leaves the delimiter in the stream getline consumes it (but does not store it) Using get in a loop without ignoring the newline yourself gives an infinite loop.

char_io.cpp

#include <iostream>
#include <fstream>
#include <sstream>
#include <string>

int main() {
    { std::ofstream f("text.txt");
      f << "Nepal Engineering\nCouncil 2026\n"; }

    /* 1. get()/put() — a byte-exact copy */
    {
        std::ifstream in("text.txt");
        std::ostringstream out;
        int c;                          /* int, NOT char */
        long n = 0;
        while ((c = in.get()) != EOF) { out.put(char(c)); n++; }
        std::cout << "  copied " << n << " chars verbatim\n";
        std::cout << "  [" << out.str() << "]\n";
    }

    /* 2. peek() — decide before consuming */
    {
        std::istringstream s("42abc");
        std::cout << "  peek sees '" << char(s.peek())
                  << "' (not consumed)\n";
        int n; s >> n;
        std::cout << "  then read " << n
                  << ", peek now '" << char(s.peek()) << "'\n";
    }

    /* 3. putback() — un-read a character */
    {
        std::istringstream s("x123");
        char c = char(s.get());
        std::cout << "  got '" << c << "', not a digit — putting back\n";
        s.putback(c);
        std::string all; s >> all;
        std::cout << "  re-read as: " << all << "\n";
    }

    /* 4. get vs getline on a C array */
    {
        std::istringstream s("line one\nline two\n");
        char buf[32];
        s.get(buf, 32);
        std::cout << "  get     -> [" << buf << "]  next char is '"
                  << (s.peek()=='\n' ? "\\n" : "?") << "'\n";
        s.ignore();                 /* skip the leftover \n */
        s.getline(buf, 32);
        std::cout << "  getline -> [" << buf << "]  newline consumed\n";
    }

    /* 5. gcount() */
    {
        std::istringstream s("hello world");
        char buf[6];
        s.read(buf, 5); buf[5] = '\0';
        std::cout << "  read 5 -> [" << buf << "] gcount="
                  << s.gcount() << "\n";
    }
    return 0;
}
Output:
  copied 31 chars verbatim
  [Nepal Engineering
Council 2026
]
  peek sees '4' (not consumed)
  then read 42, peek now 'a'
  got 'x', not a digit — putting back
  re-read as: x123
  get     -> [line one]  next char is '\n'
  getline -> [line two]  newline consumed
  read 5 -> [hello] gcount=5

Counting the 31 characters: "Nepal Engineering" = 5 + 1 + 11 = 17 newline = 1 "Council 2026" = 7 + 1 + 4 = 12 newline = 1 total = 31 ✔ Two techniques worth extracting: peek() lets you look before you leap — essential when parsing, because you often need to know what KIND of token comes next before choosing how to read it. Every hand-written parser and lexer uses it. putback() undoes one get(). Together they let you write recursive-descent parsers: read a character, decide it belongs to the next token, push it back, and let another function handle it.

The get versus getline difference on character arrays causes a specific, infuriating bug: get(buf,n) in a loop reads the first line, leaves the

'
'

, then reads zero characters on every subsequent call because the delimiter is still there. The loop never advances and never ends. Either use getline, or call ignore() yourself as above.

Block I/O — read and write

block_io.cpp

#include <iostream>
#include <fstream>
#include <vector>
#include <string>

/* A buffered copy — how real file utilities work.
   4-8 KB is the sweet spot: big enough to amortise syscall
   overhead, small enough to stay in L1 cache. */
long bufferedCopy(const std::string &src, const std::string &dst) {
    std::ifstream in(src, std::ios::binary);
    std::ofstream out(dst, std::ios::binary);
    if (!in || !out) return -1;

    char buf[4096];
    long total = 0;
    while (in.read(buf, sizeof buf) || in.gcount() > 0) {
        out.write(buf, in.gcount());
        total += in.gcount();
    }
    return total;
}

int main() {
    /* make a file with known content */
    {
        std::ofstream f("big.bin", std::ios::binary);
        for (int i = 0; i < 1000; i++) {
            int v = i * i;
            f.write(reinterpret_cast<const char*>(&v), sizeof v);
        }
    }

    long n = bufferedCopy("big.bin", "big_copy.bin");
    std::cout << "  copied " << n << " bytes ("
              << n / (long)sizeof(int) << " ints)\n";

    /* verify by reading a specific value back */
    {
        std::ifstream f("big_copy.bin", std::ios::binary);
        f.seekg(500 * sizeof(int));
        int v; f.read(reinterpret_cast<char*>(&v), sizeof v);
        std::cout << "  element 500 = " << v
                  << "  (500^2 = " << 500*500 << ")\n";
    }

    /* read a whole vector in one call */
    {
        std::ifstream f("big.bin", std::ios::binary);
        std::vector<int> v(1000);
        f.read(reinterpret_cast<char*>(v.data()),
               v.size() * sizeof(int));
        std::cout << "  bulk read gcount=" << f.gcount()
                  << "  v[999]=" << v[999]
                  << " (999^2 = " << 999*999 << ")\n";
    }
    return 0;
}
Output:
  copied 4000 bytes (1000 ints)
  element 500 = 250000  (500^2 = 250000)
  bulk read gcount=4000  v[999]=998001 (999^2 = 998001)

Checking: 1000 ints × 4 bytes = 4000 bytes ✔ element 500 = 500² = 250,000 ✔ element 999 = 999² = 998,001 ✔ The loop condition is subtle and worth understanding: while (in.read(buf, sizeof buf) || in.gcount() > 0) read() returns the stream. On the FINAL partial block it reads fewer than 4096 bytes, sets eofbit AND failbit, and so converts to false — but gcount() still reports how many bytes it did get. Without the `|| in.gcount() > 0` the last partial block is silently DROPPED and your copy is truncated. That is a real bug found in production code. Always pair read() with gcount(). WHY BUFFER AT ALL — the arithmetic: copying 1 MB one byte at a time with get()/put(): 1,048,576 iterations copying with a 4096-byte buffer: 256 iterations → 4096× fewer loop iterations and stream operations The OS also does its own buffering, so the gain is not 4096× in wall-clock time, but the reduction in per-call overhead is real and measurable.

Worked example — a checksum and a hex dump

hexdump.cpp

#include <iostream>
#include <fstream>
#include <iomanip>
#include <string>

int main() {
    { std::ofstream f("sample.txt"); f << "NEC 2026"; }

    /* a simple additive checksum — unformatted read is the
       only correct way, since every byte counts */
    {
        std::ifstream f("sample.txt", std::ios::binary);
        unsigned long sum = 0; long n = 0;
        int c;
        while ((c = f.get()) != EOF) { sum += (unsigned char)c; n++; }
        std::cout << "  " << n << " bytes, checksum = " << sum << "\n";
    }

    /* hex dump — 8 bytes per line, hex then ASCII */
    {
        std::ifstream f("sample.txt", std::ios::binary);
        char buf[8];
        long offset = 0;
        while (f.read(buf, 8) || f.gcount() > 0) {
            std::streamsize got = f.gcount();
            std::cout << "  " << std::setw(4) << std::setfill('0')
                      << std::hex << offset << "  ";
            for (int i = 0; i < 8; i++) {
                if (i < got)
                    std::cout << std::setw(2) << std::setfill('0')
                              << (int)(unsigned char)buf[i] << ' ';
                else std::cout << "   ";
            }
            std::cout << " |";
            for (int i = 0; i < got; i++)
                std::cout << (buf[i] >= 32 && buf[i] < 127
                              ? buf[i] : '.');
            std::cout << "|\n";
            offset += got;
        }
        std::cout << std::dec;
    }
    return 0;
}
Output:
  8 bytes, checksum = 448
  0000  4e 45 43 20 32 30 32 36  |NEC 2026|

Verifying the checksum from ASCII values: char 'N' 'E' 'C' ' ' '2' '0' '2' '6' dec 78 69 67 32 50 48 50 54 hex 4e 45 43 20 32 30 32 36 running sum: 78 +69 = 147 +67 = 214 +32 = 246 +50 = 296 +48 = 344 +50 = 394 +54 = 448 ✔ matches the program And the hex dump agrees byte for byte: 4e=78, 45=69, 43=67, 20=32, 32=50, 30=48, 32=50, 36=54. Computing the same data two ways and getting consistent answers is exactly how you gain confidence in byte-level code. Note '2' is 50 and '0' is 48 — the CHARACTER '2' is not the NUMBER 2. That is why the digit-to-value conversion is c - '0', and why an unformatted reader must never assume a byte's numeric meaning. THE (unsigned char) CAST MATTERS. On a platform where char is signed, a byte above 127 reads as NEGATIVE, so adding it would SUBTRACT from the sum. Every byte-level program needs that cast; omit it and your checksum works on ASCII text and silently breaks on binary data — a bug that passes every text-file test. This is a real utility, not a toy: `xxd` and `hexdump -C` produce exactly this layout, and it is the standard first step when reverse-engineering an unknown file format.

🌍 Go further: C++20 added std::span<std::byte> and std::as_bytes, which give you a type-safe view over raw memory without the reinterpret_cast gymnastics above — std::byte exists precisely because char carries confusing sign and text semantics. C++23 added std::byteswap for the endianness problem. Search "std::byte vs char vs unsigned char"; understanding why the standard needed a fourth byte-like type is a good window into how much history C's char is carrying.

💡 Exam angle: distinguish formatted from unformatted I/O — conversion versus verbatim bytes, and whitespace skipped versus preserved. Know why cin >> name fails on "Ram Bahadur" and getline does not. State that get() returns int, not char, because of EOF. The get(buf,n) versus getline(buf,n) delimiter difference is a favourite one-mark question. For block I/O, know that read/write take char* and that gcount() is essential for handling the final partial block.

Syllabus points

get, put, getline, read, write

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.