Solving internamespace and dll issues...
Author
Hello Community,
I'm having some namespacing issues. Every namespace has it's own project in my engine, and therefore, gets exported into a separate dll. However, some of my classes are causing circular dependencies. For example, I have a class Point, which obviously stores a point in screenspace. This typically applies to graphics, which has it's own namespace Graphics. This would go into the project exporting the graphics api. The graphics project is dependent on the base project. But if I feel that a given class should be a part of the base class but requires the Point class, I'm stuck. How can I resolve these internamespace conflicts?
Thanks for any assistance[smile],
Chad Seibert
I would say: how can a point be considered as a graphic entity? In mathematics, a point has no size - only a position. That hardly make it a graphic entity. Pixels have position too, but they also have other intrinsic data - such as the color, for exemple. So a pixel is not a point - it has coordinates, which can be represented as a point.
So my advice is to put mathematical entities in they own namespace - that sounds more logical anyway.
More generally, the idea to resolve this kind of namespace circular dependencies is to think about abstraction. Robert C. Martin published an interesting article about Design Principles and Patterns (here, PDF) and a chapter in this article is directly speaking of your issue (and how to handle it) (chapter "Acyclic Dependencies Principle"). In fact, the whole article is worth a read, so I encourage you to give it a look.
Best regards,
So my advice is to put mathematical entities in they own namespace - that sounds more logical anyway.
More generally, the idea to resolve this kind of namespace circular dependencies is to think about abstraction. Robert C. Martin published an interesting article about Design Principles and Patterns (here, PDF) and a chapter in this article is directly speaking of your issue (and how to handle it) (chapter "Acyclic Dependencies Principle"). In fact, the whole article is worth a read, so I encourage you to give it a look.
Best regards,
Author
Thanks for your reply, that article did provide some very good insight on engine development. However, this seems to be overly complicated for something as simple as a point. Is duplication of small classes terrible?
Thanks[smile],
Chad Seibert
Thanks[smile],
Chad Seibert
Quote:Original post by Chad Seibert
Is duplication of small classes terrible?
It's worse than terrible. What happens when you update the class in one namespace and forget to update it in another? Very bad idea.
Author
I'm having a hard time abstracting away a point class. I see how I can create an abstract interface as a base, and implement it across namespaces's. However, for very simplistics structures like a point, which can be defined as:
it seems to be overkill by a long shot. That's why I asked whether code duplication for small classes and structures is terrible or not. This 'Point' class could be defined in a different namespace, and typedef'd in the most logical one for use outside of the engine. For example:
Maybe I'm not seeing the real picture here, but is this such a terrible way to deal with cross namespace duplications?
Thanks for the great advice[smile],
Chad Seibert
struct Point{unsigned int X, Y;}it seems to be overkill by a long shot. That's why I asked whether code duplication for small classes and structures is terrible or not. This 'Point' class could be defined in a different namespace, and typedef'd in the most logical one for use outside of the engine. For example:
namespace EngineImp{struct PointImp{unsigned int X, Y;}}//Now define it in Engine::Mathtypedef PointImp Point;Maybe I'm not seeing the real picture here, but is this such a terrible way to deal with cross namespace duplications?
Thanks for the great advice[smile],
Chad Seibert
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
