Principales disfunciones a. IU tras prostatectomía radical

We will provide many versions of FMLib on the website for this book, numbered chapter by chapter. For example, FMLib5 contains the code needed to understand this chapter.

You should download this library and unzip it into a folder called FMLib5. You should then check that you can compile and run the project.

Have a look through the code and observe the following points:

• The hornerFunction functions are not in the header file. We think users of our library won’t want to know about them.

• The hornerFunction functions are static.

• The constants a1, a2, etc., used in our calculations are all static. • The hornerFunction functions are inline.

Exercises

5.5.1. Write a new file called geometry.cpp which contains a function to compute the area and circumference of a circle given its radius. Ensure that your functions can be called from main.cpp. Should your new functions be marked as static?

5.5.2. Which file gives a better overview of our matlib functions, matlib.cpp or matlib.h?

5.5.3. If you mark the function normcdf as static in the header file, what are the consequences? In the cpp file? In both? What if you don’t mark horner- Function as static?

5.5.4. Which file do you think should contain the definition for PI?

5.6

Summary

We have seen how header files allow us to write projects that use multiple files by putting declarations into header files and definitions into cpp files. The only exception is for inline functions.

Under normal circumstances, two cpp files can only share the same function definition if they share the same declaration via a header file.

We have learned the importance of information-hiding, which explains why not all declarations should be in header files.

If you have experience programming in other languages, you may won- der why you have to use header files at all. The answer is history. Modern languages do without header files—they provide alternative mechanisms for information hiding that require less typing.

In addition to following the rules of the C++ language, we have also fol- lowed some important conventions in this chapter. It is strongly recommended that you follow the following tips when using header files.

Tip: The rules for header files

• Start every .h file with #pragma␣once.

• Don’t put a function into a header file unless you have to. Try to hide information.

• Try to remember to use static for functions and variables that aren’t in the header file.

• For every .h file there should be one .cpp file that defines everything the .h file declares.

• In addition you should have one header called stdafx.h that includes the standard libraries you’re using. It saves typing to put most of your #include statements into one file. It is also possible to use special com- piler settings to “pre-compile” this shared header file, which allows you to compile your code more quickly. By convention on Windows this file is called stdafx.h and we have decided to use the same convention on all operating systems for simplicity.

• You should have a main.cpp file for testing.

• The first line of the .cpp files should #include the corresponding .h file.

• Don’t write using␣namespace in a header file. You don’t want to force the user of your library to use specific namespaces, it should be their choice. If you were to break this rule and use a namespace in a header file all users of that library will have to use that namespace. This would defeat the entire purpose of the namespace.

Chapter 6

Unit Testing

A revolution occurred in computer programming in the late 1990s (which some banks are still struggling to catch up with). The revolutionary idea was that you should write automated tests for all of your code.

Actually it wasn’t such a new idea. Computer programming veterans tell me that in the 1960s and early 1970s, testing your code was commonplace. But somehow lots of development teams forgot about it. It became quite normal to write code without any automated tests. This code was typically very expensive to maintain (with an army of manual testers) and was very prone to bugs.

If you are old enough to remember software from the 1990s, then you might have noticed that software doesn’t crash as much as it used to. I put this down, at least in part, to the automated testing boom.

The basic ideas of unit testing are as follows.

(i) Every function (near enough) should have at least one test. (ii) All tests should be fully automated.

(iii) You should assume that code that is not tested does not work. (iv) You should keep your tests forever.

Naturally, some manual testing is also required, but this should be much more along the lines of acceptance and usability testing. For example, finding out whether your music download app is easy to use would need some manual testing. Testing if your music download app actually works should be auto- mated.

If you attempt to write any C++ code that is more than a few lines long, you will probably write a bug. This is partly because you are new to C++, but mostly because you are human and humans make errors constantly. Just as you can be pretty sure that your calculus computation is wrong unless you’ve double-checked it, you can be pretty sure that C++ code is wrong unless it has a unit test.

One possible way to test your code is to write a main method to test the bit you are working on. The problem is that you find yourself constantly recreating tests that you have written before when you need to fix bugs.

The solution is to:

• write all tests as functions; • never throw any tests away;

• run all your tests every time you compile your code.

6.1

A testing framework for C++

Since C++ has no built-in support for unit testing, we’ll have to write our own. One might argue that it would be more sensible to use a testing framework that somebody else has written. There are lots of choices, such as the Boost Test Library (http://www.boost.org), Google Test (Google it!), cppunit, and many others.

Unfortunately these testing frameworks are designed for people who can already program in C++ and so won’t be put off by their odd syntax. This makes them inappropriate to use in an introductory C++ course.

Instead, I’ve written a very simple testing framework for use in this book. By the end of the book, you will be able to download and use the testing framework of your choice without too much difficulty.

Download FMLib6 and you will see that it contains a header file called testing.h. This file should be incomprehensible to you at the moment as it contains various C++ macros.