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.

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.

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.

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.