Built-in Types in C++

Most of the types you have used so far come with the language itself. An int holds a whole number, and an array holds a fixed run of elements of one kind. These are built-in types. Now imagine a type that a programmer designs and writes as a class, yet that can be used in almost the same way as those built-in types. That idea is the subject of this article: concrete classes.

Keep one question in mind while you read: when a class is written to behave like a built-in type, what exactly is shared with the built-in type, and what is left different? You will trace the answer step by step through an example, then check it against the source's pairings of types.

Think of a built-in type as the material you start from. When you write int total = 0; you create a value, you combine it with other values using operations the language supplies, and you pass it through your program in familiar ways. Nothing about that usage needs explaining: it is the baseline pattern of working with values in C++.

A concrete class asks a different question. Instead of accepting the language's operations as given, the programmer defines a type whose values can be used with that same familiar pattern. The source's central claim is that the user-defined type can be used in almost the same way as the built-in one, even though the two are not the same thing.

The word concrete here signals that the class is a complete, usable value type: its objects are meant to be created, combined, and passed around the way built-in values are. A concrete class does not have to reproduce every detail of the built-in type it resembles. Its job is to make its objects feel like ordinary values in a program.

The source frames the idea through two comparisons. A complex number type and an infinite-precision integer are each much like the built-in int. A vector and a string are each much like a built-in array. In both comparisons, the user-defined type is close enough to its built-in counterpart that it can be understood through that counterpart, even though it is not the same thing.

The pairs show that the resemblance concerns the role each type plays in a program, not how it is built inside. A complex number and an int play similar roles as quantities you calculate with. A vector and an array play similar roles as containers of elements. The internal workings can differ widely while the usage pattern stays familiar.

A complex number is a good illustration because it is a quantity that people often wish to add and track just as they would a plain number. The example below is written for this article, not taken from the source. It defines a small complex number class that stores a real part and an imaginary part, and it defines its own addition operation. Read it with the source's idea in mind: the class can be used the way a number is used, and the addition it performs is the class's own definition.

The plus sign in main looks like the ordinary arithmetic you already know, which is the resemblance to int that the source describes. But the addition itself lives inside the class. Had the programmer defined operator+ differently, the same visible syntax would mean something else. This is the second half of the source's point: the operations belong to the concrete type.

The source names two things that a concrete class and the built-in type it resembles share. The first is the overall pattern of use: you create values, combine them, and move them through a program in familiar ways. The second is the sense that the type is a sound, well-formed value rather than a loose collection of parts. Beyond that shared pattern, the concrete class is free to define what its own operations mean.

The diagram below sets a built-in int beside a user-defined complex number type. Both are used by writing values and operations on them, but the operations come from different places: the built-in int uses the operations the language supplies, while the complex type supplies its own.

Read the two columns across. Each row of shared pattern matches, so a reader familiar with int can start using the complex type immediately. The bottom row is where they separate: the int's operations are supplied by the language, while the complex type's operations are whatever its class defines.

Built-in types can be built from the fundamental types, the const modifier, and the declarator operators. It helps to read this definition as a recipe with three inputs. The first input is the set of fundamental types. The second is the const modifier, which marks a value as one that should not change. The third is the set of declarator operators, which shape how a declaration names and structures a type. A built-in type is whatever the language lets you form by combining these three inputs.

Read the diagram as a set of three inputs feeding one result. None of the three inputs is a complete built-in type on its own; each one contributes a part, and the combination is what the language recognizes as a built-in type.

This declaration does not invent a new kind of type with its own operations. It combines a fundamental type with the const modifier, which is exactly the recipe the definition names. The source does not list every possible combination, so treat this as one illustration of the general principle rather than a complete catalogue.

Imagine you need a language in which a programmer can write a fast program with almost no hidden cost, where every operation maps onto something the machine actually does. C++ begins from that requirement. Its built-in types and operations are rich, but they are deliberately low-level, and they reflect the capabilities of conventional computer hardware directly and efficiently.

A low-level foundation has a consequence. The built-in types do not give you high-level facilities that make advanced applications easy to write. The language therefore adds a second layer: a set of abstraction mechanisms that programmers use to build those higher-level facilities themselves. Keep that two-layer picture in mind, because the rest of this section is about how the layers connect.

Built-in types are the starting material. Abstraction mechanisms are the tools that turn that material into something larger. The source describes these mechanisms as a sophisticated set that C++ adds on top of the built-in types and operations. Programmers use them to build high-level facilities out of the low-level base.

The purpose of these mechanisms is specific. They are primarily designed to let programmers design and implement their own types, with suitable representations and operations. They also let programmers use those types simply and elegantly once they exist. So the abstraction mechanisms serve two audiences in one move: the person who designs the type and the person who later uses it.

When a programmer uses the abstraction mechanisms to build a type, the result is called a user-defined type. The source gives two names for this kind of type: classes and enumerations. Concrete classes such as the complex number type above are one kind of user-defined type. Most of the source book is devoted to the design, implementation, and use of user-defined types, which shows how central this category is to working in C++.

Read the diagram from the top down. The built-in layer is the foundation at the top, augmented by abstraction mechanisms. Those mechanisms are the means by which user-defined types are built. User-defined types are also constructed directly out of the built-in types, so the built-in layer stays the foundation even at the top of the stack.

The source also notes that the standard library mainly consists of user-defined types. Those library components show what can be built with the language facilities and programming techniques the early chapters introduce. The standard library is a good place to see user-defined types at work once you understand the built-in foundation.