469,602 Members | 1,795 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,602 developers. It's quick & easy.

Mixing managed C++ with unmanaged C++

I am developing a demo in C# using Managed DirectX. I wanted to use a
C++ static library in the demo (its a class for handling physics), so
I decided to create my Graphics classes in C#, inherit from them in
MC++. So far so good......

I modified my MC++ project to run as mixed mode (removed nochkclr.obj,
added msvcrt.lib, etc etc), and created 2 unmanaged classes which
handled the calls to the static lib (btw all the code works fine in
other unmanaged C++ projects - i just copied it straight out) . I then
created managed wrappers around them. Again so far so good......

BUT THEN!

When I try and call the code from C++ it falls over. I get a null
object exception. Now my unmanaged classes use some static members,
and if I remove the calls to static member variables it all runs OK -
obviously it doesnt do what I want, but at least it doesnt crash. If I
put them back in it fails.

I debugged the code to see if my suspicions were right - it seems the
static members are being reset - eg (c#)(btw these arent my class
names - changed for clarity)

MyGFXSys mgfxs= new MyGfxSys(); //calls unmanaged constructor in
here which initialises static members - shows in the debugger fine.

MyGFXObject obj3d = new MyGFXObject() //calls unmanaged constructor
in here which accesses the static member from above. This call fails -
static members variables appear un-initialised.

The static members I refer to are part of the UNMANAGED class btw, in
case that makes a difference. I also tried making them (ugh) global,
and got the same effect.

OK, I know what I'd be thinking about now - why not find another way
to do it without static members or globals? Unfortunately the static
lib makes use of these, and I dont have and cant get the source for
this - so I need to solve this.

Any ideas, help, or simply prayers would be much appreciated.

Cheers

Neil
Nov 22 '05 #1
2 2008
Neil wrote:
When I try and call the code from C++ it falls over. I get a null
object exception. Now my unmanaged classes use some static members,
and if I remove the calls to static member variables it all runs OK -
obviously it doesnt do what I want, but at least it doesnt crash. If I
put them back in it fails.


You've answered yout own question. The CRT is responsible for calling static
constructors. Have you looked at the docs that mention how tro initialize
the CRT from outside the library?

http://msdn.microsoft.com/library/de...omixedmode.asp

(becareful about line wrapp - this must be the longest name for an HTML page
I have ever seen!)

Richard
--
my email ev******@zicf.bet is encrypted with ROT13 (www.rot13.org)
sign up for my free .NET newsletter at
http://www.wd-mag.com/newsletters/
Nov 22 '05 #2

Unfortunately I followed that document. I ave another project which does
a similar thing, but I could only get it to work when I link to libc.lib
too. Unfortunatley this isnt an option as the static lib I'm using
requires that libc is excludded fro the build as qsort is defined in the
static lib file I'm using.

I've noticed in my project that works (using zlib) that the link order
makes adifference to whether it links correctly or fails. Is this a
feature or a bug?

Regards

Neil Danson
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 22 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by kaalus | last post: by
4 posts views Thread by Daniel Lidström | last post: by
2 posts views Thread by quat | last post: by
3 posts views Thread by frank | last post: by
3 posts views Thread by frank | last post: by
2 posts views Thread by jraul | last post: by
2 posts views Thread by Jon Slaughter | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.