__declspec(dllexport) question

Started by
8 comments, last by floatingwoods 15 years, 9 months ago
I have a collection of functions that I just exported in a dll. Everything compiles fine and links fine. Some functions work well (as before), others seem to work fine at first (the function executes without apparent error, but once the function returns and the function calling it returns too, there is a crash. What is wrong? Before, the functions looked like, at that worked fine:

bool algos_getConvexHull(
		std::vector<float>* verticesIn,
		std::vector<int>* indicesIn,
		std::vector<float>* verticesOut,
		std::vector<int>* indicesOut)
{
	return(CAlgos::getConvexHull(verticesIn,indicesIn,verticesOut,indicesOut));
}

Now, the exported functions look like that, and not all of them perform without crash (this one in particular is crashing):

__declspec( dllexport ) bool algos_getConvexHull(
		std::vector<float>* verticesIn,
		std::vector<int>* indicesIn,
		std::vector<float>* verticesOut,
		std::vector<int>* indicesOut)
{
	return(CAlgos::getConvexHull(verticesIn,indicesIn,verticesOut,indicesOut));
}

What can I have done wrong?
Advertisement
What sort of "crash"?

Generally speaking, passing non-const STL objects over a DLL boundary like that is A Bad Thing; it requires that the DLL and EXE both link to the exact same version of the CRT, and that they both link to the DLL version of the CRT. If you ever recompile the EXE on a different compiler, you'll need to recompile the DLL too.
Thanks for the reply.
In debug mode, the crash happens when some objects get destroyed just before leaving the function calling the exported function (it looks like the stack is corrupt). I also tried compiling both (the dll and the application calling the dll) with the same compiled but that didn't change anything.
Quote:Original post by floatingwoods
Thanks for the reply.
In debug mode, the crash happens when some objects get destroyed just before leaving the function calling the exported function (it looks like the stack is corrupt). I also tried compiling both (the dll and the application calling the dll) with the same compiled but that didn't change anything.
What objects are being destroyed? Are they local variables or on the heap? What's the exact error message you get?

If it's something to do with a heap corruption message, it's almost certainly caused by passing those STL objects over the DLL boundary. What CRT are you using (In project settings -> Linker I think, what is "Run time library" set to)? It should be multi-threaded DLL or multi-threaded debug DLL for this sort of thing (Which, as I said really isn't a good idea).
Thank you again!
I will check tomorrow if I set it to "multithreaded dll".
Otherwise the error is caused by objects created on the stack. I'll check the exact error message tomorrow too.
Well, I checked my settings and the situation looks as following:

I am not using any MFC functions nor anything special (the dll is making only calculations, nothing else fancy). It is also using std::vector. So I have settings: "not using MFC". In that situation, I can compile the dll only if the runtime library is in "multithreaded" mode. That should be fine, no? When setting it to "multithreaded dll" I can't compile it I get some linking errors of following kind:

nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc
and some additional errors also linked to nafxcwd.lib. I found following resource, but the article doesn't mention the case when MFC is not used:

http://support.microsoft.com/default.aspx?scid=kb;en-us;166504

I get same error when I try to use MFC in a static library (but I don't need MFC). When I set it to "use MFC in a shared dll", it compiles fine.

But, since I don't need any MFC stuff, I should be fine with "not using MFC" and "multithreaded", right?
What compiler are you using? Please don't say VC6...

Have you tried making a stripped down version of your app and seeing if that still has the MFC-related problems? Also, in debug builds, you should be using the multi-threaded debug runtimes, or the multi-threaded runtimes in release mode.
Well... I am using VC6!
Right now I am removing all data like std::vector in the interface to avoid problems as you suggested earlier. This might already give me some improvement
Quote:Original post by floatingwoods
Well... I am using VC6!
Right now I am removing all data like std::vector in the interface to avoid problems as you suggested earlier. This might already give me some improvement
I'd strongly recommend binning VC6. It's over a decade old, has some serious flaws, doesn't work with a lot of APIs (For instance, the DirectX SDK dropped VC6 support about 5 years ago), crashes frequently, has terrible template support, and produces terribly inefficient code.

VC2008 on the other hand is free, and doesn't have any of the above problems.

I wouldn't be at all surprised if your problem magically vanished from upgrading to a more recent compiler.
Well, I downloaded and installed VC2008 express and was surprised to see that it doesn't come with MFC! So at first I couldn't compile anything, but then I references all include and lib files from VC6 (a directory called VC98). stdafx and some other files get compiled, however with some other files I often get following error that seem not to be coming from me:

d:\vc98\mfc\include\afxtempl.h(776) : warning C4346: 'CList<TYPE,ARG_TYPE>::CNode' : dependent name is not a type
prefix with 'typename' to indicate a type
d:\vc98\mfc\include\afxtempl.h(776) : error C2143: syntax error : missing ';' before '*'
d:\vc98\mfc\include\afxtempl.h(776) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:\vc98\mfc\include\afxtempl.h(776) : fatal error C1903: unable to recover from previous error(s); stopping compilation

This topic is closed to new replies.

Advertisement