I'm having a hard time with this concept. What is Stroustrup getting at here? What is special about a class whose "representation is part of its definition"? What does a "concrete type" contrast with? (I assume it contrasts with "abstract type", but since, AFAIK, you can't even bring an instance of an abstract type into existence, it seems obvious you couldn't place that on the stack, initialize it, etc.)
Is there such a thing as a class I could instantiate that would NOT fit this description of a "concrete class"? Normally I find BS very easy to follow, but I'm missing the point here.
The basic idea of concrete classes is that they behave “just like built-in types.” For example, a complex number type and an infinite-precision integer are much like built-in int, except of course that they have their own semantics and sets of operations. Similarly, a vector and a string are much like built-in arrays, except that they are better behaved (§ 4.2, § 4.3.2, § 4.4.1).
The defining characteristic of a concrete type is that its representation is part of its definition. In many important cases, such as a vector, that representation is only one or more pointers to more data stored elsewhere, but it is present in each object of a concrete class.... In particular, it allows us to
• place objects of concrete types on the stack, in statically allocated memory, and in other objects (§ 6.4.2);
• refer to objects directly (and not just through pointers or references);
• initialize objects immediately and completely (e.g., using constructors; § 2.3.2); and
• copy objects (§ 3.3).
Stroustrup, Bjarne (2013-07-10). The C++ Programming Language (4th Edition) (Section 16.3 Concrete Classes; Kindle Locations 2373-2386). Pearson Education. Kindle Edition.
struct variable_length { char data[]; }
.