From Win32 to Cocoa

Shining Arcanine wrote:


I did not read the guy's argument, but I have never been able to understand why the .NET libraries must be used from within .NET. Why is it not possible to simply use them in C++ much like you would use the standard template libraries or any other libraries written in native code?

Because .NET languages have the following important points:
1. .NET languages compile to MSIL which must be translated to processor code before it can be run. This is a serious obstacle to .NET running inside a C++ native app
2. .NET languages typically (although not uniquely) rely on a concept of pointer-less references which nessesitate some form of garbage collection (e.g. reference counting or the full-blown asyncronous GC). This means that .NET objects need to have a central manager, and that any .NET method must be running within the context of such a manager.

Basically this means that if .NET is to be run inside C++ we can do the following:

1. Translate it to C++ code at compile-time and find clever ways to avoid the problems of the GC.
2. Run the .NET code inside a big C++ black-box of a runtime.

Note that while 1 is feasible, it loses a lot of the point of .NET - that is processor independence and the ability to migrate modules without binary recompilation.

2 suffers from simmilar problems, since there's little reason to run a managed program unless it can either
 a) Return a result from a computation
 b) Interact with the outside world via native invocations
which is why we have pinvoke and interop.

Given all of this we can then start putting everything together and say that we can run .NET languages natively, but methods that are managed must be run within a managed black-box (which manages the JIT, Garbage collection, managed Exceptions etc) and this can call out to native methods. These native methods can be written in C++ and we put in a clever layer to translate .NET managed objects into C++ unmanaged objects and vice-versa for argument passing between the two.

This is called managed C++ and it exists.

Shining Arcanine wrote:


Then again, I never could really understand proprietary languages. Java is another fine example of a proprietary language that I do not understand. Why Java must be compiled for the JVM and not a real processor, or more accurately, why is it so strongly discouraged that Java programs run on anything other than the JVM? Also, why is the JVM so biased towards Java and that better languages, like C++, need not apply? I suppose the same could be said for .NET's intermediate language.

You mean you do not understand why we have different binary languages that are not processor languages? This is a consequence of the migration towards the program managing your pointers rather than the programmer managing your pointers (which is the basis of "managed" languages such as Java and C#).

Direct consequences of this include easier optimisation paths, easier data flow analysis and the potential for much more aggressive optimisations at runtime via the JIT that would be impossible at compile time.

Furthermore, by using a common binary language we can allow programs to run on arbitrary machines by only rebuilding the virtual machine, rather than recompiling the the program-on-top. This is what we mean by processor independence, which means that a C# program I build on this machine could be run on a playstation3, a fridge, my car or on an apple mac, so long as someone has written the virtual machine.

Shining Arcanine wrote:


I really do not understand this trend of proprietary languages bundling together a few different concepts that deviate dramatically from well established practices and try to force them collectively on people. The idea of a virtual processor that makes any program compile for it run on any system is great, but why ensure that only one language works on it? The idea of having many useful libraries bundled with each other is great, by why force managed code on people? The idea of managed code is great, but why force a dependency on one huge conglomeration on people? These things are very good when taken alone, but when taken together, some of the benefits that they have individually become disadvantages.

The underlying binary specification is published and a number of languages can run on both the JVM and the CLI-VM. For Microsoft the range of languages is bigger, including C#, managed C++, VB.NET, F# and a number of sub-languages from MSR.

Also it's important to note that while practises may have become established, that doesn't mean that they are good practices, particularly given that the type of programs being written now are different to the types of programs we used to write - until very recently the vast majority of programmers could completely ignore concurrency and thus the C++ Resource-Allocation-Is-Initialization (RAII) system removed the potential for memory leaks in programs. With multiple threads this is no longer the case, and is one of the many things that managed languages help to solve.

littleguru wrote:



Article wrote:But Java's much more high-minded. It's much stronger on concepts, making it easier to learn.

Especially the generics that are converted into cast by the compiler I don't know how much the people who like clean design like that...

Just thought I'd point out that actually that doesn't happen - when you first create a qualified type the JIT physically builds that type in memory and this means that there are no casts involved when using generics (this increases the speed dramatically given the high-level-of-use of generics in the managed assemblies)

GamlerHart wrote:



The Java-guys had choosen the "type erasure"-system to keep backward-capabilty. It garanties that a generic-libary can be use from old code and new code can use old non-generic Library.

It's the same thing again. There where million and millions of Java-apps out there and if you break compabilty, millions of developer had cried or ignored the new release.

The .NET world had integrated "real"-Generics, because the .NET world was much younger.


Imo this discussion about "legacy"-concepts blend into "new" plattforms is everwhere.

- .NET lots of concepts from the Win32-world
- Java brings pain from badly designs in the early days. (Uglyboxing/unboxing, no "real" generics, etc)
- Mac has Cocoa but also Carbon but also some UNIX-like stuff etc...

That's a pretty poor excuse. Even if you don't define runtime generics construction, the compiler enforces closures for all types (all instanced generic types must be closed under types) and this means that you can create anonymous types at compile time that effectively are the closures of the generic form:

class Generic<T> {
  T myvar;
  static Generic<Int> someInstance;
  static Generic<String> someOtherInstance;
}

gets translated to:
class Generic_Int {
  Int myvar;
  static Generic_Int someInstance;
  static Generic_String someOtherInstance;
}
class Generic_String {
  String myvar;
  static Generic_Int someInstance;
  static Generic_String someOtherInstance;
}

which preserves all of the attributes and type safety of generics and is backwards compatable to older versions.


Also, .NET brought in generics in .NET 2.0 and there was a huge backlash against Microsoft making .NET 1.1 incompatable with .NET 2.0 and vice-versa.