Hello.

I am a C++ programmer with limited experience (design) using C#. From my experience, C#, like Java, is a derivative of C++. However, Microsoft is able to blend C# and C++, getting the best out of the Java design.

With the recent settlement between MS and SUN, I think that MS will remain the top desktop software company. Bottomline: C# should surpass Java given that it is in fact platform-independent.

I have some basic questions on the C# language.

Currently, does a C# application run on a non-Win32/Win64 platform (UNIX, Mac, wireless)?

How does C# compare to C++ in terms of object-oriental design (inheritance, template, etc) on a large-scale project?

How does C# compare to C++ for client/server applications including various IPC concepts, multithreading, multiple processes, etc?

How does C# compare to C++ for processor-intensive applications including games, 3D-render, multimedia, etc?

I read some reviews on two books on C# by Jeff Prosise and Charles Petzold. In general, readers find the books GUI-oriented. How good is C# for performance-imperative applications?

Thanks,

Kuphryn
Posted on 2004-04-05 16:43:54 by kuphryn
Hm, actually, I don't care about C, C++, C# or any "C" letter of the alphabet. ;)
Posted on 2004-04-05 16:50:34 by JohnFound
c# on other platforms: http://www.go-mono.org/

I know next to nothing about c# though, so I can't really answer any of the other questions. I guess that the JITer is good (comparing speed of MS JVM and Sun JVM), but that (on x86) there's still reason to use native code for speed-intensive tasks.

Friend of mine that has used it said the memory consumption was very high, and that some tasks took quite too long.

The language (and the .NET environment) is still pretty new, so I guess it should be given some time before too severe judgment is made against it. It's probably just fine for speed-insensitive tasks as it is now.

Btw: this post should really have been made in the heap.
Posted on 2004-04-05 16:57:06 by f0dder
First of all, this isn't asm related so it should go into the heap. I'll move it after my reply.

I've been looking into C# myself too lately so I'll try to answer some of your questions as far as I can:

I am a C++ programmer with limited experience (design) using C#. From my experience, C#, like Java, is a derivative of C++. However, Microsoft is able to blend C# and C++, getting the best out of the Java design.

With the recent settlement between MS and SUN, I think that MS will remain the top desktop software company. Bottomline: C# should surpass Java given that it is in fact platform-independent.

While C# (or rather, .NET) was designed to be platform independent, in practice it only runs fully on windows yet, though there are projects like mono. Java on the other hand runs on many platforms already. On the windows platform, .NET will most likely surpass java because the platform will be available by default in all future windows versions and as a redistributable for current windows versions. When the .NET runtime is installed, programs run just like normal programs apart from the initial JIT compilation and the time and memory it takes to load the framework, unlike java programs which most users only know from applets. Also, java's user interface (especially swing) doesn't really have a native look (even using the 'native skin', it's just not it) and is far from fast. Finally, since microsoft has removed the java runtime, I don't think it has a chance :).

I have some basic questions on the C# language.
Currently, does a C# application run on a non-Win32/Win64 platform (UNIX, Mac, wireless)?

In principle, yes. In practice, not really yet. But it was designed to be portable just like java.

How does C# compare to C++ in terms of object-oriental design (inheritance, template, etc) on a large-scale project?

In its object-oriental design, C# is a mixture of java and C++. It has java's interfaces instead of C++'s multiple inheritance, but it does allow you to explicitly make a method virtual or not like C++. It also has operator overloading and lots of other useful stuff like references, structs, boxing, delegates and properties. For a large-scale project this will probably make your life easier and the design more robust. The designers of C# have thought a lot about the problems C++ and java programmers frequently came across and tried to provide better solutions in C#.

How does C# compare to C++ for client/server applications including various IPC concepts, multithreading, multiple processes, etc?

Actually, C++ does not support any of those concepts. C++ in itself is just a language. It doesn't even have a native string class, let alone support for threads. All this is done by libraries like STL, or APIs like windows'. C++ gives you a lot of freedom but there's not much to say about the concepts you mention without relating it to some library or API. C# on the other hand works hand in hand with the .NET framework, and can't really be seen without it. The .NET framework almost completely covers the windows API, but in an object oriented way. So basically programming all these concepts usually work like you are used to. There are some differences because C# run more or less sandboxed, but in general the principles are the same.

How does C# compare to C++ for processor-intensive applications including games, 3D-render, multimedia, etc?

