But it is important to contrast this to composition, where the relationship between one object and another is not defined by their class relationship (i.e., their type) but rather by the references that each has in relation to the other. General composition is a very powerful and ubiquitous method of arranging objects: when one object needs to know something about another, it has a reference to that other object and invokes methods upon it as necessary. As soon as you start looking for this super-fundamental pattern, you'll find it absolutely everywhere; the only way to avoid it is to put everything in one object, which would be massively dumb!
(There's also stricter UML composition/aggregation, but that's not what the GoF book is talking about there.)
One of the things about the composition relationship is that particular objects do not need to be hard-bound to each other. The pattern of concrete objects is very flexible, even in very static languages like C++. (There is an upside to having things very static: it is possible to analyse the code more closely and — at least potentially — issue better code with less overhead.)
Some GoF patterns only really make sense in the context of a language where things are fairly static. That's OK; it just means that not all forces affecting the pattern are necessarily listed. One of the key points about studying patterns is that it helps us be aware of these important differences and caveats. (Other patterns are more universal. Keep your eyes open for those.)