Pure virtual operator

Figabs contains a pure virtual member function virtual Figabs operator +()=0; this means you cannot instantiate Figabs

consider:

virtual Figabs& operator +()=0; 
/*Now you will not be returning an actual instance but can return derived class instances*

As other posters have pointed out, the assignment is far from trivial, and operator+ isn't normally a member. There are two issues which should be addressed:

1. If you support `FigAbs + Coord`, then you should also support `Coord + FigAbs`. The first can be a member (there's no real problem there); the second, if it is to be a member, must be a member of `Coord`, which is probably not what is wanted.
2. Any reasonable implementation of `operator+` must return by value. And you can't (normally) return a polymorphic class by value; you need something like the letter-envelope idiom for this to work: the base class must look something like:

   class Figure : BinaryOperators<Figure, Coord>
   {
       Figure* myImpl;
   public:
       Figure& operator+=( Coord const& translation )
       {
           myImpl->operator+=( translation );
           return *this;
       }
   };
   

   Of course, you'll need factory methods for correctly instantiating `Figure` for each different type, a virtual `clone` function, and copy constructor, assignment and destructor which support deep copy. (`BinaryOperators` is a template class which implements `operator+` in terms of `operator+=`; this is the usual way to provide the binary operators.)

Finally, I would argue that this is operator overloading abuse. The notion of addition doesn't apply to geometrical figures. What you're doing is called translation, and the logical solution is to provide a member function which does it, not to overload addition.