Exporting STL templates from DLLs

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Exporting STL templates from DLLs

      Was just wondering if there is a best practice for using stl templates in cross dll situations such as returning std::string from class methods. I get a compiler warning in my project and havent really found a good solution to the issue. I have read that the warning can be ignored if all code was compiled with the same compiler version, but could cause issues in cross platform environments. Maybe I should only use char* on methods that are being exported?
    • I don't have a huge amount of experience with DLL's since I avoid them like the plague (as do most game companies I've worked for), but I seem to recall that you generally want to use primitive types in functions that cross the boundary.

      -Rez
    • I got the DLL idea from the Ogre3D project. Where most of the major components of the engine are plugins that are pulled in dynamically at run time using a config file.

      Is this an uncommon approach from your experience? I was thinking about making my logic and views their own module, like plugins to the engine. I want to make sure i'm not falling into the trap of learning something cool and wanting to apply it to everything even when it doesn't fit, kind of like the singleton pattern. :D
    • I believe objects created with STL templates are generally compatible in environments where DLLs were created with, say, GCC and the consuming application was created with Visual Studio.

      With strings, though, you have to be cautious, since you want to make absolutely sure the string format (ASCII, UTF-8, etc.) is the same on both sides. C++ std:wstring should be compatible across different compilers targeting the same architecture if you need to support Asian or other ideographic languages. Straight Latin based alphabets can use std::string.

      When you say cross-platform, I assume you mean different processors/operating systems - like Mac vs. Windows machines. In those cases the compiled result won't be compatible since the target architecture will be different. In those cases you'll want to use an interpreted language or even C#.

      Looking over my answer I think I may have confused the issue! I hope I didn't.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • I don't think you did, but to make sure. You are saying to push any actual string operations out to an interpreted language (LUA in the books case), and in the compiled code use only string identifiers from some sort of resource cache and hashed strings to abstract any encoding or platform differences?
    • Terribly sorry - I didn't mean you have to do that.

      I think the easiest thing to do is just throw your strings into UTF-8 encoded XML files, and read them into your game with std::wstring.

      As far as DLLs are concerned, I don't think you need a special DLL just to load strings. I'm with Rez on staying away from DLLs unless they are absolutely needed, such as when you might want to load one at runtime....

      Perhaps you can expound a bit on what problem you are trying to solve?
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • I am mostly just trying to decide on how I want my engine to run. Initially, I started writing a DLL that contained most of my application layer that would also dynamically load a particular game DLL from a configuration file at run time. After its loaded the game would register its self with the applicatoin library and off we go.

      The current application layer DLL gives me a bunch of warnings regarding std::string needing a DLL interface. I want to know if there is some sort of best practice when it comes to writing DLL's and which data types one should export, though after talking to you guys I have started considering what I gain by loading these things a run time, and I can't think of any real benefit. I can compile the application layer in its own static lib and, at the very least, reduce the complexity of the code. Once I write the game logic and views the application layer library will have to remain static for that particular game anyway.

      I am at work so I don't have access to my code but I found an example of the warning I am getting on the web in case you are interested. In this example they are using std::list but I get a similar message for std::string.

      Source Code

      1. warning C4251: 'MyClass::mylist' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'MyClass'

      The post was edited 3 times, last by superkent ().

    • Most games I've worked on don't use DLL's. I just glanced at our bin directory here on The Sims and the only DLL's are for DirectX, and internal performance kit tool, and a web kit tool. The latter two are purely internal and were made into DLL's for ease of deployment & integration (they're made by a central tech group that I don't think is in this building).

      Using a DLL adds complexity to your code and costs you run-time performance. You should only use DLL's to solve a specific problem you are having. This is especially true if you're new to making games. Why add to the complexity of what you're learning for little or no gain?

      -Rez
    • Just to put a finishing nail into this subject - check out this article. It describes the problem really well.

      stackoverflow.com/questions/56…s-needs-to-have-dll-inter

      Basically, don't use DLLs if you are exporting "everything" - just compile and link.
      Mr.Mike
      Author, Programmer, Brewer, Patriot