C# is, like any .NET language, compiled to intermediate language (IL), which is comparable to java's bytecode. However, when windows runs a .NET executable, it will compile (parts of) the code on the fly and actually store the compiled code in a cache. This gives a performance hit the first time you run an application (or part of it that hasn't been run before), but on the subsequent runs the code is already compiled. This might actually perform better than normal compiled code like C++ in some cases because the code can really be optimized to the target CPU. For example, if you compile a C++ program you probably compile it for some older pentium to ensure it will run on most machines, including some older ones. So even though the latest athlon might benefit from some optimizations, they are not used because the code is compiled for some general processor. With the JIT compiler it can actually use all the opcodes available, since it is compiled on the fly for each computer it runs on. And since the Visual C++ compiler is pretty good, I assume the IL compiler to be pretty good as well.

However, .NET is still managed code, which means it has some performance loss because of the garbage collector, runtime type checking, bounds checking etc. Usually this doesn't really matter. If it does, one can mark a block of code as 'unsafe', and actually use pointers and other low level things to speed things up. The final compiled code for such pieces are probably of comparable speed as C++. If you really need the speed you can always write parts in (managed) C++ and link it to the .NET application.

I think the main thing that makes it looks slow is the big runtime that needs to be loaded, but maybe that will change in the future if .NET is integrated by default in windows.

I read some reviews on two books on C# by Jeff Prosise and Charles Petzold. In general, readers find the books GUI-oriented. How good is C# for performance-imperative applications?

The .NET framework has a lot of GUI stuff like windows forms but also web forms for ASP.NET applications, so that's probably why the books talk a lot about them. For the performance issue, see above.

Thomas
Posted on 2004-04-05 17:33:59 by Thomas
Okay. Thanks.

Kuphryn
Posted on 2004-04-05 19:26:08 by kuphryn
Nice reply, Thomas.


Actually, C++ does not support any of those concepts. C++ in itself is just a language. It doesn't even have a native string class, let alone support for threads. All this is done by libraries like STL, or APIs like windows'.


STL is part of the C++ standard library, which is in turn part of C++. C++ is not just a language.
Posted on 2004-04-05 20:03:22 by death
Originally posted by death
STL is part of the C++ standard library, which is in turn part of C++. C++ is not just a language.

It's probably a matter of definition, but the C++ language does not require the STL. You might as well use an alternative library, and that was my point. C# or java are bound to their libraries, while C++ does not need any libraries to function (though you wouldn't be able to do much interesting then).

Thomas
Posted on 2004-04-06 02:46:28 by Thomas
I often read about fully OO feature in languages including Java and C#.

How important is object-oriented paradigm?

Nonetheless, the good things seem to point to platform-independence rather than the OO paradigm.

How would you evaluate fully OO paradigm (C#, Java, etc) to a flexible programming language like C++ that gives the developer unsurpassed control without going to ASM?

Kuphryn
Posted on 2004-04-06 11:52:15 by kuphryn
I'd say modularity and object oriented design is important, even if you aren't using an object oriented language - look at the NT kernel for instance.

I think the "everything is an object" paradigm can be a bit too much sometimes, although it certainly is useful when doing GUI programming. With existing technology, it's too easy to have a lot of code bloat, performance degradation and memory usage when "everything is an object", though.

(But well, that's my subjective "feeling", I haven't really looked at the .NET platform, so better listen to people like Thomas instead :))
Posted on 2004-04-06 12:10:02 by f0dder
Also I remember, and I supose that I write before, but I listen some times that OO is a state of mind, the languages only facilitate the implementation of it, but even you can programm in a OO way in C.


For example and when I listen the anterior was in a discusion about nasm, some time a go, and a yasm coder (author), write to the nasm-dev list that yasm is Object-oriented, but is writed completely in simple C. If you whant other example, you can look at GTK+, and other libraries, there are writed in pure C, but with a style of OOP.


Have a nice day or night.
Posted on 2004-04-06 13:05:04 by rea
Originally posted by f0dder
I think the "everything is an object" paradigm can be a bit too much sometimes, although it certainly is useful when doing GUI programming. With existing technology, it's too easy to have a lot of code bloat, performance degradation and memory usage when "everything is an object", though.

