K
kilroytrout
When trying to use some unmanged C++ libs in a VS 2005 Release
Candidate Windows Forms (/clr) project, I found that any dynamic
initialization in the lib's global STL objects (perhaps other C++
objects as well) create an exception at startup. Has anyone seen this
or know a workaround?
For example create a simple /clr C++ console app:
#include "unmanaged.h"
int main(array<System::String ^> ^args)
{
unmanaged_foo(); // empty func. to get linker to include library
globals
return 0;
}
Then create an unmanaged static lib with the header...
// unmanaged.h
void unmanaged_foo();
And the cpp file...
// unmanaged.cpp
#include <vector>
std::vector<int> stlVect;
void unmanaged_foo(){}
Compile the lib, and then compile and link the console app with the
unmanaged lib using /MDd (or /MD) and run. You'll get an exception in
the dynamic initializer for stlVect. I know in VS 03 there were some
issues with the and mixed mode C++ DLL's, but this is an EXE.
Tell me I'm missing something. It seems likely that various static libs
developers might use will have this problem if they're native and
linked into /clr projects. Recompiling them to /clr is not always an a
viable option.
--jeff
Candidate Windows Forms (/clr) project, I found that any dynamic
initialization in the lib's global STL objects (perhaps other C++
objects as well) create an exception at startup. Has anyone seen this
or know a workaround?
For example create a simple /clr C++ console app:
#include "unmanaged.h"
int main(array<System::String ^> ^args)
{
unmanaged_foo(); // empty func. to get linker to include library
globals
return 0;
}
Then create an unmanaged static lib with the header...
// unmanaged.h
void unmanaged_foo();
And the cpp file...
// unmanaged.cpp
#include <vector>
std::vector<int> stlVect;
void unmanaged_foo(){}
Compile the lib, and then compile and link the console app with the
unmanaged lib using /MDd (or /MD) and run. You'll get an exception in
the dynamic initializer for stlVect. I know in VS 03 there were some
issues with the and mixed mode C++ DLL's, but this is an EXE.
Tell me I'm missing something. It seems likely that various static libs
developers might use will have this problem if they're native and
linked into /clr projects. Recompiling them to /clr is not always an a
viable option.
--jeff