That's a very good question, mismatches in utility classes (vectors, matrices or even containers) between libraries is often an overlooked issue.
I wouldn't try to modify SFML or Box2D:
- Your own utilities classes might be missing a few features that those libraries rely on;
- If you need to update your libs to integrate some new features or bugfixes, you'll have do re-do all that work again.
What you should do is wrap those libraries in classes of your own, so that other parts of your engine can manipulate them without "polluting" everything with external dependencies. E.g. if you need to use a function that requires a
Box2D::Vector2, don't rewrite it, instead wrap it in a function that requires a
// this is declared by Box2D
void Box2D::DoStuffWithVector2( Box2D::Vector2 foo )
// this is a wrapper function for your engine
void hayer::DoStuffWithVector2( hayer::Vector2 foo )
Box2D::DoStuffWithVector2( hayer::ConvertToBox2D( foo ) );
You don't have to wrap everything though, just wrap what you need when you need it, iteratively. You won't need everything in the library interface, so that's the best way to limit the code size. I'd say that creating this kind of "glue code" is roughly the same amount of work than rewriting the libs, but it brings much more benefits:
- Changing libs (e.g. from Box2D to another physics lib) will be easier, as you'll just have to modify this "glue code";
- You'll be able to integrate new features or bugfixes from your external libs almost instantaneously.
Doing a separate .lib for your utility classes is a good idea, it'll keep a good modularity and can't do any harm. And it'll fit in that model as well.