BleepingComputer.com: The next step...C++ or C#?

Hi guys!

So during my free time, I enjoy writing programs and I've been trying to play with a number of different programming languages. I started with C, which was the first programming language I ever learnt. Worked with Autoit, a macro scripting language to gain a feel for how to work with programming, and now, I'm currently sitting on VB .Net.

I have to say that every step of the way was useful. I learnt the general idea of what it's like to program and how to overcome problems and how to actually 'write' a program not only so that it works, but it works as efficiently as possible.

I now want to move on to a programming language that I'll hopefully be using for a long time to come. I did a little research myself, and I've arrived at these two finalists:
C# and C++

Now, I'd like to ask a few questions to the more experiences programmers here:

• Which one can be used to write more powerful programs, in general?
  
• Which one is harder to learn in terms of a learning curve?
  
• Which features does C# have that C++ doesn't have and vice versa? For this, I looked up a wiki article and it said that C# has a reflective and and functional paradigm whereas C++ doesn't. However, C++ allows you to allocate memory (I think?) in certain locations and allows for a lot more control. (How true is this by the way?) And consequently, is there something that one of these languages can do that the other can't?
  
• Which one looks better on a resume?
  
• From a general understanding of VB .Net and a pretty good understand of general programming concepts (loops, if statements, variable/array declarations/mainpulations), how difficult would it be to move onto these languages?
  
• Do these languages support API functions? (Mouse movements, mouse clicks, keystrokes)?
  
• How good are the compilers for these programs when it comes to debugging? What about availability?
  
• How easy would it be to write programs for other OS's in these languages(Linux and Mac as well as Windows)?
  
• How easy would it be to design GUI's in these languages?

Currently, I'm leaning towards C# but I'd like to be sure before I commit myself to it.

Thanks again guys

Hello

• Which one can be used to write more powerful programs, in general?
  C++ allows more direct access to hardware and is required for interfacing with lower level interfaces of most operating systems.
  
