This is a long shot, and I couldn't find a definitive answer anywhere else...

I'd like to use C++ classes and functions inside an XNA game (on the 360). I've read that using C++ is technically possible, but I haven't been able to find how to do this since it would only be a small portion of the code.

What I'm doing is porting some BlitzMax code over to XNA, and it uses some external C++ code for collisions. Some bits of the BMax code to give you an idea of how this works:


where the C_ methods are in collisions.cpp.

Is what I'm asking even remotely possible? Sure I could rewrite collisions.cpp in C# too, but it's over 1200 lines of barely commented, operator-overloading-reference-passing-brain-melting C++, so if there's a way to avoid that I'd gladly take it.

You cannot use native code on Xbox.

You may be able to make use of existing C++ source code, if:

• You have all the source, so you can recompile it to .NET IL opcodes
• The code does not use any of the (many) C++ features that the Compact Framework does not support
• The code does not call any C++ library features that the Compact Framework does not support

So in general, no, you can't just run arbitrary pieces of existing C++ code. You may be able to get specific pieces of code to work, depending on exactly what they do, but this is somewhat fragile and not officially supported.

Yes, I understand this isn't a good thing to depend on. However I'd like to try, if for no other reason than to see if it's possible. :)

In this case, I believe it satisfies all three of those requirements. If so, how do I try it?

Check out http://msdn.microsoft.com/en-us/library/x0w2664k.aspx

You just want to focus on the managed libraries.   The native libraries are not supported according to eariler posts.

If you have the source code then I think you'd have a lot more luck with trying to convert it to unsafe C# code.

Interesting! Thanks for the replies guys, I'll research both methods, but from some small tests I fear what I want is impossible, and I will have to go through and convert the C++ code anyway. _{*que scary music*}

How many lines of code is it? If you decide to convert to c#, I think you'll find it's easier than you think, once you get into the swing of it. If you can break it down into bits, I could probably do a bit or two for you.

I find this amusing since I'm on a similar boat.

I have a ton of C/C++ code that I wish I could easily port. I wouldn't mind converting it to C#, but the editor and classes are different enough that it takes more time to learn the tools than to write the code. And although I've used C# for a few years now I don't do it regularly enough where it is burned in.

I stated once that C# was written by VB programmers. . .lol

Not starting a "flame", and it's too late  anyway, but if I were writing the next generation language I would have made it more inline with C++ than with VB.

r2d2:

Not starting a "flame", and it's too late  anyway, but if I were writing the next generation language I would have made it more inline with C++ than with VB.

The whole point is to make things easier, not more difficult. Making a next-gen language more inline with C++ is a couple of steps backwards. I used C++ for almost a dozen years total. I'll never use it again unless there's no other option. Yeah, I know the whole "It's faster" argument, but that's crap. No one here is writing cutting edge stuff AFAIK so there's absolutely no need to use C++. Move into the 21st century pool, the water's fine! :)

r2d2:

I stated once that C# was written by VB programmers. . .lol

Pascal, actually. Anders Hejlsberg wrote the original Turbo Pascal. WinForms in .net owes a lot to the Delphi rtl. (He wrote both, and kept a lot of what he liked from Delphi.)

@Jim - I don't mind the water, in fact there are numerous parts that I like about it. But the change up is hard when 96% of your time is spent on C++ (and Assembly), and C# usage is intermittent.

r2d2:

@Jim - I don't mind the water, in fact there are numerous parts that I like about it. But the change up is hard when 96% of your time is spent on C++ (and Assembly), and C# usage is intermittent.

I understand. It's part of being a programmer though. Over the years I've had to learn about a dozen different programming languages. :)

Honestly, while C# is great as a bread-and-butter application programming language, and System.Reflection is the closest thing I have to an extramarital affair, some things just work better in C++. You can do some very elegant things with C++ templates that generics simply cannot do, for example. (Although the implementation of those elegant things generally looks very un-elegant in C++...)

The biggest problem in porting to C++/CLI is that your code is going to use "*" and "->" and "&" all over the place, rather than "^" and "." and "%." While unsafe code is allowed in XNA on Xbox, impure code is not.

A dozen?

jwatte:

...some things just work better in C++. You can do some very elegant things with C++ templates that generics simply cannot do, for example.

I guess it's just a matter of opinion. I've yet to find that I can't do something I need to in C#. Maybe if I were working on the next GoW or Doom game, I'd need fancy coding, but I'm not, so I don't.

And, to be specific, assume you have this class:

#pragma managed

namespace Foo
{
  class Bar
  {
    public:
      Bar() { ptr = new int[2]; }
      virtual ~Bar() { delete[] ptr; }
      virtual void delete_me() { delete this; }
  };
}

You will be able to see the class "Foo.Bar" in your C# code, but that class instance will not have a visible destructor (because there is no "delete" keyword in C#), and the delete_me() function will also not be visible in C# (probably because it's not a CLR compliant class).

Jon what happens when the object goes out of scope?

jwatte:

And, to be specific, assume you have this class:

#pragma managed

namespace Foo
{
  class Bar
  {
    public:
      Bar() { ptr = new int[2]; }
      virtual ~Bar() { delete[] ptr; }
      virtual void delete_me() { delete this; }
  };
}

You will be able to see the class "Foo.Bar" in your C# code, but that class instance will not have a visible destructor (because there is no "delete" keyword in C#), and the delete_me() function will also not be visible in C# (probably because it's not a CLR compliant class).

That's because even with the #pragma managed, "class" or "struct" without qualification generates a native type, which does not use the CLR type system and will not work on Xbox.

To compile this as a managed type, change "class" to "ref class". The same code will still build, but the output will now be an IL type that can happily be used from C# (the compiler will map Dispose -> ~Bar, and the delete_me method works fine too).

It still won't work on Xbox, though, because it uses "new" and "delete" which are part of the C++ runtime library.

r2d2:

Jon what happens when the object goes out of scope?

What does the C# garbage collector do?

If you compiled this as a native type, it does nothing: the garbage collector has no involvement in native types.

If you compiled it as a managed type ("ref class"), GC will reclaim the instance just like it does any other managed type. However, it will not reclaim the array that was allocated by the class constructor, because that is still a native type.

The rules are simple:

• Managed objects are reclaimed by GC
• Native objects must be explicitly freed (generally by whoever allocated them)

But when you mix managed and native types in the same code, things can get devilishly complicated. Not something I would recommend doing for fun, but sometimes necessary (if you are, for instance, writing the XNA Framework, which is almost all interop between managed and native types).

Well I for one would like to help eliminate that "devilishly complication" by voting for native access :D

Shawn Hargreaves:

But when you mix managed and native types in the same code, things can get devilishly complicated. Not something I would recommend doing for fun, but sometimes necessary (if you are, for instance, writing the XNA Framework, which is almost all interop between managed and native types).

To compile this as a managed type, change "class" to "ref class"

But that's my whole point! When you have a ref class, you have to declare a reference with ^ instead of *, and suddenly all your existing C++ code no longer builds without significant re-write.

jwatte:

But that's my whole point! When you have a ref class, you have to declare a reference with ^ instead of *, and suddenly all your existing C++ code no longer builds without significant re-write.

Too true.

Which loops us back to the original question: "can I somehow compile this large body of existing C++ code and have it run on Xbox?"

In general, no.

There are ways you can compile code that looks vaguely C++ish, and have it mostly work if you do things just right, but there are too many caveats and restrictions for this to be widely useful as a porting technique for existing code.

One of the things that I love about the Win32 SDK is that the API is a contract with developers. Add to this its lifespan and reliability, and you have a very happy developer community. Even CE is a near match such that new developers quickly come up to speed.

Compare this with the tools we have been using over the years, and it clearly shows a dichotomy. The tools change rather frequently, although for the better in most instances, but sometimes the changes take a lot of time to adjust to.

My concern with C# and GS is will it be around long enough to make a living with it?

If yes, then it would make sense for me to recreate my codebase in GS. But as I see it right now, considering performance and restrictions, there is some hesitation as to what this framework will be in the grand scheme.

If in two years from now Microsoft were to allow developers like me native access, then I certainly would choose that path instead.

r2d2:

If in two years from now Microsoft were to allow developers like me native access,

There's already a native access path. :)