The Complex Class and Its Scalar Parts

Suppose you are writing a program that needs complex numbers, the kind with a real part and an imaginary part. Those two parts do not have to be stored with the same level of precision. One program might be satisfied with single-precision floating-point values, while another needs the greater precision of double-precision values. The choice depends on what the program is doing, not on what complex numbers are in the abstract.

The question this article answers is how that flexibility is built into the standard library, and what it means for you as a programmer. The short answer is that the standard library's complex type is a template. The rest of the article traces what that means step by step.

Before looking at the rules in detail, follow what happens when a programmer uses the template. Watch which parts are already fixed and which part is still open at each step.

The standard library's complex is a template in exactly this sense. The source states the central design decision directly: the library's complex is a template, so it supports complex numbers whose parts can have different scalar types. The pattern itself is not a finished class with one fixed set of behaviors.

It is worth being precise about what the template does not decide. It does not fix the scalar type in advance. That decision is delegated to the programmer, who supplies a scalar type when using the template. This is the reason the single name complex can stand for a whole family of related types rather than one type alone.

The source names two scalar types that the complex number template can support. The first is the single-precision floating-point number, usually called a float. The second is the double-precision floating-point number, usually called a double. Both are scalar types the programmer can supply as the scalar choice for the template.

The source also says the list is not closed. It uses the phrase etc., which signals that other scalar types can be used in the same way. So float and double are the examples the source gives, not a complete list of every type the template accepts. When you read or write code against the template, the rule to remember is that any suitable scalar type can be supplied, not only the two named explicitly.

The relationship between the template and its scalar types runs in one direction. The template is the shared pattern, and each scalar type is a separate option that can be plugged into it. Each choice yields its own concrete complex type. The diagram below shows the shape of that relationship: one template, several scalar options, and a concrete complex type for each option you choose.

Read the diagram from the top down. The template sits at the top and is never itself the type of a stored value. Each scalar option below it produces a different concrete complex type at the bottom. The complex with float parts and the complex with double parts are two distinct types, even though both come from the same template. The third branch stands for the other scalar types the source's etc. signals.

It helps to contrast the template design with the alternative the source describes. A library that offers only one fixed version of complex numbers has a single underlying scalar type baked into its definition. The template instead leaves that scalar type open. The diagram below compares the two approaches side by side.

The fixed approach is simpler to describe, but it forces every program into one precision choice. The template approach allows each program to pick the scalar type it needs, at the cost of understanding that the template produces a concrete type only after that choice is made. The source presents the template as the way the C++ standard library addresses the precision problem.