Hello. We have a native C++ .lib that we have created that uses a
const string in it. The string is initialized to "". We
have successfully linked this native library to a managed Windows C++
Forms project and have code in the form to instantiate one of the
objects defined in the native library. However, when the Forms
application starts, it attempts to instantiate the const string in the
native library and a _CrtIsValidHeapPointer assertion fails. Has
anyone seen this behavior Admittedly, I am new to .NET and have
been looking for a compiler switch that might address this issue.
Does anyone have a suggestion how we might successfully use this native
library without modifying it or recompiling it It may come down
to us begin forced to recompile the native library as a managed one but
we would prefer to avoid that if possible. Thank you!
-Matthew
Initializing statics in native library
Hot Topic
- Incompatibility between VC++ 2005 and C++ compiler from platform SDK
- How to convert unmanaged Recordset20Ptr to managed IntPtr or to managed DataSet object
- UNICODE and RichEdit control
- malloc error in C
- Importing and exporting functions from DLLs in VC++6.0
- Dynamically allocated ostringstreams? Getting C strings from ostringstream instance
- Unresolved Token and other link errors when migrating from VC++ 2003 to VC++2005 Express
- Build a console program for AMD Athlon 64 bit
- HI there I FIND a BUGS In VC6 .. and i think its soo big that One should never Use VC for any development
- Getting Error - Regarding stdafx.h
Visual C++
- SOS:VC2005 B2 Express VC++ Directories Problem
- msvc ++ 5.0 or 6.0
- srand
- msvcr80.dll Problem
- Please HElp With LPCWSTR
- Missing Class Designer for VS2005 C++/CLR projects
- Registry editing
- controlling user input
- UB in macros? (MS VC compiler does unbelievable tricks)
- System::Object to Variant in mixed C++
Initializing statics in native library
Daniel Carey
[STAThreadAttribute]
int main(array<System::String ^> ^args)
I have searched high and low for information on known issues related to this problem, but since I was not aware that the entry point played a role, I have not focused on it at all. Do you have a suggestion where I might get more information Thanks!
-Matthew
Luke D
Actually, come to think of it, if this does fix your problem, you should file a bug here: http://lab.msdn.microsoft.com/productfeedback/.
I'm not sure if we've gotten any customer reported issues (we give customer reported issues a very high priority) with this yet.
Laxmi Narsimha Rao ORUGANTI MSFT
Well, maybe they are not so well known ;). If you check in the CRT init code though (vc\crt\src\crtexe.c etc) you'll notice that the managed entry point (int main(array<System::String ^> ^args) has to have different code in order to start up the CLR.
I believe there are a few outstanding issues where things that should be initialized prior to user global initialization don't get initialized until just before the user main gets called (this means that global/static initializers don't have everything initialized before their execution). Switching out the entry point to one of the standard ones (int main(), int mait(int argc, char** argv) etc) will give you the old standard init code path and should alleviate such problems.
-Ben
lagu26537
What entry point are you using in your managed app There are several known issues with global initialization using int main(Array...) as opposed to one of the standard entries (int main(int argc, char** argv)).
Thanks,
Ben