A type whose 'representation is part of its definition' is a type for which we can use value semantics.
For example std::string
A type whose 'representation may not be part of its definition' is a type for which we can't use value semantics; we access them through pointers or references. For example a pointer or reference to a base class (even if it is a base class that can be instantiated) may have a different dynamic type.
In general, a concrete class type is a class that is not designed for inheritance; not designed to act as a base class.
Stroustrup on abstract types:
3.2.2 Abstract Types
Types such as complex and Vector are called concrete types because their representation is part of their definition. In that, they resemble built-in types. In contrast, an abstract type is a type that completely insulates a user from implementation details. To do that, we decouple the interface from the representation and give up genuine local variables. Since we don’t know anything about the representation of an abstract type (not even its size), we must allocate objects on the free store (§3.2.1.2, §11.2) and access them through references or pointers (§2.2.5, §7.2, §7.7).
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.
It's important to recognize that C++ has a "method" of using Object Oriented Programming. It has different coding style support built into the same language, using the same language constructs in different ways.
1. Object methods are virtual.
2. Objects are referenced using methods (no data access).
Although you can't instantiate an abstract type, you can point to it. Polymorphism makes it possible for an object to be both a concrete type and an abstract type at the same time. For example, an object can be a Rectangle (concrete) and a Shape (abstract).
You can write code like, with Shape being abstract: