Sign in to follow this  
TheUnbeliever

DLL questions

Recommended Posts

I'm fumbling around with DLLs for the first time here with a personal project, and have a couple questions. 1. I'm getting lots of warnings like "warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'lgLCD::BitmapException'" and "warning C4251: 'lgLCD::LCD::device' : class 'std::auto_ptr<_Ty>' needs to have dll-interface to be used by clients of struct 'lgLCD::LCD'" with both the standard library (as here) and boost classes being specified as the problem. Can I safely ignore these, since the clients will have these available to them at the end, or is there some issue that will require me to manually go through and add LGLCD_API to their signatures? 2. Is there some way of listing all the exports of a DLL, without the source? 3. To compile code that uses the DLL, I just need to have the header file (with __declspec(dllimport) as necessary) in the include path, and the DLL in the linker's library path? (I'm particularly dubious about the 'DLL in the linker's library path' part)

Share this post


Link to post
Share on other sites
First a word of warning: mixing C++ features and DLLs opens the doorways to worlds of pain. Seriously consider making the DLL interface as minimal as possible, reducing the interface as close to C style as you can.

1) This isn't strictly necessary as long as you can guarantee that all modules (executables and DLLs) that will be linked together at runtime share the exact same compiler; are compiled with the exact same settings with the exact same header files.

If any of those aren't the case then you've got potential major problems.

Even if you don't have any of those issues or export the base classes, then you still may have problems with doing things like passing objects by value over module boundaries. You'll also generally end up with duplicated code between the executable and the DLLs, but that isn't a major issue. RTTI however will not behave as you might expect.

2) Depending on your toolchain different functions can do this. For example, Visual Studio users can use dumpbin /exports to get the exported symbols from a DLL.

3) The DLL does not need to be in the linker path. The DLL's export library needs to be in the linker's path (or added explicitly to the project that is linking against the DLL), unless the user uses LoadLibrary()/GetProcAddress() for all functionality.

Share this post


Link to post
Share on other sites
Ah, thank you very much – the answer to 1 was what I worried it might be. However, it looks like this may be more effort than it's worth, particularly as heading towards a more C-style library subverts the whole point of this.

Does the awkwardness with C++ libraries persist if I switch to using a statically-linked library? If so, I may just leave this as-is.

Again, thanks for the full and succinct response.

Share this post


Link to post
Share on other sites
Just to add to SiCrane's points:

Quote:
Can I safely ignore these, since the clients will have these available to them at the end, or is there some issue that will require me to manually go through and add LGLCD_API to their signatures?

You should be fine for your templatized types, and in fact you generally don't want to add _declspec(dllexport) to those, unless you have specializations (in which case you'll generally get linker errors if you don't use).

As SiCrane said, it does open the doorway to some pain, but I find the dll approach too useful in a tools pipeline NOT to use it, and I use full C++ functionality; on the other hand, I'm able to guarantee (as SiCrane mentioned) that all the libraries are compiled using the same compiler, headers, etc. The primary benefit for me is in allowing extensibility of certain applications using a plug-in approach; if you're not after this kind of extensibility, it might be overkill.

Once you get everything setup, it's not bad in practice. The biggest pain I've found is in converting a library (or libraries, plural) to be created as dlls, making sure to have separate output file names for release/debug (this is a minor point, but important if you have multiple projects, and you rebuild in debug, then switch to release, and build only one project; you'll get conflicting dll builds, unless they're going to separate out files, i.e., mydll.dll and mydlld.dll).

Also, as SiCrane mentioned, beware of RTTI:
http://www.gamedev.net/community/forums/topic.asp?topic_id=479183

Share this post


Link to post
Share on other sites
Static libraries don't suffer from nearly as many problems as dynamic link libraries as far as C++ features are concerned. If you want to use template and other inline defined classes, though, the static library and the application should still be compiled with the same version of the compiler and the same headers and so on. However, you don't run into issues with passing objects by value or weird RTTI behavior.

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