I was just wondering if there would be a way to export a templated class into a DLL. Mainly because I want to wrap ID3D11Buffer. The other way would be to store things to be copied to the buffer in a std::vector<void*> and do some smart copying when you call Map(). If it were possible to export a templated class that would allow me to keep my vertex/index data inside std::vector<T> and just do a single memcpy, let me know.

Thanks in advance,
Sepiantum.

Follow and support my game engine (still in very basic development)? Link

If you're willing to include the template header in the DLL client code, and willing to use explicit instantiation, then yes, it can be done - provided you ensure that you use the same compiler (down to the version/service pack number) for both the DLL and the client code. Outside of that, it's really not practical.

Actually, it's worse than that. You also need to make sure both client and DLL use the same compiler settings. In particular standard library containers can look significantly different between debug and release.

Actually, it's worse than that. You also need to make sure both client and DLL use the same compiler settings. In particular standard library containers can look significantly different between debug and release.

The change in class size is the important factor, and not specifically templates (It just so happens that STL containers/iterators contain additional data in debug, which isn't present in release). This can and does cause problems when mixing debug/release DLLs, but only occurs when you are doing that. If you only ever run a full debug build, or a full release build, you can safely ignore this problem (on VC++ it generates warning C4251). For what the OP wants, unless he intends to ship the DLL as part of some API or modding toolkit, he can probably just get away with ignoring the problems (it's perfectly safe to do so in this case).

To be perfectly honest though, if your DLL interface depends on some code not shipped with your DLL (std::vector / boost headers etc), then you're doing it wrong anyway. It's just too much of a nightmare dealing with numerous people wanting to use their own preferred STL implementation, or a specific boost version, etc. It's just better to not allow that to happen by writing DLL interfaces that DONT depend on 3rd Party code.

If it's your own template, and it's size is the same in Debug & Release, then there are no problems exporting specialisations from your DLL.If the class changes size between debug and release, then you will never be able to safely mix debug/release DLLs. If the template is mainly small inline funcs, then you'd be better off not exporting it at all.

If it's your own template, and it's size is the same in Debug & Release, then there are no problems exporting specialisations from your DLL.

You're still making assumptions about answers to questions that the OP hasn't bothered to give. For example, the whole whether or not the compiler for the client of the DLL is going to be the same as the compiler for the DLL. If he wants to use MSVC 2010 for one and BCB 3 for the other then there are going to be issues. And settings with impact on the size of classes in Release vs. Debug aren't the only relevant compiler settings. For example, good luck getting a 64-bit DLL to work with a 32-bit compiler. If you don't bother to specify the calling conventions on your functions, a DLL and a client that uses different default calling convention flags is going to give a lot of fun runtime errors. And so on.

If it's your own template, and it's size is the same in Debug & Release, then there are no problems exporting specialisations from your DLL.

You're still making assumptions about answers to questions that the OP hasn't bothered to give. For example, the whole whether or not the compiler for the client of the DLL is going to be the same as the compiler for the DLL. If he wants to use MSVC 2010 for one and BCB 3 for the other then there are going to be issues. And settings with impact on the size of classes in Release vs. Debug aren't the only relevant compiler settings. For example, good luck getting a 64-bit DLL to work with a 32-bit compiler. If you don't bother to specify the calling conventions on your functions, a DLL and a client that uses different default calling convention flags is going to give a lot of fun runtime errors. And so on.

I'm pretty much assuming that people are going to use the latest version of MSVC. I normally don't add debug only data and haven't done that yet, so that won't be a problem. And finally, it's not that hard to build 32-bit or 64-bit versions of the same dll, as I don't use 32-bit or 64-bit only functions.

Follow and support my game engine (still in very basic development)? Link