1 Introduction to C++ C++ basics, simple IO, and error handling

Transcription

1 1 Introduction to C++ C++ basics, simple IO, and error handling 1 Preview on the origins of C++ "Hello, World!" programs namespaces to avoid collisions basic textual IO: reading and printing values exception handling: reporting and handling errors standard C++ exception class hierarchy assertions: writing self-checking programs/objects invariants, preconditions, and postconditions assertions vs. exceptions 2 1

2 On origins of C++ C++ was designed to provide both object-oriented facilities for program organization object-oriented features originated from the Simula language (classes, virtuals, etc.) Stroustrup had used Simula for simulation of distributed systems (his thesis involved distributing UNIX kernel over a network of computers) C s efficiency and flexibility for systems programming Stroustrup didn t like alternatives such as Pascal: too simple and inflexible for real work 3 First version C with Classes ( ): originally implemented as a preprocessor features already include classes derived classes (i.e., subclasses) public/private access control friend classes constructors and destructors more static type checking (than C) Classes: an abstract data type facility for the C language. ACM Sigplan Notices, Jan Adding classes to the C language, Software - Practice and Experience, Feb 1983, pp

3 "Hello world!" #include <iostream> using std::cout; using std::endl; // std::cout is located here int main (int argc, char*argv [ ]) { cout << "Hello world!" << endl; return 0; // as C main // can be omitted as in C, IO operations are provided by libraries note the missing ".h" suffix in standard headers 5 Evolution of C++ from 1982 virtual functions (already in Simula, 1967) function name and operator (+, *,..) overloading references (&), in addition to old C pointers const variables and parameters user-controlled heap, via new and delete operations a version of multiple inheritance overloading of assignment and initialization ("=") pure virtual functions and abstract classes const member functions enumerations exceptions: throw, and try - catch construct templates & Standard Template Library (STL) evolution and standardization (2003) goes on.. 6 3

4 // another "Hello world" program in C++ #include <iostream> // get std::cout #include <string> // get std::string class World { // user-defined data type public: explicit World (std::string const& what) : msg_(what) { // initializer list void say () const { std::cout << msg_<< '\n'; ~World () { std::cout << "Bye!"; // destructor private: std::string msg_; // data member ; int main () { // start the program World world ("Hello!"); // local obj (variable) world.say (); World * ptrworld = new World ("How are you."); ptrworld->say (); // use dynamic object delete ptrworld; // release object 7 Notes on the "Hello!" program includes headers <.. > for text IO, std::string, etc. members may be public, protected, or private (best declared in this recommended order) data members are initialized within constructors, in a special initialization list the function member say is defined as const: declared not to modify the state of the object the write statement uses an overloaded output operator << (explained more later) the destructor (~World) cleans up (and often releases resources) before the memory space of the object is deallocated (here just prints trace) the constructor is defined explicit to disable implicit (automatic) conversions from strings to World values 8 4

