Thread: Why learn C#?

C# doesn't pay my bills heh, in fact I would get a pretty stern lecture(see getting yelled at for my stupidity) if I tried to start using C# at work. It is all a matter of looking around.

Originally Posted by Wraithan

There is no reason to just focus on one language or another, if you have interest in C# and C++ learn both, you will be better off in the end.

I both agree and disagree with you. I agree that programmers should learn more than one language. I disagree that learning both C# and C++ makes you any better a programmer, mostly because they are too similar. If anything, C++ is far better for learning about programming; there are fewer arbitrary rules, so the language is more flexible. One approach could be to learn C++ to learn to program, then pick up additional languages as you need them in the business world.

Originally Posted by MDofRockyView

I would use C# if I was desparate for money and had no choice. It would be better than starving to death. There is a heck of a lot of people in that situation (most people), and C# is their savior, and it pays the bills.

Thank you for that arrogant viewpoint. You must have never had a job you enjoyed where good business sense dictated that you should use an inferior technology. You can't be both intellectually honest and a language elitist.

Sounds like a programmer's failure to fully understand and use the language, not a fault of the language design.

What I mean is when you use .Net, there will be many background operations like GC for example that the programmer is unaware of them. They make programming easier and safer but slower and bigger. It is not the fault of language design of course it is goal of it.

You're comparing apples and oranges. MSIL code will be slower once per function runtime; after that, it's been JIT'ed into native code. MSIL code has the further advantage of being portable to anything with a .Net runtime; native code doesn't.

Of course .Net has some advantages.
Lets compare the speed and size:
a>C++ Code ---> Native code
b>.Net Code --(No platform specific optimization)---> IL ---> Native code
Now both are not portable.
As I know a is faster because of better optimizations and nature of C++ language. b has better memory managment but CL run time takes more memory than C runtime and a good written C app allocates less memory. About size, I don't know.

Originally Posted by pianorain

I both agree and disagree with you. I agree that programmers should learn more than one language. I disagree that learning both C# and C++ makes you any better a programmer, mostly because they are too similar. If anything, C++ is far better for learning about programming; there are fewer arbitrary rules, so the language is more flexible. One approach could be to learn C++ to learn to program, then pick up additional languages as you need them in the business world.

From what I have seen C++ and C# aren't as simular as C# to Java. Going from how I have learned. Java taught me a fair deal about OO and through it I became a lot better of a C++ programer.

Originally Posted by MDofRockyView

Okay, say I use C++, than I have to match that up to a bunch of fragmented systems, but on the other hand, if I use C#, than it works seamlessly with the .Net product line which is composed of servers and services and support.

You need to set yourself straight. You were blaintantly hateful of the language without justification... pianorain said it best...

Originally Posted by pianorain

You can't be both intellectually honest and a language elitist

Choose which you want to be, you seem to take a contrary opinion and honestly it is getting tiresome.

Originally Posted by siavoshkc

What I mean is when you use .Net, there will be many background operations like GC for example that the programmer is unaware of them.

Once again, the fault of the programmer. The programmer should fully understand the tools he/she is using.

Originally Posted by siavoshkc

Lets compare the speed and size:
a>C++ Code ---> Native code
b>.Net Code --(No platform specific optimization)---> IL ---> Native code
Now both are not portable.

Not quite. When the .Net code is ngen'ed into native code, the MSIL is still present, so it's still portable. I'm not convinced about the platform-specific optimizations. If it's platform-specific, the runtime should be able to make the optimization. However, it certainly makes sense that the combination of platform-specific optimizations and the reduced amount of time the JIT compiler has to make optimizations could lead to a slower execution speed. In my personal experience, that certainly has not been the case. I've taken a couple of programs from C++ to C#, and they've both run faster in the .Net framework.

Originally Posted by Wraithan

From what I have seen C++ and C# aren't as simular as C# to Java. Going from how I have learned. Java taught me a fair deal about OO and through it I became a lot better of a C++ programmer.

Aye, I could see that. I haven't learned Java, but C# certainly taught me a bit about OOP and IOP. However, both of these concepts could be taught in C++.

Once again, the fault of the programmer. The programmer should fully understand the tools he/she is using.

