[some of this covered in the FAQ http://forums.xna.com/thread/7267.aspx]

We should be careful to use the right words for things here

'unsafe' is a term meaning that the code is still IL but no longer verifiable that comes with a managed language like C# or C++/CLI - and the 360 does support that kind of unsafe code.

'native' means there is precompiled x86 code in the EXE - and in this case you can't run that on the 360 obviously.

The issue for C++/CLI appears to be that there is no compiler switch to say 'make IL code, but don't make it verifiable'. See http://msdn2.microsoft.com/en-us/library/k8d11d4s.aspx and http://msdn2.microsoft.com/en-us/library/85344whh.aspx

/clr mixes native and IL

/clr:pure isn't sufficient (see Deans post http://blog.deanoc.com/?p=75 - though I am unsure why)

/clr:safe works but that won't allow pointers even though its supported on the 360 becuase it forces verifiable code. http://blog.deanoc.com/?p=74

But Shaw is correct about the hassles - safe/pure in C++ is quite different to writing native C++ and there is certainly no Pinvoke/COM/interop etc on the 360. The only real advantage would be if you really love C++ and can't bear the few subtle differences to switch to c#.

And yes there is no integration to the 360 or content pipeline so you need to use MS Build command line type tools to do that or other projects in your solution.

• I use new and delete a lot. However most of my pointers are warpped in smart pointers so I don't rely on delete in my code (other than in my garbage collector). So I could possibly use:
  #define new gcnew
  and ignore delete in my garbage collector. But I don't want to do this unless I have to (I would still like unsafe pointers to work).
• I rely on std::string and std::list. This isn't such an issue since I can write my own string class and my own linked-list template class.
• If unsafe classes aren't allowed I could use:
  #define class ref class
  but that seems a bit dodgy to be elegent.

MessiahAndrw:

I use new and delete a lot. However most of my pointers are warpped in smart pointers so I don't rely on delete in my code (other than in my garbage collector). So I could possibly use:
#define new gcnew
and ignore delete in my garbage collector. But I don't want to do this unless I have to (I would still like unsafe pointers to work).

MessiahAndrw:

I rely on std::string and std::list. This isn't such an issue since I can write my own string class and my own linked-list template class.

MessiahAndrw:

If unsafe classes aren't allowed I could use:
#define class ref class
but that seems a bit dodgy to be elegent.

ShawMishrak:

No new and delete allowed (no standard C/C++ library period.)  You can use gcnew (I think, haven't tried it) but then you're in managed memory and need to pin your pointers before doing anything pointer-esque with them.

• gcnew allocates a chunk of memory and gives it a reference counter.
• ^ is a smart pointer.
• When the value of a ^ pointer is set to a chunk of memory the reference counter for that chunk of memory is increased.
• When the value of a ^ pointer is changed or a ^ pointer is destroyed, the reference counter for that chunk of memory the  ^ pointer was pointing to is decreased.
• When the garbage collector goes does a clean up it looks for any chunk of memory whos reference counter <= 0 and frees that chunk of memory.

• You say you won't run out of memory.  How do you plan on balancing your local store of managed memory and the total memory on the system?  Remember that the .NET Class Library and the XNA Framework need memory too, and that's going to come from the managed heap.  If you allocate too much memory for yourself up front, you'll get OutOfMemory exceptions being thrown when you try to run XNA code.  Remember that once you make a call into your game and start using pointers, you can no longer allocate memory for your memory manager.  If you don't understand why, take a look at my post regarding pin_ptr above and read about it on Google.  In short, managed memory is not stationary.  A GC handle is not some fancy notation to refer to a memory location.  The actual pointer behind the memory can be moved at run-time when the GC compacts the heap, so if you just blindly find a way to get a char* pointer out of a GC handle, it's not guaranteed to be valid afer a garbage collection!  In order to get around this, you need to pin the memory and keep it pinned over the lifespan of your pointers.  The only way to do this is within a function with pin_ptr, and the pinning is not valid after the function returns.  That's why you need to allocate all you need up front, then call into your main message loop without exiting the function.  You'll end up having to decide how much to allocate up front, and how much to leave to the .NET framework, and not change that amount over the life of the program.
  
• Calling into a method through a class pointer cannot be done because the Compact Framework just has no idea how to handle it.  All it knows is calling into managed objects.  When you just give it a memory address and tell it to make a call into it, it just chokes and fails to JIT the method.  You cannot even do stack-allocated objects.  The following will not work:

class MyClass 
{
public:
    void MyMethod()
    {
    };
};

namespace Test
{
    public ref class TestClass
    {
    public:
        static void DoSomething()
        {
            MyClass cls;
            cls.MyMethod();
        };
    };
};