5 Notes on the "Hello!" (cont.) the data member msg_ is a fixed part of an object (a field), and is automatically destructed along its owner dynamic objects are allocated on the free store or heap (with new), and must be destructed by calling the delete operation the execution starts at main - after construction of global objects (e.g., std::cout) local objects (= variables) are allocated on the call stack, and automatically destructed when exiting from the block the object world is destructed at the exit from main global objects are allocated in static memory, and automatically destructed at the end of the program - after main (e.g., the system-defined std::cout) 9 Namespaces define hierarchical scopes (not executable block) namespace Engine { // usually in a header file class Game { public:... ; // Engine access name from a namespace using the scope operator Engine::Game // in header or source file prevent name collisions between different libraries, while libraries are combined, extended, and modified correspond somewhat to Java packages namespaces can be nested (and unnamed, see later) 10 5

6 Namespaces (continued) standard libraries are placed in the namespace std #include <string> // get std::string using declaration is used to import a name into the local scope: #include <string> // get std::string using std:: string; // locally declares "string"... string name = "abcdef"; // OK without qualification #include is usually a textual inclusion (but a programming environment may use internally precompiled headers) 11 Namespaces (cont.) a using declaration is used to add a name from a namespace to a local scope to make all the names from the namespace potentially available, can specify the whole namespace with the using directive using namespace std; // directive: "imports" all however, using directive is not recommended makes maintenance harder: code is more vulnerable to changes, has fewer checks.. namespaces are open: can be extended with new declarations, within different header files namespace Engine {.. class GameEntity

7 Basic I/O three predefined ("console") streams std::cout - the standard output stream std::cin - the standard input stream std::cerr - the standard error stream (unbuffered) std::clog - the buffered error stream the insertion operator << is used for output ("put to") the extraction operator >> used for input ("get from") included via the header <iostream> these are exceptional global objects predefined by the system (created in the program's startup code) not generally recommended for C++ programs, since initializing and handling of globals can be tricky 13 Basic I/O (cont.) std::cout << "Enter value " << std::endl; // prompt int i = 0; std::cin >> i; // input an integer std::cout << "The value is "; std::cout << i << std::endl; // output the integer // or can freely chain io operations: std::out << "The value is: " << i << std::endl; double a = 0, b = 0; std::cin >> a >> b; // read two real numbers note that >> and << are overloaded operators: handle different kinds of values according to their (compiletime) types the manipulator std::endl prints a newline and flushes the buffer 14 7

8 // Read integer values until a positive value is entered. // If a non-integer value is entered, abort the program. #include <iostream> int main () { // Input with some error control int i = 0; std::cout << "Enter a positive integer" << std::endl; while (std::cin >> i) { // test for failure // input succeeds: got a number if (i > 0) // has correct sign? break; std::cout << "got non-positive value: re-enter: "; if (!std::cin) // failed for, e.g., format error std::cout << "Incorrect integer value" << std::endl; std::cout << "You entered " << i << std::endl; 15 Output operations and formatting an overloaded << operation (read: "put") formatting of output uses the format state operated on by objects called manipulators parameterized manipulators require the inclusion of the <iomanip> header file once a manipulator modifies the state of a stream, this state typically stays modified an important exception is setw: set output field width setw holds only for the next put operation after that the width sets to 0 (and uses max width) manipulators are "inserted" to the output stream // set field width (uses right justification) std::cout << std::setw (5) << i << std::endl; 16 8

9 Input operations by default, the input operator >> skips whitespace two manipulators modify this default std::skipws to skip whitespace (default) std::noskipws to not to skip whitespace char c = 0, d = 0; std::cin >> std::noskipws >> c >> d; // read chars std::cout << c << d << std::endl; // print them the header <ios> defines these manipulators but typically they are included via other iostreams headers alternatively, the operation get reads without skip std::cin.get (ch) // read a single char into ch the user can define new manipulators (see C++ texts) 17 Input operations (cont.) the stream may be either OK or in an error state if (cin >> var) // means: cin >> var; if (!cin.fail ()).. attempts to read input of the type of the variable var if fails, changes the state of the istream to an error, and returns a special value which can be tested subsequent IO is ignored (not performed).. until the error state is cleared, using cin.clear () (default zero arg means: good, i.e., clears all flags) the state of istream can be inspected by operations cin.eof () cin.fail () cin.bad () cin.good () a bad implies fail; good implies not eof and not fail the test "(cin >> var)" tests fail (and bad) flag 18 9

10 Input operations (cont.) fail () returns true if an error other than eof has occurred fail: a format error (usually can recover) bad: some fatal error (usually cannot recover) // read int values until the eof or a non-int value // then output the sum of the read values int sum = 0, i = 0; while (std::cin >> i) sum += i; // just continue until fails if (!std::cin.eof ()) { // not eof but still failed (or bad) std::cout << "Invalid int value encountered\n"; if (!std::cin.bad ()) // safe to reset failbit only std::cin.clear (); std:: cout << " sum = " << sum << std::endl; 19 How to read a string from input? read a single, whitespace terminated word #include <iostream> #include <string> int main () { std::cout << "Please enter a word:" << std::endl; std::string s; // initially empty std::cin >> s; // grows as needed std::cout << "You entered: " << s << '\n'; similarly, can read many consequent words as whitespace separated strings (in a loop) very convenient: no explicit memory management, no exception handling, no fixed-sized buffer to limit the size 20 10

11 Reading a whole line to read a whole line (and not just a single word) #include <iostream> #include <string> int main () { std::cout << "Please enter a line:" << std::endl; std::string s; std::getline (std::cin, s); // omits '\n' character std::cout << "You entered: " << s << '\n'; default line delimiter parameter: '\n' the delimiter not inserted into the string but skipped 21 Reading from a string to read values from a given string (e.g., already read input line) #include <sstream>.. std::istringstream input (" text 122 & "); std::string symbol; long int_value; char ch; // read from string stream: input >> symbol >> int_value >> ch; if (input) // if success then.. // can process values

12 File IO: writing a text file #include <iostream> #include <fstream> int main () { std::ofstream myfile ("example.txt"); if (myfile.is_open ()) { // no exception handling myfile << "This is a line." << std::endl; myfile << "This is another line." << std::endl; myfile.close (); // destructor would close else std::cout << "Unable to open file\n"; can use the same output primitives: << the destructor can automatically handle closing 23 File IO: reading a text file #include <iostream> // std::cout #include <fstream> // std::ifstream #include <string> // std::string, std::getline int main () { std::ifstream myfile ("example.txt"); if (myfile.is_open ()) { // test state std::string line; while (std::getline (myfile, line)) // not incl. \n std::cout << line << std::endl; else std::cout << "Unable to open file\n"; as usual, std::getline returns the istream status 24 12

13 Exception handling exception handling is done within try blocks, e.g.: try {.. // any C++ code catch (std::exception const& e) {.. // do local recovery if necessary throw; // rethrows the original exception e symbol& means an "alias": the parameter name is used as a synonym for the original exception object resembles a Java reference/pointer value exception handling is strongly tied to C++ destructors: while propagating an exception back along the call chain (stack), the destructors of local objects (variables) become executed 25 Exception handling (cont.) exception objects may be of any type (incl. prim. value) throw "stack underflow"; // syntax OK but peculiar recommended to use exceptions of class types throw std::out_of_range ("at operation"); // better primitive constructs (from C) do not throw exceptions: an array index that is out of bounds for a primitive (Cstyle) array will not generate any exception C++ (library) operations may throw exceptions derived from the base class std::exception, e.g., invalid index for vector::at (), generates std::out_of_range exception (but not the operator [ ]) using standard exceptions recommended for userdefined libraries and components, too 26 13

14 Example: handling an allocation failure if the runtime system cannot allocate memory for an object on the heap, then a std::bad_alloc exception is thrown try { michael = new Student (321); // one student studentarr = new Student [ ]; // huge array.. catch (std::bad_alloc const&e){.. Note. You can also define a special new-handler function to deal with the failure of new, or use the nothrow-version of new (omitted here, see e.g. Stroustrup). 27 Standard exceptions standard library defines a hierarchy of exceptions with std::exception as the root (in header <stdexcept>) exceptions are divided into two categories logic errors: precondition violations that in principle should be guaranteed before calling an operation; a failure will often mean an error in program logic (e.g., pop from an empty stack, invalid array index, etc.) run-time errors: dynamic errors that cannot really be tested or anticipated, usually numeric errors (overflow), communication line failure, etc. plus some logic/run-time language-related errors: bad_cast, bad_alloc, bad_exception.. subclasses of logic errors use self-explanatory names; e.g., std::invalid_argument exception 28 14

15 Standard exceptions (cont.) Logic and runtime exceptions are included from the header <stdexcept>. The header <exception> provides std::exception, std::bad_exception, and related functions. The header <typeinfo> provides std::bad_typeid and std::bad_cast. The header <new> provides std:bad_alloc. Not the perfect design (says Stroustrup) - but supports portability, uniform handling of exceptions, and is ready for use. 29 Standard exceptions (cont.) Exceptions are used for library and run-time errors out_of_range: invalid index for a STL container (vector) length_error: a specified structure/range too long range_error: error in numeric computation Special exceptions are used for C++ features bad_alloc: operator new fails to allocate memory bad_cast: dynamic_cast operation fails (on reference&) bad_typeid: typeid operator fails on zero pointer (0) bad_exception: violation of exception specification ios_base::failure: IO failure (only when a stream is especially configured to throw exceptions) By default, no exceptions are thrown from IO errors

16 Standard exceptions (cont.) std::exception has a special operation to report on the error (can be redefined in subclasses).. std::cerr << e.what (); // caught exception e derived exception classes have constructors, used to specify the value returned by what (): logic_error::logic_error (std::string const& msg); there is a similar arrangement for other predefined exceptions the constructor takes a std::string value as a parameter but the query operation what returns a C-style character array 31 Assertions assertions are Boolean expressions that define conditions that should never fail C++ provides (#include<cassert>) the predefined macro assert (booleanexpression); // already in standard C by default, is turned on in the test version if NDEBUG is not defined and the argument of assert () evaluates to 0, then source file and line are displayed, and the execution of the program is aborted, by calling abort () is usually turned off in the production version when macro NDEBUG is defined, assert () does nothing (it's empty) and thus "extra" checks are eliminated from the code 32 16

17 Assertions (cont.) int maxi (int x, int y, int z) { // just illustrative // returns the largest of the three given integers int max = x;.. // the rest of the implementation // just before return, check the validity of result: assert (max >= x && max >= y && max >= z); return max; document and check assumptions about program states during debugging, to expose and report bugs redundant checks can are eliminated from the production version (when NDEBUG is defined) however: exceptions are often part of specified service, and thus are not redundant 33 Preconditions and postconditions a precondition is a fact that must be true prior to the execution of some code section a precondition must hold in order for the operation to be succesfully performed it should be guaranteed by the caller of the operation if (i >= 0) // precondition to sqrt(i) d = sqrt(i); else.. a postcondition is a fact that must be true just after the execution of some section of code describes the program state after the operation has been successfully performed postconditions are the responsibility of the implementation often tested using preprocessor assertions within code 34 17

18 Class invariants a class invariant is an assertion for a class that must always hold for every object of this class defines a valid state of an object more precisely, must be true before and after any operation manipulating an object updates have intermediate states where the class assertion may (temporarily) be false a logical precondition for a method is the combination of its precondition and the class invariant however, checking preconditions and internal invariants are usually separated in practice why? (see next slide) 35 Exceptions vs. assertions (1) assertions are useful in development versions assert (isinvalidinternalstate_); // aborts if not (2) in production versions, exception handling and (potential) recovery are more acceptable than aborting if (!precondition or other external failure) throw std::runtime_error ("msg"); // reports to caller // otherwise OK: can continue.. in theory, pre- and postconditions can be used to define fully abstract responsibilities; e.g., that a stack service fulfills Last-In-First-Out - regardless of implementation black-box testing and test drivers are used to verify this kind of abstract services and responsibilities need both unit testing and internal checks 36 18

19 Exceptions vs. assertions (cont.) Differences between exceptions and assertions failed assert immediately terminates the program you can catch exceptions and try to continue you can turn off assertions (but usually not exceptions) Differences between preconditions and other assertions preconditions often tests external failures which the component cannot handle itself; instead, must throw failures back to their original source (the caller) many run-time failures (e.g., math. overflow, memory alloc.) can be seen as a kind of "external" factors, too => must use exceptions invariants and (concrete) postconditions test the internal state that cannot make sense to outsiders and indicate a bug in the component => use asserts to eliminate them 37 Summary: Why checks? Why not leave all checks out of the production version we don't know the real reason of the failure: perhaps a programming error or some external resource/factor strongly-typed languages (such as Java) use checks and exceptions to always prevent unsafe operations preconditions/external failures provide a pragmatic trade-off what to check, at the boundary of a component or module note that the C++ standard library (mostly) uses the same convention (provides precondition checks for selected operations) to really use exceptions, must additionally design classes and operations to be exception safe (i.e., to tolerate unexpected errors and their handling thru exceptions) 38 19

20 Summary C++ classes are user-defined data types namespaces prevent global name collisions IO uses overloaded put and get operations (<<, >>): safety (thru type inference) and extensibility (user types) IO doesn't use exceptions (by default) but we test the state of a stream via state flags (possibly implicitly) asserts make checks to reveal internal errors (i.e., bugs) prim. C operations don't check for errors or throw exceptions report failures from external sources (memory allocation, invalid index, numerical overflow, etc.) prefer predefined standard exceptions see online material: more samples, instructions how to compile and execute 39 20