horseshoe bend 1908283 1280

C++ Core Guidelines: IOstreams

When you interact with the outside world, the iostream library is the way to go in C++. As always, you have to keep a few rules in mind. Let me show which rules.

 horseshoe bend 1908283 1280

 

The C++ core guidelines give a good overview of iostreams: "iostreams is a type safe, extensible, formatted and unformatted I/O library for streaming I/O. It supports multiple (and user extensible) buffering strategies and multiple locales. It can be used for conventional I/O, reading and writing to memory (string streams), and user-defines extensions, such as streaming across networks (asio: not yet standardized).

Surprisingly for me, and in contrast to the fact, that iostreams are quite essential and are used by most C++ developers, there are only five rules which deal with them, and these rules do have not much content. Here are they:

I have to add additional information to make a story out of the rules. This is not necessary for the first rule:

SL.io.1: Use character-level input only when you have to

First, here is a bad example from the guidelines. Using character-level input for more than one character:

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

     

    char c;
    char buf[128];
    int i = 0;
    while (cin.get(c) && !isspace(c) && i < 128)
        buf[i++] = c;
    if (i == 128) {
        // ... handle too long string ....
    }
    

     

    This is a terrible solution for a simple job. My remark does not hold for the right way to do it:

     

    string s;
    s.reserve(128);
    cin >> s;
    

     

    Presumably, the better way is also the faster way.

    The following rule states a no-brainer.

    SL.io.2: When reading, always consider ill-formed input

    The question is now: How can we deal with bad data? Each stream has a state associated.

    State of the Stream

    Flags represent the state of the stream. The methods for dealing with these flags need the header <iostream>.

    StateStream

    Examples causing the different states of a stream

    std::ios::eofbit

    • Reading beyond the last valid character.

    std::ios::failbit

    • False formatted reading.
    • Reading beyond the last valid character.
    • Opening of a file went wrong.

    std::ios::badbit

    • Size of the stream buffer cannot be adjusted.
    • Code conversion of the stream buffer went wrong.
    • A part of the stream threw an exception.

    stream.fail() returns whether std::ios::failbit or std::ios::badbit is set.

    Reading and setting the state of a stream

    stream.clear()

    • Initializes the flags and sets the stream in the goodbit state

    stream.clear(sta)

    • Initializes the flags and set the stream into the state sta.

    stream.rdstate()

    • Returns the current state.

    stream.setstate(fla)

    • Sets the additional flag fla.

    Operations on a stream have only an effect if the stream is in the goodbit state. If the stream is in the badbit state, it can not be reset to the goodbit state.

     

    // streamState.cpp
    
    #include <ios>
    #include <iostream>
    
    int main(){
    
        std::cout << std::boolalpha << std::endl;
    
        std::cout <<  "In failbit-state: " << std::cin.fail() << std::endl;
      
        std::cout << std::endl;
      
        int myInt;
        while (std::cin >> myInt){
            std::cout << "Output: " << myInt << std::endl; 
            std::cout <<  "In failbit-state: " << std::cin.fail() << std::endl;
            std::cout << std::endl;
        }
      
        std::cout <<  "In failbit-state: " << std::cin.fail() << std::endl;
        std::cin.clear();
        std::cout <<  "In failbit-state: " << std::cin.fail() << std::endl;
    
        std::cout << std::endl;
    
    }
    

     

    The input of the string wrongInput causes the stream std::cin to be in std::ios::failbit state. Consequently, wrongInput and std::cin.fail() cannot be displayed. First, you have to set the stream std::cin in the goodbit state.

    You can show your output with printf or with iostreams. My tip is obvious.

    SL.io.3: Prefer iostreams for I/O

    The following two program displays two times the equivalent formatted data. First, by using printf and format strings; second, by using iostreams and format manipulators.

     

    // printfIostreams.cpp
    
    #include <cstdio>
    
    #include <iomanip>
    #include <iostream>
     
    int main(){
        
        printf("\n");
        printf("Characters: %c %c \n", 'a', 65);
        printf("Decimals: %d %ld\n", 2011, 650000L);
        printf("Preceding with blanks: %10d \n", 2011);
        printf("Preceding with zeros: %010d \n", 2011);
        printf("Doubles: %4.2f %E \n", 3.1416, 3.1416);
        printf("%s \n", "From C to C++");
        
        std::cout << std::endl;
        std::cout << "Characters: " << 'a' << " " <<  static_cast<char>(65) << std::endl;  
        std::cout << "Decimals: " << 2011 << " " << 650000L << std::endl;
        std::cout << "Preceding with blanks: " << std::setw(10) << 2011 << std::endl;
        std::cout << "Preceding with zeros: " << std::setfill('0') << std::setw(10) << 20011 << std::endl;
        std::cout << "Doubles: " << std::setprecision(3) << 3.1416 << " " 
                                 << std::setprecision(6) << std::scientific <<  3.1416 << std::endl;
        std::cout << "From C to C++" << std::endl;
      
        std::cout << std::endl;
        
    }
    

     

    As promised, the same output:

     printfIostreams

    Okay, but why should you prefer iostreams to printf? There is a subtle but critical difference between printf and iostreams. The format string with printf specifies the type, and the format of the displayed value, and the format manipulator with iostreams specifies only the format. To say it the other way around: The compiler deduces the correct type automatically in case of an isotream.

    Let me make my point clear. You get undefined behavior when you have a bad day or are new to C++ and specify the wrong type in a format string.

    // printfIostreamsUndefinedBehaviour.cpp
    
    #include <cstdio>
    
    #include <iostream>
    
    int main(){
        
        printf("\n");
        
        printf("2011: %d\n",2011);            
        printf("3.1416: %d\n",3.1416);           
        printf("\"2011\": %d\n","2011");           
        // printf("%s\n",2011);    // segmentation fault
        
        std::cout << std::endl;
        std::cout << "2011: " <<  2011 << std::endl;    
        std::cout << "3.146: " << 3.1416 << std::endl;   
        std::cout << "\"2011\": " << "2011" << std::endl;   
        
        std::cout << std::endl;
    
    }
    

     

    This is what undefined behavior looks like on my local PC.

    printfIostreamsUndefinedBehaviour

    Of course, the compiler usually writes a warning in case of a wrong format string, but you have no guarantee. Additionally, I know what often happens when the deadline is passed. You ignore the warnings and, maybe, will look at it later. Instead of dealing with errors, don’t make errors in the first place.

    The difference between printf and iostreams reminds me of the most important design guideline from Scott Meyers:Make interfaces easy to use correctly and hard to use incorrectly.

    What’s next?

    I used in the iostream example format specifiers. To simplify your life as a software developer, you should keep a few format manipulators in mind. Let me show in my next post, which ones.

     

     

     

    Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to Tipi.build 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *