Re: Java or C++ for cross-platform Cocoa/.NET?
Re: Java or C++ for cross-platform Cocoa/.NET?
- Subject: Re: Java or C++ for cross-platform Cocoa/.NET?
- From: Jonathan Dodds <email@hidden>
- Date: Mon, 7 Jun 2004 23:57:29 -0400
On Jun 7, 2004, at 10:00 PM, David Feldman wrote:
Thanks. For some reason it's been a bit difficult to find adequate
information to support this decision, so I appreciate the help. Some
follow-up questions...
Managed C++ (MC++) is a set of non-standard extensions to C++ that
allow for the creation of and interaction with objects in the .NET
managed heap. MC++ is not portable.
You might lean heavily on the preprocessor to have code that can
compile as either MC++ or C++. For non-.NET compiles you could
#define away things like __gc. You'll also need to deal with type
differences. For example, you can't use std::string in managed code;
you must use the CLR String type. Basically you would be using the
preprocessor to generate two different sources. That could get ugly.
(And note that there are big changes to MC++ syntax that are coming
with Visual Studio 2005.)
That's what I was afraid of...that MC++ and C++ are, in many ways,
different languages that happen to share syntax.
You could write the platform-independent code in straight standard
C++ and take advantage of the standard C and C++ libraries. As you
can with C++ and Objective-C, you can mix C++ and MC++. As with
Obj-C++ there are certain restrictions because of differences in the
object models. The unmanaged C++ code would not be subject to the
garbage collector. That may not be a disadvantage unless there is a
reason to be pure .NET.
How does this C++/MC++ mixing work? If I can write standard C++ code
and just connect it up to MC++ or C# code, that sounds reasonable. I
have no attachment to pure .NET and am only using .NET because it's a
quick way to create the Windows-specific pieces of a Windows app.
We may be using different meanings for 'mix'. By 'mix' I mean you can
use C++ and MC++ in the same source file. By this definition you can
not 'mix' C++ or MC++ with C#. C/C++/MC++ and C# use different
compilers: cl.exe and csc.exe, respectively.
An example of some of the restrictions when mixing C++ and MC++:
If you declare a class to be a managed __gc class, it can not inherit
from an unmanaged class or be the parent of an unmanaged class. Data
members of a managed class can be either managed types, unmanaged POD
types, or pointers to unmanaged types.
You can find more detail on the MSDN (msdn.microsoft.com) website.
If it is really important to keep the .NET and unmanaged code
separate, you could wrap your platform-independent code in a COM
object and then use COM-interop to call it from .NET.
I've looked into this a bit. It's easy to call COM object methods from
.NET code but I haven't been able to figure out how to go the other
way and have a COM object call methods in .NET code. Is that doable?
Yes. COM Interop works in both directions. COM objects can be made to
look like .NET types to .NET code and .NET types can be made to look
like COM objects to unmanaged code.
(I also know next to nothing about COM so it would be a steeper
learning curve on my end, but I'll deal with that if it's the best
option.)
I haven't used J# so I can't comment on it.
I'm still looking into it. There seems to be less info on it than the
other VS.NET languages, but it looks potentially promising: It seems
to be basically just an early (1.1 I think) version of Java that will
compile in VS.NET and work with the .NET Framework. If that's true it
would allow me to write standard Java code and just compile it for
.NET on the Win side, Cocoa on the Mac side, and with standard Linux
tools if I end up building a Linux client. It seems like it would work
since Java is more of a managed language than standard C++...
Probably 1.1.8. The Microsoft Java VM stopped evolving at 1.1.8. I
believe J# is primarily aimed at users of Microsoft Visual J++ which
may explain why J# doesn't support a newer version of Java.
--Dave
-----------------------------------------------------------------------
---
David A. Feldman
User Interface Designer
http://InterfaceThis.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.