Watch Your Memory Spaces when Implementing C++/CLI

So for the past 4-5 days I've been trying to figure out why my CLI will not run in one of my CPP files. I figured since it was just a POD(Plain Old DataType) it should behave as expected... not the case... basically the POD is being allocated in seperate memory space than the applications memory space and thus being joined up using the semantics of what's known as a SharedPtr (shared pointer) In my quest to beat or figure out the compiler I was not able to get CLI to play nice inside of a shared pointer class. I tried every which way under the sun that I could possible think of to get it to work... IJW (/clr, /clr:pure, /clr:safe) I even tried using the old and new style gcroot and auto_gcroot wrappers around System::Runtime::InteropServices:Marshal class... still no dice. Every time I went to call a member on the managed type I got a memory corruption runtime error. I searched around and no one I could find had a solid answer so the only thing left to do was pull the logic in to the program memory space and then once the managed work was done I could then Marshal the data to the native world and pass it in the back door of the seperate memory space via a custom accessor I created and voila... it worked! I would love to show some of the code for how I did this but unfortunately it would be against company policy. However, I think the key take away here is that when you're trying to expose functionality that you've invested in years ago to a now modern managed world of applications you really need to have a sense of both worlds as you write your managed functionality. I on the other hand am learning native as I work with it so there is always little surprises popping up as I code. : )

-Develop with Passion
(Jean-Paul S. Boodhoo)