Lecture Notes for Advanced Programming II

24 September 2002 - Includes, Strings, and Invariants


  1. include files

    1. there are three types of include files - c++ standard, c standard, and others

    2. include file extensions

      1. the c++ and c standard include filenames do not have extensions - no .h

      2. other include filenames can be arbitrary

      3. be careful - <string> is not <string.h> is not <cstring>

    3. the std namespace

      1. the c++ and c standard include files define names inside the std namespace

      2. compilers respect this to varying degrees

    4. the c++ standard include files

      1. <iostream>, <iomanip>, <fstream> - stream io

      2. <utility>, <vector>, <list>, <deque>, <queue>, <stack>, <map>, <set>, <bitset>, <functional>, <memory>, <iterator>, <algorithm> - stl includes

      3. <exception>, <stdexcept> - exceptions

      4. <string>, <sstream> - strings

      5. <locale>, <limits>, <typeinfo> - odds and ends

    5. the c standard include files

      1. drop the .h, prepend a 'c' - from <stdio.h> to <cstdio>

      2. <cassert>, <cctype>, <cfloat>, <climits>, <cmath>, <cstdio>, <cstdlib>, <cstring>, <ctime>

      3. use the c-prepended header files

        1. accessing the .h forms is nonstandard

        2. c-prepended headers make the proper C++ extern declarations, .h headers do not

    6. any other include files are non-standard C++ files - strcasecmp() and strings.h and the X Windows includes

      1. "non-standard" is not bad - "unconventional" is bad

      2. don't include source (.cc) files - but the stl does

      3. templates trip over this convention

  2. the string data type

    1. some terminology - the string data type and character arrays

      1. string s; vs. char s[10];

    2. character arrays are bad

      1. arrays are bad - fixed size, no bounds checking

      2. character arrays are bad - the null byte, clumsy operations, relations, errors are subtle

    3. the string data type is good

      1. strings are defined in the header file <string>

      2. why strings are better than character arrays

        1. strings don't have a null byte - nothing to forget, nothing to remember

        2. strings manage space themselves - no overflows, no leaking memory

        3. comparisons work as expected

        4. of course, they're slower and bigger, but so what

      3. string declarations and initialization

        1. use #include <string> to get access to strings

        2. part of the standard c++ library - need the std:: prefix

          1. use the using std::string; statement to forego the std:: prefix

        3. strings can be initialized in the usual way

          1. std::string name = "jacaranda";

          2. a string with no initialization is the empty string - the string with no characters

        4. strings are accessed with subscripts, just like arrays

          1. the index range is the same

          2. the length() function returns the number of characters in a string

          3. unfortunately, subscript access to strings is not checked

          4. the at() accessor is checked

      4. string assignment and access

        1. assignment behaves like normal

        2. strings are accessed with subscripts, just like arrays

          1. unfortunately, subscript access to strings is not checked

            1. s[s.length() + 1] = 'a' does not add 'a' to the end of s

          2. the at() accessor is checked

        3. + does string catenation

      5. string comparison == works as expected

      6. stream io operations

        1. >> and << work as expected - eats white space

        2. the getline() function doesn't eat white space

      7. strings and character arrays

        1. automatic (mostly) conversion from character arrays to strings

        2. conversion from strings to character arrays is not automatic

          1. the c_str() member function

          2. the pointer returned is temporary

        3. characters are not character arrays - conversions between a character and a string requires work - str += 'a' wrong

  3. loop invariants

    1. straight-line programs are easy to understand (relatively)

    2. programs with loops are harder to understand

      1. what's happening while it's looping

      2. when does it stop looping

    3. the trick - find something about the loop that's always true

      1. easier to verify something stays true

      2. always true - before, during, and after

    4. example - search for an element in a vector

    5. the invariant must be true before the loop executes

    6. it must be true after the guard executes

    7. it must be true at the end of the loop body

    8. it will be true after the loop exits

    9. the combination of the invariant and negated loop guard gives what we want


This page last modified on 21 February 2002.