Sign in to follow this  
discman1028

Module dependencies in C# (would be nice)

Recommended Posts

I miss static libraries from C++. You could make a 'core' static library that pretty much everything depends on, and then a 'gfx' library that depends on 'core', and then a 'physics' library that depends on 'core' and 'gfx'. The compiler will prevent 'core' from ever depending on 'gfx'/'physics', and 'gfx' from ever using any of 'physics', etc. You can do the same in C#, but each module must be a DLL -- no good for a vector library where you want each short routine to inline by the JIT if possible. (I assume the JIT is c*ck-blocked at least a little by the DLL separation.) So my question is: in C#, is there a way to create some non-DLL vector classes in that I can assure never makes a call into my non-DLL 'gfx' classes? That is, how can I introduce some kind of 'code module dependencies' in C#? (I'm happy with using a single .csproj as long as I can do this!) (For now, I just separate groups of .cs files into folders, but that's not strictly enforcing any hierarchy at all.)

Share this post


Link to post
Share on other sites
Hmm, I realize namespaces could be a potential answer here. Still requires some user discipline though, and there's no sure way to verify the hierarchy.

Share this post


Link to post
Share on other sites
Quote:

You can do the same in C#, but each module must be a DLL -- no good for a vector library where you want each short routine to inline by the JIT if possible. (I assume the JIT is c*ck-blocked at least a little by the DLL separation.)

Not really. The fact that everything sits in DLLs is not really a huge concern. The JIT sucks at inlining most things anyway -- value types in certain places? No dice. Code above some certain small threshold of bytes? No dice.

Furthermore, static libraries aren't any more amenable to having their already-compiled code inlined in by the compiler (only, in some cases, the linker).

Quote:

So my question is: in C#, is there a way to create some non-DLL vector classes in that I can assure never makes a call into my non-DLL 'gfx' classes?

No, other than writing sane code. I understand the concept you are asking for is probably a bigger concern for you, but this particular example is relatively foolish. Why on earth would you write vector code that called into the renderer? That's just careless.

But since your assumption about the JIT and inlining is bogus (owing largely to the fact that the JIT is probably not inlining stuff anyway), is there some other reason you don't want to make separate assemblies? That's exactly what assemblies are designed for.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie ...this particular example is relatively foolish. Why on earth would you write vector code that called into the renderer? That's just careless.


It's a pet example, there are cases where it's not so black and white.

Quote:
Original post by jpetrie
But since your assumption about the JIT and inlining is bogus (owing largely to the fact that the JIT is probably not inlining stuff anyway), is there some other reason you don't want to make separate assemblies?


Nope, performance was the only reason. I had read that the JIT will inline simple funcs but hadn't checked any IL yet to be sure.

Share this post


Link to post
Share on other sites

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