A simple program with trains and inheritance Here it is my program. I'm especially worried about the main because I know that one must be careful while instancing vectors of "inherited" objects. The code I have works fine (as far as I can see) but I saw the original program made by my teacher and his implementation of the vector in the main uses new and iterator. I'd like to have some piece of advice on how to improve! 

#include &lt;vector&gt;
#include &lt;iostream&gt;
#include &lt;cmath&gt; 

class Station {
private:
    double x_, y_;

public:
    Station(double x, double y) : x_(x), y_(y) { }
    Station(const Station &amp; s) : x_(s.x_), y_(s.y_) { }

    // dichiarazione funzione globale  
    friend double dist(const Station &amp; s, const Station &amp; t);
};

class Train {
private:
    double vm_;
public:
    Train(double vm) : vm_(vm) { }
    double getvm() {return vm_; } 

    virtual double time_of_travel(const Station &amp; s, const Station &amp; t) { 
        return( dist(s, t)/vm_);
    }
};

class Regionale : public Train {
public:
    Regionale() : Train(60.) { }
};

class Intercity : public Train {
private:
    Station stop_;
public:
    Intercity(const Station stop) : stop_(stop), Train(110.) { }

    double time_of_travel(const Station &amp; s, const Station &amp; t) {
        return( (dist(s, stop_) + dist(stop_, t))/this-&gt;getvm());
    }

};


double dist(const Station &amp; s, const Station &amp; t) {
    return(sqrt(pow(s.x_ - t.x_, 2) + pow(s.y_ - t.y_, 2)));
}

int main() {
    Station Milano (0. ,0.);
    Station Bergamo (35. ,25.);
    Station Piacenza (40. , -45.);

    std::cout &lt;&lt; dist (Milano, Bergamo) &lt;&lt; std::endl;
    std::cout &lt;&lt; dist (Bergamo, Piacenza) &lt;&lt; std::endl;
    std::cout &lt;&lt; dist (Piacenza, Milano) &lt;&lt; std::endl;

    Intercity i(Milano);
    Regionale r;
    std::vector&lt;Train * &gt; v = {&amp;i, &amp;r};

    for(auto elem : v) std::cout &lt;&lt; elem-&gt;time_of_travel(Bergamo, Piacenza) &lt;&lt; std::endl;

}
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.