My manager wants me to refactor a gigantic amount of terribly-coupled, macroed, full of private namespace methods, hierarchy-perverted (even 10+ levels of inheritance) code which hasn't been (indeed) designed with a "whole-vision" concept.

I tried to explain to him that this code needs to be rewritten, not just refactored but he didn't listen and stated explicitly that I need to refactor it.. somehow.

I could dive into all the "dealing with legacy code" books but I think nothing useful would come out.

How can I convince him that a rewriting, instead of a refactoring, is actually needed?

He's probably right.

If the codebase is so monstrous, so gigantically complicated, so difficult to understand... what makes you think you can write something that does the same thing correctly?

Generally a big refactoring is the best place to start - start ripping bits out and combining them into reusable chunks; tidy up the code so its easier to view; flatten the inheritance hierarchy and remove the dangling edge-cases; combine the namespaces; unroll the macros; whatever it takes to turn the big mess into a reasonably understandable system.

You have to understand it before you can rewrite it - otherwise you will just end up with a different mess. 
