Class naming and namespaces

Question

Will using same class name within multiple namespaces get me into trouble? I also try to remove dependency to math library. What do you think about following design.

first file

#define MATH_RECTANGLE_EXISTS

namespace math {

    class Rectangle : Object2D {
    public:
         float perimeter();
         float area();

         float x,y,w,h;
    };
}

other file

#define GRAPHIC_RECTANGLE_EXISTS

#ifndef MATH_RECTANGLE_EXISTS
     //is this a good idea to remove dependency?
     namespace math {
   class Rectangle {
   public:
    float x,y,w,h;
   }
     }
#endif

namespace graphics {

 class Rectangle : math::Rectangle {
 public:
  void Draw(Canvas &canvas);

  void Translate(float x, float y);
 };
}

EDIT

What about this approach to remove dependency?

** 1st file**

namespace common {
   class Rectangle {
       float x,y,w,h;
   };
}

math lib file

#define MATH_RECTANGLE_EXISTS

namespace math {

    class Rectangle : public common::Rectangle, public Object2D {
    public:
         float perimeter();
         float area();
    };
}

graphic file

#define GRAPHIC_RECTANGLE_EXISTS

namespace graphics {

#ifndef MATH_RECTANGLE_EXISTS
 class Rectangle : public math::Rectangle {
#else
 class Rectangle : public common::Rectangle {
#endif
 public:
  void Draw(Canvas &canvas);

  void Translate(float x, float y);
 };
}

Thanks in advance.

Answer 1

I don't see the problem with reusing the same identifier within different namespaces, that was they were created for after all.

However I would strongly urge you NOT to 'simulate' the inclusion of math::Rectangle. If you need the file then include it, but what you are doing is called copy/paste programming, and it leads to a good number of problems, essentially because your two pieces of code are not synchronized so any bug fix / feature addition to one is not reported on the other.

EDIT: answer to the Edit ;)

It is not clear from the comments so I will state it:

If you need the dependency (because you really USE the functionality offered), then you HAVE to include the header. On the other hand, if you only use inheritance to get something that have 4 corners and nearly no method, then you're better up rolling a new Rectangle class with the minimum functionality.

I can think of an edge case though. I am under the impression that you are not so much interested in the functionality but in fact interested in the possibility of reusing the methods in the Math library that have been tailored to take a math::Rectangle as a parameter.

According to Herb Sutter (in C++ Coding Standards I think), the free functions that are bundled with a class are part of the class public interface. So if you want those classes, you actually need the inheritance.

---

Now I can understand that you may have some reluctance in including a library that may be huge (I don't know your Math library). In this case you could consider splitting the Math library in two:

• A MathShapes library, comprising the basic shapes and the methods that act upon them
• A Math library, which includes MathShapes and add all the other stuff

This way you would only depend on the MathShapes library.

On the other hand, if you absolutely do not want the dependency, then a blunt copy/paste will do, but your solution of testing the presence of Math::Rectangle by testing the presence of its header guard is ill-fitted:

• It only works if you get the header guard correctly
• AND if the include is actually performed BEFORE the include of Graphics::Rectangle

Note that in the case in which Graphics::Rectangle is included before Math::Rectangle you may have some compilation issues...

So make up your mind on whether or not you want the dependency.

Answer 2

That is rather what namespaces are for, and a rectangle is both a mathematical and a graphical object.

The attempt to avoid including a header file however is very ill-advised. It achieves nothing other than a maintenance headache. A change in math::Rectangle should cause a rebuild of graphics::Rectangle - if they end up in a mismatch and you hide that from the compiler, you'll end up with a harder to debug run-time error.