Sign in to follow this  

Decomposing my application into DLLs

This topic is 4856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I want to decompose my application into 3-4 different dlls for better maintainability, modularity and upgradability. For instance I wanna have: 1. math dll (including vectors, matrices with all operations and operator overloading) 2. collision detection dll 3. path planning dll 4. The main application using the math, collision detection and path planning dlls How can my parts 2,3 and 4 be aware of the classes and operator overloading in the math dll? I want to use my math dll as if I had it included in the main application (with automatic function name completion, etc.) Thanks :)

Share this post


Link to post
Share on other sites
If you're using Visual Studio .NET then you need to make a project for each of the DLLs and then include them all in the solution for your application. Any projects included in a solution will get Intellisense. Putting your math functions in a DLL may not be a good idea though. Many of your vector and matrix functions should be inline for performance and so they won't actually be in the DLL anyway. For functions that aren't inline there is extra overhead for calling functions in a DLL which you may want to avoid. On the other hand statically linking them into all the DLLS that use them could cause some code bloat so it's not a clear cut decision.

Share this post


Link to post
Share on other sites
I'd say it is a clear cut decision. Sure, you'll end up with slightly larger DLL's by inlining the math functions but the speed difference for such low-level and often used functions will more than outweigh the slight code bloat.

Share this post


Link to post
Share on other sites
Thank you both!

I didn't think about the inlining problem... So I'll have the math classes inside each of my dlls (collision detection, path planning) and inside the main application. This is a redundancy of 3. Big problem?

Also, by doing so, how can I guarantee that if I modify the math classes it gets modified for the other projects using it too?

Share this post


Link to post
Share on other sites
Quote:
Original post by joanusdmentia
I'd say it is a clear cut decision. Sure, you'll end up with slightly larger DLL's by inlining the math functions but the speed difference for such low-level and often used functions will more than outweigh the slight code bloat.

Obviously you want to inline the majority of common functions whether you're using a DLL or not - things like vector operators, dot products, etc. What I meant is that if you use a DLL rather than statically linking then for functions that aren't inline (either because they're seldom used or because the cost of the function outweighs the cost of the call, like inverting a matrix) then you get a little more function call overhead than you would with static linking. Whether that's a big deal or not for those functions you don't inline is not a clear cut decision I don't think. You're right though - it's clear cut that you absolutely should inline all the common, simple functions.

One other possible reason not to inline is for functions that can benefit from special instruction sets (SSE, SSE2, SSE3). If you want to decide at runtime which function to call depending on what processor you're running on then inlining becomes problematic. That doesn't really affect the question of whether to use DLLs or not though.

Floating - like I said above, you want to inline your common simple functions whether you're using DLLs or not so the code bloat isn't really an issue there - you'll have it with static or dynamic linking. The only additional bloat from the DLL route is from those functions that aren't inlined and unless you have a really large number of DLLs or a huge math library I don't think it will be a big deal. If your math library has a lot of inline functions though there's not much to be gained from a DLL - you still have to recompile everything that uses it if you change a header file and since most of your functions are inline that will be a frequent occurrence until your math library is very stable.

Share this post


Link to post
Share on other sites
Thanks a lot again :)

One last question: if I do like you say, how do I integrate the math part into my different sub-applications? As I see things, I will have to create a dll project for the collision part and a dll project for the path planning part, but both will have to contain the math code. That is ok, but simply copying the math classes would be stupid. How can I share that math code between 2 or more projects? Do I have to put everything into a solution? How does that work?

Share this post


Link to post
Share on other sites
Quote:
Original post by Floating
Thanks a lot again :)

One last question: if I do like you say, how do I integrate the math part into my different sub-applications? As I see things, I will have to create a dll project for the collision part and a dll project for the path planning part, but both will have to contain the math code. That is ok, but simply copying the math classes would be stupid. How can I share that math code between 2 or more projects? Do I have to put everything into a solution? How does that work?


Just add the same files (eg. vector.h, vector.cpp, matrix.h, matrix.cpp) to all the projects that use them. You don't need multiple copies of the same files. For organisation you can keep all your math header/source files in a 'Math' directory.

Share this post


Link to post
Share on other sites
If I were you, I'd make several static .lib files, not .dlls. With .libs, they'll be linked with your application, so you get no overheard from calling into a DLL (a big thing for operations like vector addition, matrix multiplication, etc).
I'm not sure about what various MSVC versions do with optimizing, but it should be as good as if you just had all the code in the main application.
Actually, for the math functions, just put everything into the header files (or make a .inl file if its neater, and #include it from the header), and declare all the functions as inline (even the huge functions). If the compiler decides its not worth inlining (e.g. matrix inversion), it won't bother. But if it decides it is worthwhile (constructors, vector addition, etc) it has the option.

Share this post


Link to post
Share on other sites
I agree. Do not use DLLs if you can possibly achieve what you want without them.

Upgradability is a non-reason, putting a new .exe is just as easy and likely to be necessary anyway.

Static libraries will work fine and not have the ick factor associated with DLLs. Specifically, you won't need to worry about DLL exporting your functions, or if certain things don't work properly across DLL boundaries.

Loads of people assume that if they are going to have several different application roles (like game, editor, configuration settings, network server) for their application, they need to produce more than one .exe file. This is not true, it is pretty easy to have a single .exe which behaves differently depending on how it is invoked. And doing so produces a smaller binary than the multiple binaries would be, even if they shared some of their code in DLLs.

Mark

Share this post


Link to post
Share on other sites

This topic is 4856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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

Sign in to follow this