Search

8.2 — Introduction to program-defined types

Because fundamental types have been defined as part of the core C++ language, they are available for immediate use. For example, if we want to define an int variable, we can just do so:

This also works for the compound types that are simple extensions of fundamental types (including pointers, references, and arrays):

. . . → Read More: 8.2 — Introduction to program-defined types

8.3 — Unscoped enumeration input and output

You might be surprised to find out that enumerators are actually just named integral constants (and as a result, enumerated types just hold an integral value).

This is similar to the case with chars (%Failed lesson reference, id XX%). Consider:

A char is really just a small integer, and the character ‘A’ gets converted . . . → Read More: 8.3 — Unscoped enumeration input and output

7.16 — std::cin and handling invalid input

Most programs that have a user interface of some kind need to handle user input. In the programs that you have been writing, you have been using std::cin to ask the user to enter text input. Because text input is so free-form (the user can enter anything), it’s very easy for the user to enter . . . → Read More: 7.16 — std::cin and handling invalid input

7.13 — Code coverage

In the previous lesson 7.12 — Introduction to testing your code, we discussed how to write and preserve simple tests. In this lesson, we’l ltalk about what kind of tests are useful to write to ensure your code is correct.

Code coverage

The term code coverage is used to describe how . . . → Read More: 7.13 — Code coverage

7.5 — Switch fallthrough and scoping

This lesson continues our exploration of switch statements that we started in the prior lesson 7.4 — Switch statement basics. In the prior lesson, we mentioned that each set of statements underneath a label should end in a break statement or a return statement.

In this lesson, we’ll explore why, and talk about some switch . . . → Read More: 7.5 — Switch fallthrough and scoping

7.14 — Common semantic errors in C++

In lesson %Failed lesson reference, id 7940%, we covered syntax errors, which occur when you write code that is not valid according to the grammar of the C++ language. The compiler will notify of you these type of errors, so they are trivial to catch, and usually straightforward to fix.

We also covered semantic errors, . . . → Read More: 7.14 — Common semantic errors in C++

7.17 — assert and static_assert

In a function that takes parameters, the caller may be able pass in arguments that are syntactically valid but semantically meaningless. For example, in the previous lesson (7.15 — Detecting and handling errors, we showed the following sample function:

This function does an explicit check to see if y is 0, since dividing by . . . → Read More: 7.17 — assert and static_assert

7.12 — Introduction to testing your code

So, you’ve written a program, it compiles, and it even appears to work! What now?

Well, it depends. If you’ve written your program to be run once and discarded, then you’re done. In this case, it may not matter that your program doesn’t work for every case — if it works for the one case . . . → Read More: 7.12 — Introduction to testing your code

7.3 — Common if statement problems

This lesson is a continuation of lesson 7.2 — If statements and blocks. In this lesson, we’ll take a look at some common problems that occur when using if statements.

Nested if statements and the dangling else problem

It is possible to nest if statements within other if statements:

The . . . → Read More: 7.3 — Common if statement problems

7.11 — Halts (exiting your program early)

The last category of flow control statement we’ll cover is the halt. A halt is a flow control statement that terminates the program. In C++, halts are implemented as functions (rather than keywords), so our halt statements will be function calls.

Let’s take a brief detour, and recap what happens when a program exits normally. . . . → Read More: 7.11 — Halts (exiting your program early)