Even when the programmer is aware of them, he/she can't prevent their operation.

I've taken a couple of programs from C++ to C#, and they've both run faster in the .Net framework.

About the programs you ported to C#, weren't they using MFC?

>Time is up, now I'm going to tell you why C++ is a better choice.
This should be good.

>First off Microsoft's implementation of MSVC++ is not a better choice than C# because it is decricated
Wait, isn't that counterproductive to telling us why C++ is a better choice?

>probably the strongest reason why Standard C++, the type you find on *nix
>systems might be a better choice is because you can avoid vendor lock in, and
>more specifically being locked into a product line.
I think you fail to understand the meaning of standard conformance. If a compiler conforms to the C++ standard then it must follow certain rules. It can circumvent those rules with extensions, but as long as your code follows those rules and uses relatively portable libraries, there's no vendor lock-in. It's only when you use the non-portable extensions provided by a "product line" that you find yourself stuck with it. This happens with tools on *nix too. If you use a gcc extension, you're stuck with it unless you can find a portable workaround or another compiler that supports the feature you used.

One thing I find amusing with *nix snobs is their arguments almost always work just as well against them.

>Personally I have a lot more respect for those kind of programmers, the ones who are more independant.
So your argument that C++ is a better choice comes down to your personal approval and no real hard evidence.

Originally Posted by MDofRockyView

I know the answer to both sides but it appears that you could not answer the question.

Sure, I'm game. The original poster said...

Originally Posted by Newbeee

Can anybody please explain why is C# better than C++.

A worthy enough question. Let's take a look at the question you answered.

Originally Posted by MDofRockyView

now I'm going to tell you why C++ is a better choice.

Oh, exactly the wrong one. However, since you appear to have near-infinite knowledge in all things, I do have a question for you. C# is widely touted to be a Microsoft-specific sort of a thing, similar to DirectX. If this is the case, then why is there an international C# standard?

Originally Posted by siavoshkc

Even when the programmer is aware of them, he/she can't prevent their operation.

Heh, an interesting quality of any programming language. No programming language with any given feature X is powerful enough to allow a programmer to prevent feature X. With respect to the GC, I agree that Microsoft could have given programmers a bit more control over how and when it runs.

Originally Posted by siavoshkc

About the programs you ported to C#, weren't they using MFC?

Thankfully, no. I've avoided MFC like the plague.

>Prelude, everyone has to make their own decision, <snip>
It seems that the only thing you're skilled at is saying nothing with lots of words.

pianorain: However, it certainly makes sense that the combination of platform-specific optimizations and the reduced amount of time the JIT compiler has to make optimizations could lead to a slower execution speed. In my personal experience, that certainly has not been the case. I've taken a couple of programs from C++ to C#, and they've both run faster in the .Net framework.

Originally Posted by siavoshkc
About the programs you ported to C#, weren't they using MFC?

pianorain: Thankfully, no. I've avoided MFC like the plague.

Now it sounds strange. I will do some research on it and will be back with the results.

My bad, MDofRockyView. I see now that you asked a question in a post that I overlooked.

Originally Posted by MDofRockyView

Okay, say I use C++, than I have to match that up to a bunch of fragmented systems, but on the other hand, if I use C#, than it works seamlessly with the .Net product line which is composed of servers and services and support.

So how is this inferior? Hopefully I'll get an answer. I would like to know the answer. I'll be back in a few hours, I have to go ride my lawn tractor.

Now at least your answer makes some amount of sense. In general, I still disagree with it. In my opinion (and it may be an unpopular one), the C++ standard doesn't define enough stuff to make it useful. If you want to work with threads, that's platform-specific. If you want a GUI, that's platform-specific. If you want to work with sockets, that's platform-specific. If you all you want is to find the size of a file without reading the whole thing, that's platform-specific. Some C++ libraries such as boost have tried to make up for this deficiency. However, if a library doesn't support your platform of choice, then you're back to platform-specific calls.

In contrast, the C# standard defines a lot of useful functionality. So far, the only native methods I've used are Windows registry calls that could have been handled with a simple config file. Everything else is defined by the C# standard. Because of this, any compiler that compiles C# can use my source immediately. Even better than that, any platform that implements the runtime can use my assembilies without recompilation.

To refute your point about being locked in to a product, consider that Borland has its own C# compiler. The Mono project has produced its own C# compiler and a surprisingly functional MSIL runtime that works with several platforms. I fail to see how using C# could lock in to a single product when there are multiple products available that support C# programming.

At least it's fun having more active Cboard members in the C# forum.

Originally Posted by pianorain

In my opinion (and it may be an unpopular one), the C++ standard doesn't define enough stuff to make it useful.

It's actually not unpopular at all and instead quite widespread. The source lies in the history of C++, an evolved language, vs C# or Java, both of which are designed languages. Also, C++ is a lot older than both. The C++ standards committee is actively looking to remedy these defiencies. Proper filesystem access will almost surely be part of the next C++ standard. Threading is a likely candidate, too. Network access probably won't make it into the next standard, but perhaps a technical report after that.
However, the focus of C++ has usually been on providing a powerful language that would allow libraries to be written for such features. Boost is the prime example of this - and the best road to standardization for a library.
However, I have to qualify your statements below.

If you want to work with threads, that's platform-specific. If you want to work with sockets, that's platform-specific.

That's not exactly true. There are cross-platform libraries for both: Boost.Threads, Boost.ASIO, C++ POCO, ACE, not to mention all the C-based libraries and their wrappers, like NPR, APR, GTK, ...
They may be not standardized, but they are typically no less portable than the C# standard library: since they are based on a standardized language, they can be compiled anywhere there is a proper C++ compiler and an implementation has been written based on the platform-specific API. The same applies to the C# libraries: you need a C# runtime and its libraries, which means someone must have done the work to port them.
When it comes to a specific application, the remaining difference is that you need to distribute the libraries along with the app in C++, while you can assume they are available in C#.

If you want a GUI, that's platform-specific.

All the above still applies, but with one more caveat. GUI libraries don't lend themselves to be standardized. People have too different expectations on what the library should be like. Sun first provided the AWT with Java. It failed, so they wrote Swing and provided that too. Some people still didn't like it, so they wrote SWT.
C# actually has no standardized GUI library. System.Windows.Forms is not part of the CLI ECMA standard. In fact, System.Windows.Forms is so clearly a wrapping of the Win32 API that the Mono developers failed twice at implementing it before resorting to implementing it on top of WINE - an implementation of the Win32 API.
In C++, you have GTK--, Qt4, wxWidgets, and a host of other GUI libraries that support at least the platforms that Mono now supports, often more.

If you all you want is to find the size of a file without reading the whole thing, that's platform-specific.

True and embarassing.

Some C++ libraries such as boost have tried to make up for this deficiency. However, if a library doesn't support your platform of choice, then you're back to platform-specific calls.

If there's no C# implementation for your platform of choice, you're out of the game completely. Or a kernel or compact profile C# implementation - because providing a full C# implementation is a LOT of work, as the Mono project has shown. The CLI specification is over 500 pages long, and that's excluding the library specification, which is a separate 7.8 MB XML file. In addition, there's the C# language standard itself, which is also over 500 pages long.
Aside from the complexity of a C++ compiler, which mostly is platform-independent and thus doesn't need to be rewritten, it's actually far easier to provide a completely conformant C++ implementation for a platform than a C# implementation - because the standard library is so much smaller.

Even better than that, any platform that implements the runtime can use my assembilies without recompilation.

Although in fact nothing in the C++ standard says that it has to be compiled to native code - you could compile it, for example, to lwvm's bytecode, to MSIL or to JVM byte code and achieve bytecode-portability this way. Efforts to provide a backend for GCC that produces MSIL are underway.

My main point is that you're not limited to the standard. Portable never means "runs everywhere", but always only "runs on multiple platforms". It's not that hard to achieve this using C++.

Originally Posted by pianorain

I've taken a couple of programs from C++ to C#, and they've both run faster in the .Net framework.

Not that this is a necessity. The developer of the Irrlicht 3d engine, for example, started writing a scene editor in C# with Windows.Forms. He got frustrated with that and instead tried C++ with wxWidgets. Not only did it run a LOT faster (especially at startup), he also had the impression that it was faster to develop (although that measurement is not exact, because a lot of language-independent thought went into the C# phase).

