A simple program with trains and inheritance
Coal_ already made some good points. Let's just elaborate on the one about private.
A class makes everything in it private by default that is why you don't need it if you order your interface this way. However it's recommended to order your interface from public to private so people who read it can see which methods you expose without having to read through all the private data first.
If you are using a trailing underscore because you're worried about problems when assigning arguments to members then there is no need for that. This is because it's guaranteed to work even if the names are the same. Just make sure to be careful in the constructor body if you do this!
Your variable names could be better. In general you should avoid single letter names and choose a descriptive name.
Some parts are probably easier to read if you put a few more spaces inbetween operators. Indenting could also be improved for example in your ctors:

Foo()
    : bar(0)
    , baz(1)


is a lot more readable than putting everything in a single line.
Some of your parenthese in the return statements are superfluous and can be removed.
In C++ it's generally recommended to treat &amp; as part of the type and therefore write foo&amp; instead of foo &amp;.
Since you included &lt;cmath&gt; you should probably prefix pow and sqrt with std::.
You seem to use double solely because of your math functions. Perhaps strategic casting would be better instead of using a type you don't fully make use of.
When using the ranged-for loop it's recommended to use this form:

for (auto const&amp; value : container) {
    // ...
}


The const makes it clear you don't intent to modify things in this loop and passing by reference avoids unecessary copies.
If you run your compiler with warnings (as you should! For example to discover some potential problems you can use an online compiler like Clang with -Weverything. For production code you want to pick your warning levels more carefully though) you will notice that there are some issues.
You have a wrong initialization order and are missing a virtual destructor. Order can be important when you depend on something in the base class.
The way you handle your objects in main is certainly interesting but this seems like a good place for smart[1] pointers[2] and their respective make_unique/shared functions.