• Which one is harder to learn in terms of a learning curve?
  C++ (Esp. since you know VB already ... C# is just like VB but with { } s
  
• Which features does C# have that C++ doesn't have and vice versa? For this, I looked up a wiki article and it said that C# has a reflective and and functional paradigm whereas C++ doesn't. However, C++ allows you to allocate memory (I think?) in certain locations and allows for a lot more control. (How true is this by the way?) And consequently, is there something that one of these languages can do that the other can't?
  C# has no functional paradigm. In fact, C++ does. In C#, every function must be in a class. It forces you therefore to use an object oriented paradigm. C++ does not. C++ also has better support for generics (which it calls templates).
  
  C++ allows you to call native Win32 functions, whereas this is a kludge in C#. C# also requires all users of your application to run on top of the .NET framework, while C++ does not. C++ allows you to work with raw bits and bytes, whereas C# abstracts this from you.
  
  There's a comparison here:
  http://msdn.microsoft.com/en-us/library/yy...28VS.71%29.aspx
  
• Which one looks better on a resume?
  Probably C#
  
• From a general understanding of VB .Net and a pretty good understand of general programming concepts (loops, if statements, variable/array declarations/mainpulations), how difficult would it be to move onto these languages?
  C# and VB both pretty much mimic C++. Though in C++ you are forced to manage memory manually while in C# and VB the library takes care of that for you.
  
• Do these languages support API functions? (Mouse movements, mouse clicks, keystrokes)?
  Both languages support this, though C++ is lower level. C# allows you to use visual studio's nice shiny Windows Forms designer, C++ does not.
  
• How good are the compilers for these programs when it comes to debugging? What about availability?
  Debugging is the same in both languages. I don't know exactly what you mean about availability. If you mean portability (The ability to run on multiple platforms), a C++ program can be compiled under windows, linux, mac, etc, and still have the same behavior. C# is pretty much windows applications only. You can't (to a large extent) write drivers with it, for example. The Mono framework provides some measure of C# cross platform compatibility, but it is not as complete as Microsoft's implementation of the .NET Framework on Windows. Visual Studio and Mono Develop are the only major C# compilers, while there are many many compilers for C++
  
• How easy would it be to write programs for other OS's in these languages(Linux and Mac as well as Windows)?
  See above. C# is (pretty much) Microsoft Windows only.
  
• How easy would it be to design GUI's in these languages?
  C++ does not have the pretty form designer C# has.

My biggest reason for avoiding C# is the requirement of users to install the Framework, which can be several hundred MB depending on your end user.

Hope that helps,

Billy3

Hi Billy!

Thanks for the great reply once again! C++ looks to me like a better option in the long run, due to its flexibility. Should I choose to learn this, do you think it's possible to learn C++ without the help of an instructor or courses? I'm looking to learn C++ by myself, just like I taught myself all the other programming languages.

Also, would you recommend C++ has a better (even though it is harder) option, since C# closely resembles VB .Net?

I just want to make one point here since Billy is covering all of the other bases.

Quote

That sort of depends. While it is possible to learn how to program on your own, it is IMHO impossible to learn and understand good coding practices, theory, patterns, and other abstract concepts that can only be taught by someone who understands those concepts. For instance, when would you use a MVC pattern versus a 5-tier model. How do you evaluate the efficiency of your data structures? When is it ok to use standard libraries vs when it is better to create your own more efficient libraries? C# is Object Oriented, but what does that really mean?

Quote

C# is written for a Windows platform, and uses the functionality of the OS to create GUIs. C++ is not OS specific, so one has to rely on OS specific libraries. So there is not quite the cross-platform compatibility (as it pertains to GUIs).

Thank you for the excellent points Groovy

aommaster, on Jun 25 2009, 11:58 AM, said:

I learned mostly from this -> http://www.amazon.com/C-Complete-Reference...t/dp/0072226803
though I have read many many books on C++ itself and design patterns. I think without an instructor you'd at the bare minimum need a few books on C++ design. Same deal with C# though.

Examples of some things I've read:
http://www.amazon.com/Effective-Specific-A.../ref=pd_sim_b_5
http://www.amazon.com/More-Effective-Addis...d_bxgy_b_text_b
http://www.amazon.com/Effective-STL-Addiso...d_bxgy_b_text_c
http://www.amazon.com/Programming-Windows%...8301&sr=1-1
Among others.

I like C++ better than C#, though that's a personal preference thing. One thing to note: If you know VB.NET, and you know C++, then you basically know C# because it's sort of a mix of the 2. I've never read a book on C# but I can passably use it because I know VB.NET and C++ already. Once you've learned a few languages, they start to all seem the same ;) Though of course each language has it's own "special features" that you'll need a better understanding of the language to get.

Finally, no matter what language you choose, be sure to use MSDN -> http://msdn.microsoft.com ... the docs there are invaluable tools.

Billy3

@Groovicus:
Yeah, you make a good point about not only learning the syntax, but also learning the skills involved. I never really considered that.

@Billy:
I guess I'll get to work on learning C++. I'll have a look around for a book that I could use as a reference.

Thanks again, both of you

Quote

Direct access to hardware? Not really true unless you're writing a kernel in C++ (which is almost impossible in C#). You have to use the OS APIs.

Quote

The old garbage collection vs. manual memory mangement debate. I prefer GC myself .

Quote

C# doesn't force you to use OO. Putting your entire program in a static class is possible, just not a very good idea.

Quote

I wouldn't call this a kludge. Remember that the .NET class library has to be built upon something, and if you look inside with .NET Reflector you'll find that the entire Windows Forms library and many others are based on P/invoke.

Quote

C++ stereotype. C# supplies all the necessary operators (&, |, ^, ~, <<, >>, Marshal class, unsafe code and pointers) for you to work with "raw bits and bytes".

Quote

Sad but true. C# is a great language but it is practically locked into Windows.

wj32, on Jun 27 2009, 07:17 AM, said:

Actually, you can write a driver in C++ with direct hardware access. See the Windows Driver Kit for an example. You can't do that in C#. You're still going to be using APIs, but your code is literally direct access. You can embed assembler in C++ if you want as well.

Quote

But the fact that you've had to put it in a class means you're using object oriented design -- even if the whole class is static. Also, the entire .NET library is object oriented. C++'s library is not.

Quote

It's still considerably easier to type the name of a function rather than setting up a P/Invoke.

Quote

But these operations are not direct access to the CPU's bit shifting operators, etc. C# compiles into MSIL, which must be compiled into native code before execution. By default, C# compiles for AnyCPU which means you cannot make assumptions about byte ordering, etc. Bit operations will always be faster in a native language because most such operations are a single opcode on modern processors. MSIL languages must be compiled into native code before this is possible.

Billy3

C# in pretty much Windows only? No, sir you are wrong.

Have a look here : http://www.mono-project.com/

Project Mono provides .NET functionality to Windows, Linux, FreeBSD, OSX, and many others (both 32 bit and 64 bit for most)
Project Mono supports C#, VB.NET, F#, Boo, and many others

Are you afraid, you wont be able to find an IDE similar to MS Visual Studio in linux? Well sir, worry no more. MonoDevelop offers a powerful IDE using Mono, supprting C#, VB.NET, Boo, F# etc. (http://monodevelop.com/)

By the way, MonoDevelop is a clone of SharpDevelop for Windows (open source). SharpDevelop is better than the Express edition of VisualStudio. http://www.icsharpcode.net/OpenSource/SD/)

I personally use Mono for VB.net on Ubuntu Linux using MonoDevelop.

Billy O, on Jun 25 2009, 11:46 AM, said:

Already mentioned it ;)