I think it comes down to experience with the language. It may be that the C# way of doing things is more suited to you, and that thus your C++ code is not as efficient it could be. I would certainly be interested in examining those C++ programs.

Originally Posted by CornedBee

Although in fact nothing in the C++ standard says that it has to be compiled to native code - you could compile it, for example, to lwvm's bytecode, to MSIL or to JVM byte code and achieve bytecode-portability this way. Efforts to provide a backend for GCC that produces MSIL are underway.

This is very interesting. I don't know why I never thought of C++ compiling to anything other than native code. However, now that you bring it up, it seems obvious. I would certainly be interested in compiling C++ to a standard bytecode.

You bring up many good points. I agree that, for any particular platform, it's far more likely that you'll find a C++ implementation than a C# implementation due to the size and complexity of implementing C#. If you can't even compile, then you're pretty much done.

Originally Posted by CornedBee

I think it comes down to experience with the language. It may be that the C# way of doing things is more suited to you, and that thus your C++ code is not as efficient it could be. I would certainly be interested in examining those C++ programs.

After profiling both of them, the speed savings was in the memory management. If the apps had used some C++ memory manager, I'm sure the outcome would have been different. Perhaps it's more true for me to say that I took two programs with unmanaged memory and rewrote them to use managed memory, and they ran faster.

Now I wrote a code in C++/CLI and one in pure C++
Pure C++ is both faster and smaller.
C++/CLI

Code:

#include "stdafx.h"
#include<windows.h>
using namespace System;

Double funcman(Int32 a, Int32 b, Double dd){
	array<Int32,2>^ arr = gcnew array<Int32,2> (5000,5000);
	for(Int32 i=0;i<5000;i++)
		for(Int32 j=0;j<5000;j++) 
			arr[i,j]=a+j;
	array<Double>^ dar = gcnew array<Double>(1000);
	for(Int32 j =0;j<1000;j++) 
		dar[j]=dd+j;
	if(arr[b,a] < b && (a < 5000) && (a > 0)&& b<5000 && b>0) arr[a,b]=Convert::ToInt32(dd*a/b);
	return arr[1,b]-dar[a]+a;
}


int main(array<System::String ^> ^args)
{	
	long ave=0;
	for(int i=660;i<680;i++){
		DWORD stw=GetTickCount();
		Console::WriteLine("{0} {1}",i-660,funcman(i,i, 33.433+i));
		ave+=GetTickCount()-stw;		
	}
	Console::WriteLine("Man Time {0}",ave/20);
	Console::ReadKey();
    return 0;
}

Pure C++

Code:

#include<windows.h>
#include<iostream>
#include<conio.h>
double funcUnman(int a, int b, double dd){
	int *arr[5000];
	for(int i=0;i<5000;i++)
		arr[i] = new int[5000];
	for(int i=0;i<5000;i++)
		for(int j=0;j<5000;j++) 
			arr[i][j]=a+j;
	double *dar=new double[1000];
	for(int j =0;j<1000;j++) 
		dar[j]=dd+j;
	if(arr[b][a] < b && (a < 5000) && (a > 0)&& b<5000 && b>0) arr[a][b]=(dd*a/b);
	double r=arr[1][b]-dar[a]+a;
	for(int i=0;i<5000;i++)
		delete[] arr[i];
	delete[] dar;
	return r;
}
int main(){
	long ave=0; 
	for(int i=660;i<680;i++){

		DWORD stw=GetTickCount();
		std::cout<<i-660<<" "<<funcUnman(i,i, 33.433+i)<<std::endl;
		ave+=GetTickCount()-stw;
		
	}
	std::cout<<"Unmanan Time " <<ave/20<<std::endl;
	_getch();
	return 0;
}

Ticks of Managed:4268 +- 50
Ticks of Unmanaged:264

Size of managed: 26.5KB
Size of Unmanaged: 9 KB

Both optimized.

Not a very good example. As pianorain observed, the main advantage of JVM or CLR programs over native C++ is the memory management. The generational garbage collecting runtime is simply better than unoptimized direct management in non-trivial cases. Of course C++ offers many interesting ways of optimizing memory management.