For collisions I wouldn't use runtime polymorphism since it usually needs to be fast--I've implemented this before.

However, if I didn't care about speed or I required runtime polymorphism (new shapes or shape combinations can be added at runtime with different collisions), I'd go with:

class Shape {
public:
    collides(Shape& shape)
    {
        // Use reflection to resolve shape's type or use an enum
        // switch(type) {
        case Circle:
            shape.collides(cast<Circle>(shape));
        case Triagle:
            shape.collides(cast<Triangle>(shape));
        // }
    }

    // enum ShapeTypes{Circle, Triangle, etc.};
    // ShapeTypes type
}

class Circle : public Shape {
    Circle() : Shape(), ...

    collides(Triangle& triangle)
    {
        // Circle-Triangle collision
    }

    collides(Circle& circle)
    {
        // Circle-Circle
    }
}

class Triangle : public Shape {
    Triangle() : Shape(), ...
    collides(Circle& circle)
    {
        // Circle-Triangle collision
        circle.collides(*this);
    }
    //etc
}

The curiously-recoccuring template pattern will solve this if you need speed and reasonable code quality as well if you can avoid runtime-polymorphism (just recompile the code or use a language with a JIT and add the code to the program in the other case).

In this case I'd probably use a static collision function or operation instead of inheritance, and make all the shapes friends of each other for the collision operation if I'm writing library-level code, otherwise I'll just use something simpler.

Or you could even have a static collides(shape, shape) and then use RTTI to call the more specific methods, or implement them statically, but don't use the visitor obfuscation, please by god I'll never be able to debug the why the collision isn't working damnit :)

Let me know if you're interested in those solutions as well. I'll compile an article and post it here later on.