For the record -- I use both languages every day. C++ has the STL which is nice, but C# has the entire .NET framework to support it as a library.

Main reason I answered with C++ is aommaster knows Visual Basic .NET already. If you know both VB.NET and C++ well, you know C# more or less, as it's basically Visual Basic with C style syntax.

Billy3

Quote

Argh. Replace "kernel" with "kernel-mode code" in what I said previously .

Quote

The thing about JIT is that it's meant to compile your code for the specific architecture, so I don't see why bitwise operations couldn't be implemented using a single instruction.

Romeo29, on Jun 27 2009, 10:18 PM, said:

Unfortunately due to the way MS has designed the class library it is very OS dependent. E.g. the System.Environment class with GetFolderPath, GetLogicalDrives. Many things just aren't possible using the .NET library and we must use P/invoke which isn't available on Mono... I'm talking about system tools, etc. here not business-type applications.

Quote

Um no you don't actually need to be in kernel mode to execute asm in C.

Quote

The step of compilation from MSIL into native is the time suck here. Sure, the actual instruction might execute in the same single instruction, but the overhead of compiling it means that it effectively is not a single instruction.

Quote

Mono has setup these classes to work correctly on alternate platforms. For example, on Linux, these functions will return paths with / characters rather than \ ones. With the exception of P/Invokes, the intermediate language (standardized under the name Common Intermediate Language) is standardized by the EMCA.

Primary issue for me is that whatever implementation you use, your user is forced to download the .NET runtime itself -- prohibiting most dial up users from using your application.

IMHO... it comes down to what you want to do. Systems programming and utility programming will probably be easier in C++. Theoretical algorithm design will also probably be easier in C++ because of the STL. But C# is going to be easier for the vast majority of consumer applications. After all, most programs are not about maintenance of the computer. This is why I said C# is probably better on a resume.

For malware stuffs -- for some projects I can't use C# because it's too easy for malware authors to knock out some of the dlls .NET depends on -- knocking out the native Win32 DLLs would bring the entire window station to a halt, while the .NET dlls can be removed while the system is still in a functional state.

Billy3

Quote

System.Environment class is fully implemented by Mono and its all members are available on all platforms Windows, Linux, Mac etc
Some functions as you suggested like GetFolderpath have certain constants limited only to Windows but isnt that obvious? Linux has no "Program Files" folder, so we dont have that constant in Linux. Nothing hard to understand.

Interop features of CLR (called p/invoke) are available under Mono and not only for Windows but all platforms

Quote

When did I say that? What I did say was that you cannot directly access hardware in user-mode.