Back in the computing "iron-age", when programmers wrote their code in

machine or assembly language, a programmer would manipulate a data element representing quarterly sales or the velocity of a missile by using the data element's memory address, like the line below, which stores a value (from the CPU's AX register) in the memory location A42C:

int velocity = 125;

Each high-level language, from FORTRAN and COBOL in the 1950s, to Java and C++ today, comes equipped with a pre-defined, built-in set of data types. In C++, these are the primitive types like int, float and char. These types are defined in the language itself, and not as part of the standard library.

However, programmers want more. Financial programmers want real numbers, scientific programmers can't live without imaginary numbers, business programmers want dates and times, while graphics programmers really need points and shapes.

Rather than adding all of these extensions as built-in types, creating complex, "Rube-Goldberg-like languages", designers found it better to give programmers the ability to define their own data types. That's really at the heart of modern, object-based programming.

Bjarne Stroustrup, the inventor of C++ explains that C++ is not an Object-Oriented language in the spirit of Smalltalk or Simula. C++ is a multi-paradigm language; a language that supports different styles of programming, but doesn't require you to subscribe to any particular orthodoxy.

Here's what Stroustrup has to say:

Languages such as Ada, Clu, and C++ allow users to define types that behave in (nearly) the same way as the built-in types. Such a type is often called an abstract data type, but I prefer the term user-defined type. The programming paradigm supported by user-defined types (often called object-based programming) can be summarized as:

Decide which types you want; provide a set of operations for each type.

Arithmetic types such as rational and complex numbers, as well as simple concepts like dates, times, pairs, points, lines, colors, bcd characters, error messages and currencies are all excellent candidates for user-defined types, as opposed to representing them as plain data structures or as part of a larger hierarchy.

At the beginning of the semester (H01), you wrote a program to add and subtract time. This was harder than expected, because you didn't have a Time type; you did everything with integers. Let's rectify that now by creating a Time structure, with hours and minutes. Assume a 24-hour clock, so you don't need an indicator for AM/PM.

struct Time
{
    int hours;
    int minutes;
};

Now, you can create a Time object that bundles that data:

int main()
{
    Time lunch = = {11, 15};
    cout << lunch.hours << ":" << lunch.minutes << endl;

    return 0;
}

The definition of Time is straightforward, but, it will cause problems. There are certain restrictions on what values members of a Time object may and may not have. Given our specification, for instance, hours must be between 0..23 and minutes must be between 0..59. We call these the type's invariants.

But, with structures, we have no means of enforcing those restrictions. There is nothing to prevent someone, (most likely you, if you aren't careful), from constructing a bogus Time object like this:

Time bed_time = {27, 95};

Both values supplied here makes the Time object, bed_time, invalid. But, the code compiles fine; everything is perfectly legal C++, and the compiler has no idea that something bad might happen in the future.

To give an idea of what could go wrong, suppose that you have a Radiation Therapy Machine like the Therac-25. If the software controlling the machine used a Time object to specify how long a therapy session should last, the machine would be intrinsically unsafe. Think about what will happen if you write the following code using the (non-buggy) run() function:

Time treatmentTime = {0, -2};
run(treatmentTime);
. . .
void run(Time& t)
{
    auto elapsed = t.hours * 360 + t.minutes * 60;
    while (elapsed > 0)
   { 
        pulseBeam();
        --elapsed;
   } 
}

As Peg and Cat point out, you now have a fairly serious problem. Even though the run() function is reasonable, it relies on the Time& t parameter being correctly initialized. Because minutes was, (accidentally), set to a negative number, the loop will supply not two minutes of radiation, but billions of pulses instead.

If you're lucky, the code will have some extra checking to catch this, and report an error. If you are unlucky and the code actually sends too much radiation to the patient, then they would die, just as in the original Therac-25 incident.

In other words, because the user of the Time structure set a single field to a nonsensical value, it's possible that your program could cause real injury. This is clearly unacceptable, and you will need to do something about it.

There are two problems with implementing Time as a struct.