If you want to disclose the details of the implementation, you could go for something as developed as:

The key of this design is to disclose that vector is a templated class, and that it is instantiated by binding the template parameter T to the class Foo. To put Foo in the picture, you could either just show it at the instantiation level, but I preferred to show some kind of relation with T. I used here a realization, since T implicitly defines in the C++ semantic an interface for the template parameter, and Foo is expected to implement this (implicit) interface. I also used composition, since C++ vectors are by value, and the vector owns the lifecycle of its elements.
Unfortunately, this makes the design look more complex than it is in reality. Moreover it doesn't show the full reality of a std::vector that has a second template parameter Allocator. Last but not least, to be fully transparent, you should use a qualified composition, with a std::vector::size_type qualifier (to document that there is an indexed access possible). You'd end-up with a very complex diagram.
I therefore recommend to consider a simplified approach. Since everybody knows what a std::vector is, you may use the more compact (and still legit) form of a direct binding, assuming that the template details are defined elsewhere:

This is very close to your implementation and stays very readable. However, you could simplify one step further: is vector a fundamental design choice? Or is it just one practical way to implement a one-to-many composition? If the real intent is just that Demo may be composed of several Foo you could be as simple as:

Here you would let to the implementer to chose the best way to implement the composition instead of graving the implementation choice in the marble of your model.