C# has a very clever mechanism to have the benefits of 'everything is an object', but still implementing it efficient. All types are, eventually, objects. Even primitive value types like int, long, char are actually of type System.Int32, System.Int64 and System.Char. This means you can do:
int i = 5;

i.ToString();
object o = i;
6.ToString();

The ToString() is a method call on a simple integer, because it's also an object. The object reference 'o' points to a so-called 'boxed' integer, which allows you to use primitive types in generic data structures without encapsulating them into objects like java requires (with the Integer, Double, etc. wrapper classes).

However, they are still value types, copying one int variable to another actually copies the value, not some reference. The boxed integer 'o' points to is also a copy of i, not a reference to it, but you can't change an integer using an object reference anyway.

Also, note that this object view of primitive types is only used when actually necessary. When doing calculations with variables, it works just like C++. Integer arithmetic is done using normal opcodes and if you get hold of pointers to the local (int) variables using unsafe code, you will see they just take 4 bytes and are stored in sequence on the stack like a normal program.

Thomas
Posted on 2004-04-06 13:11:45 by Thomas
Here is my experience with C#. Recently I have to stick in my dll(pure asm) to C# project and as one of the agrument there was some structure which my dll fills with pointers to unicode strings located within dll's address space. Those strings was declared as follows:
[MarshalAs(UnmanagedType.BStr )] public String pSomeText;

Everything seems fine unless one little thing - C# is just copy those strings into its heap. Apart from it was very slowly, the program just got an exeption when the strings was long enough :) And after reading a couple of C# books I have no workaround yet :(
Posted on 2004-04-08 02:48:53 by masquer
masquer,

string has limited size. You could search for it on msdn but I think it's 64K. Basically, strings types should not be used when you need buffers, you might use StringBuilder instead.

As for .NET performance; it depends. On the database applications front, you can compare c# performance to that of native code. Mainly, c# has a huge advantage with its pure object oriented interface-implementation domain of work that makes designing complicated and distributed systems much more easier. The existence of platforms like java and .NET made people with limited chances talk compfortably about enterprise archeticture, design patterns and code refactoring... As a practice, It really facilitates understanding these topics.

On the other fronts, when you really need highly sophisticated applications with the highest performances and capabilities (for example, HTTP servers, image processing, games...), then .NET is not for it; at least for a while.

There is a project by microsoft codenamed ROTOR; building .NET layer for FreeBSD. The source code is at microsoft's and it is very interesting.
Posted on 2004-04-08 16:34:49 by hosam_shahin
Originally posted by Thomas
The ToString() is a method call on a simple integer, because it's also an object.
It just gets boxed in place so the ToString() can be executed.

Originally posted by hosam_shahin
There is a project by microsoft codenamed ROTOR; building .NET layer for FreeBSD. The source code is at microsoft's and it is very interesting.
ROTOR is no longer in development, but it did form the base for Mono, which is the port to Linux.


Originally posted by Thomas
While C# (or rather, .NET) was designed to be platform independent, in practice it only runs fully on windows yet, though there are projects like mono. Java on the other hand runs on many platforms already.
This answer, while technically correct, is not fully illuminating. Because of the Compact Framework, C# runs fully on *many* different devices, although those devices are running WinCE.


Originally posted by kuphryn
C# should surpass Java given that it is in fact platform-independent.
Why care specifically about C# surpassing Java? *All* managed .Net languages will surpass Java, because they all compile to the same MSIL code. May Java die a painful death ;)
Posted on 2004-04-09 07:12:27 by sluggy
hosam_shahin,

thank you for your hint, I will dig into StringBuilder, maybe I'l be lucky :)
Btw, I'm not saying all C# apps are slow :)
Posted on 2004-04-09 08:10:33 by masquer
Originally posted by sluggy
It just gets boxed in place so the ToString() can be executed.

It works pretty transparent so it looks a lot like they are objects but technically you're right.

This answer, while technically correct, is not fully illuminating. Because of the Compact Framework, C# runs fully on *many* different devices, although those devices are running WinCE.

Right again :)

Thomas
Posted on 2004-04-09 10:14:25 by Thomas


It works pretty transparent so it looks a lot like they are objects but technically you're right.
It is a bit like the "frames of reference" part of Einstein's Special Theory of Relativity: is it an object, or is it a value type? It all depends on where you are observing it from :) Who ever said that .Net would make things easier?
Posted on 2004-04-10 18:52:43 by sluggy