• Advertisement
  • entries
    422
  • comments
    1540
  • views
    489251

Request for comments...

Sign in to follow this  

64 views

I might start a forum thread on this later, but I want to do a bit of research on it first before opening it up for more widespread comment...

F1CM's codebase is one huge monolithic C++ solution/project. Currently weighs in at around 30,000 lines over ~100 files. Thats just the framework - once I drop the game on top it'll probably triple or quadruple in size.

Monolithic project works fine for me as the single developer/owner. Not so great when we're looking to get multiple developers involved. Yeah, bad design on my part [embarrass].

I want to break the solution up into seperate components. Obvious advantages really:
  • Reduced compile time
  • Stabilise components seperately
  • Easier concurrent development - less chance of multiple developers breaking each others stuff
  • More manageable (both from usage and error point of view)


Thing is, I'm not sure what the best route is to achieve this.

I dont really want to change too much of the architecture if I can avoid it. It's too late in the project for that now - even if it is a hacked up cringe-worthy job that'll be fine.

From preliminary research I have two choices: Static or Dynamic Libraries.

I could rip out the Graphics/Audio/Log/Logic/GUI/Kernel stuff into seperate components. They're already fairly well compartmentalised (sadly, with use of Singleton design patterns).

Currently static .LIB files seem like the best choice. Still requires a re-link of the main executable, but I can live with that. Final executable is therefore relatively similar to what we have now - monolithic blob.

DLL's sound like the better option as it should allow for less re-compilation and a bit more clearly defined separation. What I don't fully understand at the moment is any issues with crossing the EXE<->DLL<->DLL boundaries. Throwing class instances and data around between components etc...

Anyone got any suggested reading/advice on this topic?
Sign in to follow this  


3 Comments


Recommended Comments

You can effectively ignore the problem of passing things over a DLL boundary if all the DLLs are linked to the same version of the DLL version of the CRT. If you're managing the whole thing, that's probably your best bet.
If you're not managing everything, or the DLLs could link to different CRT versions (On different compilers), then you have two choices:

  1. Modularize everything - which will most likely be a pain. You won't be able to pass STL objects between DLLs unless it's by constant reference, and you won't be able to allocate memory in one DLL and use it in another.

  2. Create your own custom [de]allocator that sits in a DLL of it's own (perhaps the core DLL if there is one). That means that every STL object has to use that allocator too, to allow you to pass STL objects over a DLL boundary.

Personally, I'd go for #2. There's always problems with #1 that you tend not to find out till later on, and it'll be a bitch to implement on top of an already large project. I also don't like static libs that much, it's just cheating really. All you're doing is breaking the EXE into smaller chunks to develop on and then gluing them together at the end.

Just my 2p. It's probably worth posting a thread somewhere about this...

Share this comment


Link to comment
Thanks for the comments.

I'll probably be posting about this in the forums once I've gathered a bit more information and tried out a few options. Try and start a thread with as much context as possible [smile]

Quote:
You can effectively ignore the problem of passing things over a DLL boundary if all the DLLs are linked to the same version of the DLL version of the CRT.
I'm quite content with forcing VC++ 8 on people. I'm using Pro or Team System and the rest can grab Express Edition...

Quote:
I also don't like static libs that much, it's just cheating really. All you're doing is breaking the EXE into smaller chunks to develop on and then gluing them together at the end.
Agreed, but this is more about making it easier for multiple developers to "co-exist" on the project than good software engineering practice. It's too late for that [oh]

There are other, substantially more horrific (Functions with parameters are for losers), things in the codebase that kinda make this sort of problem rather irrelevent by comparison [lol]

One thing I just realised with the LIB idea is that if there are *lots* of dependencies (quite likely) then a full recompile is going to be required anyway.

Presumably the same scenario with DLL's wont be so much of a problem unless the *interface* changes.

Cheers,
Jack

Share this comment


Link to comment
Thanks for the comments.

I'll probably be posting about this in the forums once I've gathered a bit more information and tried out a few options. Try and start a thread with as much context as possible [smile]

Quote:
You can effectively ignore the problem of passing things over a DLL boundary if all the DLLs are linked to the same version of the DLL version of the CRT.
I'm quite content with forcing VC++ 8 on people. I'm using Pro or Team System and the rest can grab Express Edition...

Quote:
I also don't like static libs that much, it's just cheating really. All you're doing is breaking the EXE into smaller chunks to develop on and then gluing them together at the end.
Agreed, but this is more about making it easier for multiple developers to "co-exist" on the project than good software engineering practice. It's too late for that [oh]

There are other, substantially more horrific (Functions with parameters are for losers), things in the codebase that kinda make this sort of problem rather irrelevent by comparison [lol]

One thing I just realised with the LIB idea is that if there are *lots* of dependencies (quite likely) then a full recompile is going to be required anyway.

Presumably the same scenario with DLL's wont be so much of a problem unless the *interface* changes.

Cheers,
Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement