Reading C-Style Strings

To read C-style strings, you can use the getline function. (This is an overload version of the getline function discussed in the previous section.) This getline member function is defined as:

std::istream& getline(char *buffer, int len, char delim = '\n')

The parameters to this function are:

A C-style string in which to store the data that has been read.

Length of the buffer in bytes. The function reads up to len-1 bytes of data into the buffer. (One byte is reserved for the terminating null character \0.) This parameter is usually sizeof(buffer).

The character used to signal end-of-line.

This function returns a reference to the input file. The function reads up to and including the end-of-line character ('\n'). The end-of-line character is not stored in the buffer. (An end-of-string ('\0') is store in to terminate the string.)

For example:

char buffer[30];
std::cin.getline(buffer, sizeof(buffer));

Output Files

The functions for output files are similar to input files. For example, the declaration:

std::ofstream out_file("out.dat");

creates a file named out.dat and lets you write to the file using the file variable out_file.

Actually, the constructor can take two additional arguments. The full definition of the output file constructor is:

std::ofstream::ofstream(const char *name, int mode=std::ios::out, 
                   int prot = filebuf::openprot);

The parameters for this function are:

The name of the file.

A set of flags ORed together that determine the open mode. The flag std::ios::out is required for output files. Other flags are listed in Table 16-2. (The std::ios:: prefix is used to indicate the scope of the constant. This operator is discussed in more detail in Chapter 21.)

File protection. This is an operating system-dependent value that determines the protection mode for the file. In Unix the protection defaults to 0644 (read/write owner, group read, others read). For MS-DOS/Windows this defaults to 0 (normal file).

Table 16-2: Open flags




Append data to the end of the output file.


Go to the end of the file when opened.


Open for input (must be supplied to the open member function of std::ifstream variables).


Open file for output (must be supplied to the open member function of std::ofstream variables).


Binary file (if not present, the file is opened as an ASCII file). See the later section "Binary I/O" for a definition of a binary file.


Discard contents of existing file when opening for write.


Fail if the file does not exist. (Output files only. Opening an input file always fails if there is no file.)


Do not overwrite existing file. If a file exists, cause the open to fail.

For example, the statement:

std::ofstream out_file("", std::ios::out|std::ios::binary|std::ios::nocreate|

appends (std::ios::app) binary data (std::ios::binary) to an existing file (std::ios::nocreate) named

Example 16-2 contains a short function that writes a message to a log file. The first thing the function does is to open the file for output (std::ios::out), appending (std::ios::app), with the writing to start at the end of the file (std::ios::ate). It then writes the message and closes the file (the destructor for out_file performs the close).

This function was designed to be simple, which it is. But also we didn't care about efficiency, and as a result this function is terribly inefficient. The problem is that we open and close the file every time we call log_message. Opening a file is an expensive operation, and things would go much faster if we opened the file only once and remembered that we had it open in subsequent calls.

Example 16-2: log/log.cpp

#include <iostream>
#include <fstream>
void log_message(const string& msg)
    std::ofstream out_file("data.log", 
    if (out_file.bad(  ))
        return; /* Where do we log an error if there is no log */
    out_file << msg << endl;

Page:  1   2   3   4   5   6   7   8   9   Next 


  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

  • Instead of only managing projects organizations do need to manage value! "Doing the right things" and "doing things right" are the essential ingredients for successful software and systems delivery. Unfortunately, with distributed delivery spanning multiple disciplines, geographies and time zones, many organizations struggle with teams working in silos, broken lines of communication, lack of collaboration, inadequate traceability, and poor project visibility. This often results in organizations "doing the …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds