Quote:Original post by JamesKilton
The point of a shared/dynamic library is that you don't have to ever touch other code using that library UNLESS you're either a crappy programmer or the design was so bad that you had to change your API.

In a game development cycle, this is likely to only become true either late in the cycle, or after a library has been used through several cycles and has a standard use by the developers. Even this is likely to change from project to project. It sucks, but it really is the nature of things.

This doesn't forgive not writing solid interfaces and maintaining separation, but the reality is that even interfaces will likely have to change occassionally due to requirements changes, etc. The separation means that because the code base isn't rigid, and you should be able to fairly readily change the locations where the public API's are used and get through the interface with a minimum of pain.

Quote:
That's the point of a library, a public API which doesn't change while the internals are hidden and not connected to anything outside. While this works with a static library as well, again, such interconnectedness is a Bad Thing(tm). Do you understand that?

I guess I'm missing why linking a static library into the executable is an "innately" bad thing? As you've agreed, the benefits of a fixed public API are still there in a static library.

Now if you are talking about the desire to ship a binary only library with a public API for use by external developers (you are selling a library) that is going to be used by many executables, then a shared library might be better due to executable size reduction.

This is also particularly true for developers who will be distributing an executable over the wire that uses your DLL, thus saving costs on bandwidth (assuming the DLL is already installed on host computers).

Quote:
What's wrong with a single system version number? This feels like getting too bogged down in the details. Keeping of versions of everything, I feel, isn't necessary.

The problem with a single version number is that you have no way of knowing if the customer has grabbed a copy of one of the DLL's that is an older version and is using it with a newer version executable. If you have no way to know what each components version is, customer support won't know exactly what the customer is running.

Quote:
I think I had my mind wrapped around something else. You're right, it's just that I'm against the need to relink any executable.

No worries, my mind gets wrapped around all kinds of nasty stuff. :)

If you don't like re-linking, then I agree that shared libraries are the way to go.

Cheers!

Jeff

Quote:Original post by Puzzler183
I don't think people are getting the point. I know that a DLL can only be used on windows and that you use shared objects on Linux.

Sorry, let me be more direct.

Quote:
The thing I'm trying to figure out is:

1) Should I make one instead of just compiling with the engine code?

What do you hope to gain from shared libaries? From static libraries? How will they impact your engine?

One reason to use shared libraries is if you want to choose between two or more implementations of a component at run time (for example OpenGL or D3D), but don't want them to both be resident in memory at the same time.

Quote:
2) Which to make (or both)?

What you should do is write an API that is used to load up each component. The instance of this API will handle the details (in a hidden fashion), allowing you to load the component from a statically linked library, or to first load it into memory via a DLL and then create the component. This allows you to do one now, and the other later.

This is pretty much just a factory pattern. I'd just do one implementation for now (if not forever).

Quote:
3) Which to use for my purposes?

What are your purposes? All I know is that you are making an engine (this is a bit nebulous), and that you that you are interested in cross platform support. Doing dynamics doesn't really gain you much in cross platform support as you have to write the code either way. The benefits largely come from writing your components correctly so that they can be easily ported.

Quote:
4) How are classes exported under both Windows and Linux?

What do you mean? How do you access a class in a library?

One way in a DLL is at:

http://www.codeproject.com/dll/SimpleDll2.asp

Or you can write some standard C functions in each library that can give you instances of the classes for you. I'm pretty fond of doing a simple COM based system to get instances from a library (basically a class factory, and it's portable).

Best of luck!

Jeff