Related
While doing Windows Mobile development, which language should I use? C# or C++ or something else? Why one is better than others?
It depends what you're coding.
Making native calls to the OS are possible via P/Invoke from C#, but extensive use is probably easier via native C++. You'll also require C++ for using some hardware that has not been wrapped by the Compact Framework.
Most hardware (GPS, camera, etc.), is available via CF. If you're working with a Win Mobile 6.x device, you're probably better off with C#. In addition to hardware, Pocket Office's (POOM) object model is also available to C#, so you can integrate with it.
It's worth noting that most references to Windows Phone 7 refer to managed code and the possibility of Silverlight. With Silverlight in the mix, you'll have to code with C#.
Unless your app is high performance or is extremely miserly with memory, use C# or VB.NET.
Scott
It depends on task mainly.
c++ has following pros/cons:
Direct access to resources, faster programs
Can access very deep OS parts, not needed for high level applicaiton
harder to develop and requires to manage resources by developer
C#:
Runs under virtual machine (CLR), that's why is slower
Faster and easier application development
Rich build-in library
There is no right answer for this, becasue there is no one-size-fits-all "better" definition. If you know C++ and have a lot of C++ code assets already, C++ sure looks appealing. If you know c# and not C++, then C# sure looks appealing.
C++ applications load faster, but for many applications, that's not relevent. C# applications can certainly be written faster, but they also don't have determinism. I'd never even attempt a UI in C++ any longer, nor would I think about doing database access in C++. I wouldn't write a driver in C# though, or a shell extension.
Generally speaking, most solutions I've ever delivered were a mix of the two. C# has its strengths. It's fast to write, easier to debug and unit test, hard (though not impossible) to create leaks and for some operations (like data access or XML parsing) it's just easier.
C++ has its strengths too, like speed of execution (though C# can be made to go just as fast for many things), determinism and the ability to plug in to things that want native entry points.
So my answer? You need to know both, and likely write your solutiuon using both. The percentage of each you end up using depends on what your end goal is.
It depends.
At least present a specific use-case. And possibly use SO search? :)
C++ or C# to program mobile barcode device?
Edit:
Apparently others were faster to the draw, and gave more articulated answers. Nevertheless, I still recommend reading the above SO thread.
From my experience it is easier to start with c#, and if the api provided by the compact framework is enough for you then you are ok.
On the other hand if your project is somewhat complex, or if you want to do something that is not in the compact framework you may end needing to create a helper .dll in c++. Even in this case you maybe good doing your main program in c#, and programming helpers dll in c++.
If you go directly to program in c++ you may benefit from the fact that you have a raw performance better than c#, which is good if you are doing a game.
But you will also suffer more from the limitation of windows mobile OS. Like a maximum of 32MB per process, or that all .dll share the same address space.
So in the end it really depends on what are planning to do and the experience you have.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Recently I've started to notice a lot of smirks and generally rude comments whenever I mention C#. Everyone I talk to either says learn Python or learn C++.
Python is a nice language, I get it. But I don't find much use for it right now (for my use cases), and C++ I heard is a faster language (not sure).
So my question is this, what advantage can I get from learning C++ (besides the knowledge and expansion of my horizons), when I mainly program in C#?
The biggest issues are as follows:
C++ is the de facto standard of system AND application programming for the past 20 years
C++ is portable and compilers exist for ~ 95% of all processor architectures.
C++ can enhance your .NET code, by that I mean PInvoke can be done to run optimized code written in C++ -OR- can be used to run code from 3rd parties, allowing you to write custom wrappers etc.
C++ is linux/mac/PSP/Cray II/Random OS from Thailand compliant, it has no issue compiling because it doesn't run through the .NET CLI (which I have to admit is a beautiful piece of art) C# is bound, for now, to Mono implementations and Windows through .NET.
As a professional .NET applications programmer, I love C#, I worship the ground that the architects walked on. But C++ is in my opinion, the most important language you can/will ever learn because it will open more career doors than any other language in the modern industry. If you know C# it will take you a matter of months to learn it. I reccommend Timothy D'Orazi's C++ book if you have an academic software engineering background.
Afterthought:
C++ is a tool, just like C# or a drill or a shotgun (arguably) fit the tool to the task, I'd rather die than write functional code in C++, likewise, I wouldn't do application development in F#, they're all fine langauges. Learn something that interests you! If you want to be a better programmer, learn C++, if you want to be a better application developer, it may be more to your advantage to learn new technologies within the framework you're already working in! You are a C# programmer, have you learned WPF? WCF? what about the features of C# 4.0? Have you mastered lambda functions? expression trees? There are so many directions you can go from here, C++ is just one of them. Ask yourself the following questions:
What can I learn that will add value to me?
What can I learn that will interest me as a developer?
What can I learn that will benefit me in my immediate position?
What can I learn that will help me get into the kind of career path that I want to be in?
You'll find that there will be many answers that overlap for these questions, take your time, find something that interests you and won't be a chore to learn, you'll thank yourself for it 3 months from now.
Short answer: Learning at least some C++ (and some assembly language too) makes you better at leveraging and, perhaps more importantly, debugging the software platform deep underneath your code. This is true regardless of the programming language or OS you're working in.
Long answer:
One of the differentiating factors, IMHO, between good developers and great developers is that the great ones know what's going on under the hood in a piece of software and are capable of quickly drilling down underneath layers of abstraction in the technology stack, since the toughest software problems are often caused by things way down below your code in the stack.
Therefore, I've always recommended that developers, at some point in their careers, spend at least some time learning two languages which are at the bottom of almost every software stack: C/C++ and x86 assembly language. That doesn't mean you need to become an expert in either, but having a working knowledge of things like pointers, registers, memory management, stacks and heaps, un-GC-ed string buffers, leaks, etc. is hugely useful when you need to reach down into the stack to diagnose a problem, to better understand odd behavior, or simply to make smarter decisions as you architect higher-level software, regardless of the language.
An analogy: I became a much better manual transmission driver once I took apart my motorcycle's engine and saw how the clutch worked. That didn't mean I needed to become a motorcycle mechanic, only that it helped my overall driving skills once what was happening inside my bike was not a mystery anymore.
Also, regardless of the language or framework you're working with, for projects that must call directly down into the underlying platform, C/C++ knowledge is very helpful and sometimes required.
Note that I'm deliberately not touching the more contentious question about whether you should be writing entire apps in C++ or not. Other answers have done a great job covering those arguments. Instead, I'm simply making the case that C++ skills will benefit you, regardless of whether you continue writing most of your code in C# (or Java or Python or Ruby or...)
It depends.
The thing I like about C++ is that in some ways, it is a more expressive and yes, more elegant, language than C#. It enables some really nice abstractions (such as generic programming or RAII) that just can't be duplicated in C#.
In those ways, it's an eye-opener. Of course, so are functional languages. So is Python. All of them are worth learning, even if you write all your code in C# now and forever.
Of course, C++ is also an overcomplicated mess, and a far more error-prone language than pretty much anything else. And if you don't know it really well, then it will explode in your face when you least expect it.
Of course, plenty of people will shout PERFORMANCE! when you ask why you should learn C++. I won't. Because in many common cases, C# is going to be as fast or faster as your C++ code. This old exchange between Raymond Chen and Rico Mariani illustrates the performance characteristics of both platforms pretty well.
C++ has the potential to be extremely fast. But it also has a lot of subtle performance pitfalls that mean that most of the time, unless you're some kind of omniscient code-god, your code is going to be less efficient than the equivalent C#.
If you have an interest in programming languages, C++ is a wonderful example of the theory of evolution. ;)
It hasn't grown according to some great predefined plan. It has always improved and adapted one step at a time, according to what would make the language better right now. As a result it is huge, bloated, overly complex, but it is also more expressive than something strictly designed according to a single person's vision, such as C#. C# is designed with an unhealthy obsession with OOP, because that was the cool thing when it was designed.
In C++, OOP sort of drifted out towards the periphery, not so much as a conscious design decision, but because better alternatives turned up.
It's a fun language. And I'd recommend learning it just for the sake of becoming a better programmer. But I'm not convinced that you'll need to actually use it. Of course it will make certain tasks easier (native interop, or programming small programs which for one reason or another can't assume that the .NET framework is installed), but for most cases, you probably won't need it.
That leaves the "become a better programmer" argument, and while that is a valid argument, it is also true for other languages. You should definitely also know a functional language. And Python, or a similar pragmatic, high-level "make it easy for the programmer" kind of language.
I have been C++ developers for last 10 years and last two years, I have been using java for new product development. I have also done some programming on C# just to learn it. Based on my experience I would say C++ is a challenging and high performance language which is good for computer science students to understand programming concept and algorithms. Other usage of C++ would be protocol implementation which doesn't change often E.g implementing SIP Proxy or HTTP Server..
For practice product development where requirements changes often, I would recommend any high level language where developers can focus on application logic instead of reinventing wheel. E.g Recently I started an open source project xcapserver which I was able to do quick prototype in two days using java technologies (Glassfish,REST, log4j, eXist db)but I wanted to lean boost libraries and again it's a protocol which is not expected to change often, so I decided to implement in C++. I spent 4 days just to get the logger working using BOOST::log and another 4 days to fix the thread deadlock issues with Berkeley DB XML.
Another aspect is product maintenance. I have spent days and night to fix memory leaks and corruption and learning curve for new developers is too high versus J2EE or .NET where it's easy to find developers and maintenance is much easier.
In sort, C++ is good programming language which I would recommend to all developers to learn but I don't see much use of it going forward as processors are becoming faster and cheaper so performance is not the reason.
There are reasons to use pretty much any language.
C and C++ have uses in that they are compiled into native code rather than running on a virtual machine. There is a speed advantage and it also means these programs can run without having a 50MB+ framework installed.
Pretty much all games (certainly first person shooters) are written in C or C++.
Is this applicable to you? No idea because I have no idea of what you're trying to achieve.
What will you learn from C or C++? Pointers, memory management and the like. It's quite a different world from more modern garbage collected languages like C#, Java or Python.
Learn C++ so that you can better appreciate C#.
Apart from what others have said:
People do like to see it on resume's.
Learning any language helps you translate that language into C# which makes you more valuable as a programmer.
Learning another language helps you to understand samples using that language, arguably allowing you to draw on a wider range of samples, books, examples, experts.
Wrappers! Learning C++ helps you wrap those pesky C++ dlls for consumption in C#!
That said, there are quite possibly other things you should be learning before C++ if you're a C# programmer who never learned C++ in the first place.
You'd get more utility out of learning a functional language like Clojure, Haskel (or maybe F# given you obviously feel comfortable with CLR). They have a different underlying programming model which will expand your horizons in ways that learning a new syntax will not.
In the other direction, learning C would actually be much more useful than learning C++. That will focus your learning on pointers, memory, and 'close to the metal' topics.
2015 Update
Learn Swift. It will teach you the same use of functional and generative patterns as modern C++ but without the baggage or as many gotchas. It's also semantically a significant overlap with F# so you get a chance to study functional programming. There's a vibrant functional community pushing the bounds of Swift.
Ironically, in my current day job on C# bindings for Realm, I'm still using my C++ skills alongside C# but not much has changed my attitude in the last 6 years.
Original
I speak as a C++ programmer for 15+ years who has spent the last year learning and using C# (and C++/CLI), on top of an ongoing fascination with languages and a broad range of studying other languages to improve my thinking.
I am very very impressed with C# as a language, especially with the improvements in C# 3.0.
I would take the contrary views:
Unless you want employment writing computer games, or relatively low-level components, forget about C++ as a language because there are enough skilled C++ programmers out there and the gaming industry generates a lot more (of presumably varying quality). It is not going to improve your career prospects.
Do invest some time into studying the interesting depths of C#, the implications of operator overloading, how to use unsafe code etc. Pick up a book like the excellent C# in a Nutshell and be able to go through and annotate all the content with deeper explanations of how that idiom might be used.
Learn a dynamic language like Ruby or Python, use it for some real-world tasks such as generating or mangling test files, so you appreciate the simpler language for manipulating files, structures and strings.
Learn F# or another function language and develop a few smirks of your own about the implications of functional languages for parallel processing and clouds :-) In a few years time (or earlier) this will yield huge career benefits when people are scrambling for cloud-savvy programmers. Remember, you haven't learned a new language until you can compare it to the old ones so you need to be able to pontificate about when and where to use F# (or Haskell) instead of C#.
In terms of performance, it is a lot faster. If you have any desire to do game programming or high-performance computing, C++ is a great language for that.
But, I would also say C++ is very difficult to learn. No garbage collector, compile errors that need to be deciphered, and the need for external libraries are all difficulties to overcome.
Regarding C/C++, here are a few things that come to mind out of my own experience.
Learning C/C++ can provide experience working more closely with detailed operating system features and with raw memory. For example, many Audio, Video, and Game applications require this level of access to perform at their best.
Knowing how to interop with components and libraries written in C/C++ is a handy skill. There are many useful libraries out there that still do not have adequate equivalents in C#. TSAPI (telephony), various file format libraries, and legacy components are much easier to work with in C# if you understand their construction in C/C++ and other languages.
If you are working with windows applications, having experience with Win32 through C/C++ allows you to understand how a number of other applications written in non-managed code work; even if you do not have the source code available to you. You can then use P/Invoke more effectively to deal with libraries that would ordinariliy be unavailable or too opaque to handle otherwise.
Many techniques, though potentially black-hat in nature, are tougher to accomplish with C#. Things like DLL substitution, re-writing function entry points, injecting code into other processes, and generating inline assembly code are easier to do with C/C++; though not impossible with C#.
Finally, fine tuned control over un-managed objects is something better suited to code written with C/C++. For example, things like overlapped I/O on windows, some socket library features (ex. UDP Multicast), and device control have more working C/C++ examples out there than C#. But, these are quite esoteric and usually not handled in C# applications anyways. Some of these are likely to have equivalents in future APIs or frameworks as well.
In summary, the main motivation I would suggest for learning C/C++ is to broaden your knowledge of other systems that are not accessible in C#. Learning Python would be a step in the other direction, where learning other styles and semantics of code construction is a more likely benefit. C/C++ code written by other people tends not to have more beneficial nor recognizable patterns like software written in Python, Ruby, or Lisp.
The best reasons for learning C++ for a C# developer is to learn new programming paradigms. C++ is more than just an "object oriented" language and hence offers a chance to learn new approaches to solving problems. With C# 3.0 and .NET 3.5, C++ doesn't affer as many unique paradigms, but if you are not using them, then effective C++ programming will force you to learn them.
In particular, C++ still offers a very powerful generic programming paradigm that is unmatched by C#. The STL forces you to use functional programming concepts that many C# developers avoid or don't use (LINQ extensions and lambda's for example).
I've also found that it strengthens a persons understanding and appreciation for lexical scope. Concepts such as RAII or C++ namespaces really push the need to manage scope very carefully... in C#, many of these concerns exist, but are less "in your face". Template metaprogramming is another unique concept that C++ offers that C# doesn't.
Learn C++ so that you can feel like blowing your brains out.
With every programming language you're able grow your vision of the landscape and apply lessons learned. Although I have never written a production C++ application, it was very educational for me to understand the system at that level. If you have the spare time, dive in! You may also want to explore unsafe C# code. It could help you understand many of the advanced capabilities of C++.
In order to respect the OP's wishes I won't say anything about how I think C++ can help a C# programmer think differently about code. ;-p
Seriously though, as a tool the main advantage of C++ is that it is multi-platform. Code written in C++ can be run on a huge variety of platforms.
On the other hand the big disadvantage of C++ compared to C# is that it takes a lot longer to write correct code.
While it is possible to write faster code in C++ in theory this assumes an unlimited amount of development time. In practice because I can write more sophisticated code more quickly in C#, I can spend the extra time optimizing the code.
It depends what programs you're working on. I've never used Python before, so I can't comment on that.
As for C++; most performance critical software is written in it due to its speed. You have more power over your hardware, but with that power comes responsibility and a steeper learning curve. It also doesn't have access to .NET; so you'll probably have to dig into Win32 programming for doing some of the tasks!
Examples of where C++ is used: Game development, aerospace, air traffic control systems.
Personally, I think that learning C/C++ makes you a better programmer overall, it teaches you many things; especially about performance and memory. And also well.. pretty much everything important is built in C++.
First off, It sounds like your interested in learning more. That is really the most important part of being a good programmer.
That said; Almost all big open source projects are written in C or C++, if you want to leverage or build on top of those you need to know the language. Not only is working with a large open source project look great on the resume, it also let's you examine some really good (and really bad) code. For me that alone has been a invaluable learning experience.
The primary reason to learn any new or different language is to learn a new and different approaches to solving problems in programming. C# and C++ certainly have some similarities. They also have some pretty substantial differences. At first, those differences will seem (as a few have mentioned) to be primarily with syntax. Further study, however, will reveal considerably greater differences that go well beyond simple syntax.
That means that if you decide to study C++, you need to plan on dedicating a fair amount of time and effort to it before you gain much. If you want something that's radically different from the get-go, you'd probably be better off with something else. My own advice for a completely different language would be Scheme -- basically Lisp with a good housecleaning.
There are lots of other functional languages, and some of them are pretty cool -- but Lisp has outlived a lot of would-be successors, and I think it'll outlive quite a few more. If I were a betting man, I'd bet on Lisp outliving F# by several decades...
I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.
IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.
Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.
If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.
I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.
Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.
If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.
+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.
Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.
.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
As I posted earlier here I've decided to try my hand at one of these, but given my interests as a web developer, I'd like to know the difference between them in their real-world applications.
Edit Note:
While I'm a web developer, please don't let that limit your answer. I'm 30...I've got years of career changing ahead of me.
Bear in mind that I speak ASFAC++B. :) I've put the most important differentiating factor first.
Garbage Collection
Garbage Collection (GC) is the single most important factor in differentiating between these languages.
While C and C++ can be used with GC, it is a bolted-on afterthought and cannot be made to work as well (the best known is here) - it has to be "conservative" which means that it cannot collect all unused memory.
C# is designed from the ground up to work on a GC platform, with standard libraries also designed that way. It makes an absolutely fundamental difference to developer productivity that has to be experienced to be believed.
There is a belief widespread among C/C++ users that GC equates with "bad performance". But this is out-of-date folklore (even the Boehm collector on C/C++ performs much better than most people expect it to). The typical fear is of "long pauses" where the program stops so the GC can do some work. But in reality these long pauses happen with non-GC programs, because they run on top of a virtual memory system, which occasionally interrupts to move data between physical memory and disk.
There is also widespread belief that GC can be replaced with shared_ptr, but it can't; the irony is that in a multi-threaded program, shared_ptr is slower than a GC-based system.
There are environments that are so frugal that GC isn't practical - but these are increasingly rare. Cell phones typically have GC. The CLR's GC that C# typically runs on appears to be state-of-the-art.
Since adopting C# about 18 months ago I've gone through several phases of pure performance tuning with a profiler, and the GC is so efficient that it is practically invisible during the operation of the program.
GC is not a panacea, it doesn't solve all programming problems, it only really cleans up memory allocation, if you're allocating very large memory blocks then you will still need to take some care, and it is still possible to have what amounts to a memory leak in a sufficiently complex program - and yet, the effect of GC on productivity makes it a pretty close approximation to a panacea!
Undefined Behaviour
C++ is founded on the notion of undefined behaviour. That is, the language specification defines the outcome of certain narrowly defined usages of language features, and describes all other usages as causing undefined behaviour, meaning in principle that the operation could have any outcome at all (in practice this means hard-to-diagnose bugs involving apparently non-deterministic corruption of data).
Almost everything about C++ touches on undefined behaviour. Even very nice forthcoming features like lambda expressions can easily be used as convenient way to corrupt the stack (capture a local by reference, allow the lambda instance to outlive the local).
C# is founded on the principle that all possible operations should have defined behaviour. The worst that can happen is an exception is thrown. This completely changes the experience of software construction.
(There's unsafe mode, which has pointers and therefore undefined behaviour, but that is strongly discouraged for general use - think of it as analogous to embedded assembly language.)
Complexity
In terms of complexity, C++ has to be singled out, especially if we consider the very-soon-to-be standardized new version. C++ does absolutely everything it can to make itself effective, short of assuming GC, and as a result it has an awesome learning curve. The language designers excuse much of this by saying "Those features are only for library authors, not ordinary users" - but to be truly effective in any language, you need to build your code as reusable libraries. So you can't escape.
On the positive side, C++ is so complex, it's like a playground for nerds! I can assure you that you would have a lot of fun learning how it all fits together. But I can't seriously recommend it as a basis for productive new work (oh, the wasted years...) on mainstream platforms.
C keeps the language simple (simple in the sense of "the compiler is easy to write"), but this makes the coding techniques more arcane.
Note that not all new language features equate with added complexity. Some language features are described as "syntactic sugar", because they are shorthand that the compiler expands for you. This is a good way to think of a great deal of the enhancements to C# over recent years. The language standard even specifies some features by giving the translation to longhand, e.g. using statement expands into try/finally.
At one point, it was possible to think of C++ templates in the same way. But they've since become so powerful that they are now form the basis of a whole separate dimension of the language, with its own enthusiastic user communities and idioms.
Libraries
The strangest thing about C and C++ is that they don't have a standard interchangeable form of pre-compiled library. Integrating someone else's code into your project is always a little fiddly, with obscure decisions to be made about how you'll be linking to it.
Also, the standard library is extremely basic - C++ has a complete set of data structures and a way of representing strings (std::string), but that's still minimal. Is there a standard way of finding a list of files in a directory? Amazingly, no! Is there standard library support for parsing or generating XML? No. What about accessing databases? Be serious! Writing a web site back-end? Are you crazy? etc.
So you have to go hunting further afield. For XML, try Xerces. But does it use std::string to represent strings? Of course not!
And do all these third-party libraries have their own bizarre customs for naming classes and functions? You betcha!
The situation in C# couldn't be more different; the fundamentals were in place from the start, so everything inter-operates beautifully (and because the fundamentals are supplied by the CLR, there is cross-language support).
It's not all perfect; generics should have been in place from the start but wasn't, which does leave a visible scar on some older libraries; but it is usually trivial to fix this externally. Also a number of popular libraries are ported from Java, which isn't as good a fit as it first appears.
Closures (Anonymous Methods with Local Variable Capture)
Java and C are practically the last remaining mainstream languages to lack closures, and libraries can be designed and used much more neatly with them than without (this is one reason why ported Java libraries sometimes seem clunky to a C# user).
The amusing thing about C++ is that its standard library was designed as if closures were available in the language (container types, <algorithm>, <functional>). Then ten years went by, and now they're finally being added! They will have a huge impact (although, as noted above, they leak underfined behaviour).
C# and JavaScript are the most widely used languages in which closures are "idiomatically established". (The major difference between those languages being that C# is statically typed while JavaScript is dynamically typed).
Platform Support
I've put this last only because it doesn't appear to differentiate these languages as much as you might think. All these languages can run on multiple OSes and machine architectures. C is the most widely-supported, then C++, and finally C# (although C# can be used on most major platforms thanks to an open source implementation called Mono).
My experience of porting C++ programs between Windows and various Unix flavours was unpleasant. I've never tried porting anything very complex in C# to Mono, so I can't comment on that.
Both C and C++ give you a lower level of abstraction that, with increased complexity, provides a breadth of access to underlying machine functionality that are not necessarily exposed with other languages. Compared to C, C++ adds the convenience of a fully object oriented language(reduced development time) which can, potentially, add an additional performance cost. In terms of real world applications, I see these languages applied in the following domains:
C
Kernel level software.
Hardware device drivers
Applications where access to old, stable code is required.
C,C++
Application or Server development where memory management needs to be fine tuned (and can't be left to generic garbage collection solutions).
Development environments that require access to libraries that do not interface well with more modern managed languages.
Although managed C++ can be used to access the .NET framework, it is not a seamless transition.
C# provides a managed memory model that adds a higher level of abstraction again. This level of abstraction adds convenience and improves development times, but complicates access to lower level APIs and makes specialized performance requirements problematic.
It is certainly possible to implement extremely high performance software in a managed memory environment, but awareness of the implications is essential.
The syntax of C# is certainly less demanding (and error prone) than C/C++ and has, for the initiated programmer, a shallower learning curve.
C#
Rapid client application development.
High performance Server development (StackOverflow for example) that benefits from the .NET framework.
Applications that require the benefits of the .NET framework in the language it was designed for.
Johannes Rössel makes the valid point that the use C# Pointers, Unsafe and Unchecked keywords break through the layer of abstraction upon which C# is built. I would emphasize that type of programming is the exception to most C# development scenarios and not a fundamental part of the language (as is the case with C/C++).
C is the bare-bones, simple, clean language that makes you do everything yourself. It doesn't hold your hand, it doesn't stop you from shooting yourself in the foot. But it has everything you need to do what you want.
C++ is C with classes added, and then a whole bunch of other things, and then some more stuff. It doesn't hold your hand, but it'll let you hold your own hand, with add-on GC, or RAII and smart-pointers. If there's something you want to accomplish, chances are there's a way to abuse the template system to give you a relatively easy syntax for it. (moreso with C++0x). This complexity also gives you the power to accidentally create a dozen instances of yourself and shoot them all in the foot.
C# is Microsoft's stab at improving on C++ and Java. Tons of syntactical features, but no where near the complexity of C++. It runs in a full managed environment, so memory management is done for you. It does let you "get dirty" and use unsafe code if you need to, but it's not the default, and you have to do some work to shoot yourself.
My opinion is C# and ASP.NET would be the best of the three for development that is web biased.
I doubt anyone writes new web apps in C or C++ anymore. It was done 10 years ago, and there's likely a lot of legacy code still in use, but they're not particularly well suited, there doesn't appear to be as much (ongoing) tool support, and they probably have a small active community that does web development (except perhaps for web server development). I wrote many website C++ COM objects back in the day, but C# is far more productive that there's no compelling reason to code C or C++ (in this context) unless you need to.
I do still write C++ if necessary, but it's typically for a small problem domain. e.g. communicating from C# via P/Invoke to old C-style dll's - doing some things that are downright clumsy in C# were a breeze to create a C++ COM object as a bridge.
The nice thing with C# is that you can also easily transfer into writing Windows and Console apps and stay in C#. With Mono you're also not limited to Windows (although you may be limited to which libraries you use).
Anyways this is all from a web-biased perspective. If you asked about embedded devices I'd say C or C++. You could argue none of these are suited for web development, but C#/ASP.NET is pretty slick, it works well, there are heaps of online resources, a huge community, and free dev tools.
So from a real-world perspective, picking only one of C#, C++ and C as requested, as a general rule, you're better to stick with C#.
C - an older programming language that is described as Hands-on. As the programmer you must tell the program to do everything. Also this language will let you do almost anything. It does not support object orriented code. Thus no classes.
C++ - an extention language per se of C. In C code ++ means increment 1. Thus C++ is better than C. It allows for highly controlled object orriented code. Once again a very hands on language that goes into MUCH detail.
C# - Full object orriented code resembling the style of C/C++ code. This is really closer to JAVA. C# is the latest version of the C style languages and is very good for developing web applications.
From your other posts, I guess you want to learn a new language to get new skills. My advice is that the language is not really important, what is important is the quality of its community (advice, but also existing code you can read and learn from) and the available libraries/frameworks. In this respect, I think the "C family" is not the best choice for you: web libraries and frameworks are few, not portable and not great, and coding style of code you can study varies a lot and may confuse you a lot (although C is my favorite language).
I would advise to just learn C, and try to really understand the concept of pointers, then move to other languages more adapted to the web (Python or JavaScript comes to mind - or even Java). Also, in the C family, Objective-C has the best mix of power and simplicity in my opinion, but is a niche player.
C is the core language that most closely resembles and directly translates into CPU machine code. CPUs follow instructions that move, add, logically combine, compare, jump, push and pop. C does exactly this using much easier syntax. If you study the disassembly, you can learn to write C code that is just as fast and compact as assembly. It is my preferred language on 8 bit micro controllers with limited memory. If you write a large PC program in C you will get into trouble because of its limited organization. That is where object oriented programming becomes powerful. The ability of C++ and C# classes to contain data and functions together enforces organization which in turn allows more complex operability over C. C++ was essential for quick processing in the past when CPUs only had one core. I am beginning to learn C# now. Its class only structure appears to enforce a higher degree of organization than C++ which should ultimately lead to faster development and promote code sharing. C# is not interpreted like VB. It is partially compiled at development time and then further translated at run time to become more platform friendly.
For raw speed, use C. For power, use C++. For .NET compatibility, use C#.
They're all pretty complex as languages go; C through decades of gradual accretion, C++ through years of more rapid enhancement, and C# through the power of Microsoft.
I was just wondering what language would be a good choice for developing a game server to support a large (thousands) number of users? I dabbled in python, but realized that it would just be too much trouble since it doesn't spawn threads across cores (meaning an 8 core server=1 core server). I also didn't really like the language (that "self" stuff grossed me out).
I know that C++ is the language for the job in terms of performance, but I hate it. I don't want to deal with its sloppy syntax and I like my hand to be held by managed languages. This brings me to C# and Java, but I am open to other languages. I love the simplicity of .NET, but I was wondering if, speed wise, this would be good for the job. Keep in mind since this will be deployed on a Linux server, it would be running on the Mono framework - not sure if that matters. I know that Java is syntax-wise very similar to .Net, but my experience with it is limited. Are there any frameworks out there for it or anthing to ease in the development?
Please help me and my picky self arrive on a solution.
UPDATE: I didn't mean to sound so picky, and I really don't think I was. The only language I really excluded was C++, Python I don't like because of the scalability problem. I know that there are ways of communicating between processes, but if I have an 8 core server, why should I need to make 8 processes? Is there a more elegant solution?
I hate to say it, and I know I'm risking a down mod here, but it doesn't sound like there's a language out there for you. All programming languages have their quirks and programmers simply have to adapt to them. It's completely possible to write a working server in Python without classes (eliminating the "self" variable class references) and likewise just as easy to write C++ with clean syntax.
If you're looking to deploy cross-platform and want to develop cross-platform as well, your best bet would probably be Java. It shorter development cycles than compiled languages like C and C++, but is higher performance (arguable, but I've always been anti-Java =P) than interpreted languages like Python and Perl and you don't have to work with unofficial implementations like Mono that may from time to time not support all of a language's features.
I might be going slightly off-topic here, but the topic interests me as I have (hobby-wise) worked on quite a few game servers (MMORPG servers) - on others' code as well as mine. There is literature out there that will be of interest to you, drop me a note if you want some references.
One thing that strikes me in your question is the want to serve a thousand users off a multithreaded application. From my humble experience, that does not work too well. :-)
When you serve thousands of users you want a design that is as modular as possible, because one of your primary goals will be to keep the service as a whole up and running. Game servers tend to be rather complex, so there will be quite a few show-stopping bugs. Don't make your life miserable with a single point of failure (one application!).
Instead, try to build multiple processes that can run on a multitude of hosts. My humble suggestion is the following:
Make them independent, so a failing process will be irrelevant to the service.
Make them small, so that the different parts of the service and how they interact are easy to grasp.
Don't let users communicate with the gamelogic OR DB directly. Write a proxy - network stacks can and will show odd behaviour on different architectures when you have a multitude of users. Also make sure that you can later "clean"/filter what the proxies forward.
Have a process that will only monitor other processes to see if they are still working properly, with the ability to restart parts.
Make them distributable. Coordinate processes via TCP from the start or you will run into scalability problems.
If you have large landscapes, consider means to dynamically divide load by dividing servers by geography. Don't have every backend process hold all the data in memory.
I have ported a few such engines written in C++ and C# for hosts operating on Linux, FreeBSD and also Solaris (on an old UltraSparc IIi - yes, mono still runs there :). From my experience, C# is well fast enough, considering on what ancient hardware it operates on that sparc machine.
The industry (as far as I know) tends to use a lot of C++ for the serving work and embeds scripting languages for the actual game logic. Ah, written too much already - way cool topic.
Erlang is a language which is designed around concurrency and distribution over several servers, which is perfect for server software. Some links about Erlang and game-servers:
http://www.devmaster.net/articles/mmo-scalable-server/
http://www.erlang-consulting.com/euc2005/mmog/mmog_in_erlang.htm
I'm thinking of writing a game-server in Erlang myself.
Speaking of pure performance, if you can run Java 6 you get about 1:1 performance when compared to optimized C++ (special cases notwithstanding, sometimes Java is faster, sometimes C++), the only problem you will have is of course stuff like database libraries, interconnectivity, scalability and such. I believe there's a variety of good to great solutions available to each of these problems but you won't find one language which would solve everything for you so I have to give you the age old advice: Choose the language you like and use that one.
Oh, you're still reading this? :) Well, here's some extra pointers.
EVE Online uses Python for its client and server side code and it's both bug-ridden and laggy as something I don't think I should write here so that'd be an example of how Python can be extended to (poorly) serve vast amounts of users.
While Java has some good to great solutions to various related problems, it's really not the best language out there for vast amount of users; it doesn't scale well to extremes without tuning. However there's multi-VM solutions to this which somewhat fix the issue, for example Terracotta is said to do the job well.
While C++ is rather cumbersome, it allows for such a low-level interaction with the system that you may actually find yourself doing things you thought you couldn't do. I'm thinking of something like dynamic per-core microclustering of runtime code blocks for "filling" every possible clock cycle of the processor as efficiently as possible for maximum performance and things like that.
Mono is far behind the .NET VM/equivalent on Windows platforms so you wouldn't be able to use the latest and fanciest features of C#. However Windows XP (x64) OEM licenses are so laughably cheap at the moment that with small investment you could get a bunch of those and you could then run your code on the platform it was meant to be. And don't fall into the Linux hype, Linux is your saviour only if you really know how to use it and especially XP is pretty damn fast and stable nowadays.
What kind of performance do you need?
twisted is great for servers that need lots of concurrency, as is erlang. Either supports massive concurrency easily and has facilities for distributed computing.
If you want to span more than one core in a python app, do the same thing you'd do if you wanted to span more than one machine — run more than one process.
More details about this game server might help folks better answer your question. Is this a game server in the sense of something like a Counter Strike dedicated server which sits in the background and hosts multiplayer interactions or are you writing something which will be hosted on an HTTP webserver?
Personally, if it were me, I'd be considering Java or C++. My personal preference and skill set would probably lead me towards C++ because I find Java clumsy to work with on both platforms (moreso on Linux) and don't have the confidence that C# is ready for prime-time in Linux yet.
That said, you also need to have a pretty significant community hammering on said server before performance of your language is going to be so problematic. My advise would be to write it in whatever language you can at the moment and if your game grows to be of sufficient size, invest in a rewrite at that time.
You could as well use Java and compile the code using GCC to a native executable.
That way you don't get the performance hit of the bytecode engine (Yes, I know - Java out of the box is as fast as C++. It must be just me who always measures a factor 5 performance difference). The drawback is that the GCC Java-frontend does not support all of the Java 1.6 language features.
Another choice would be to use your language of choice, get the code working first and then move the performance critical stuff into native code. Nearly all languages support binding to compiled libraries.
That does not solve your "python does not multithread well"-problem, but it gives you more choices.
The obvious candidates are Java and Erlang:
Pro Java:
ease of development
good development environments
stability, good stack traces
well-known (easy to find experienced programmers, lots of libraries, books, ...)
quite fast, mature VM
Pro Erlang:
proven in systems that need >99.9% uptime
ability to have software updates without downtime
scalable (not only multi-core, but also multi-machine)
Contra Erlang:
unfamiliar syntax and programming paradigm
not so well known; hard to get experienced programmers for
VM is not nearly as fast as java
If your game server mainly works as a event dispatcher (with a bit of a database tucked on), Erlang's message-driven paradigm should be a good match.
In this day and age, I would not consider using an unmanaged language (like C or C++); the marginal performance benefits simply aren't worth the hassle.
It may depend a lot on what language your "game logic" (you may know this term as "business logic") is best expressed in. For example, if the game logic is best expressed in Python (or any other particular language) it might be best to just write it in Python and deal with the performance issues the hard way with either multi-threading or clustering. Even though it may cost you a lot of time to get the performance you want out of Python it will be less that the time it will take you to express "player A now casts a level 70 Spell of darkness in the radius of 7 units effecting all units that have spoken with player B and .... " in C++.
Something else to consider is what protocol you will be using to communicate with the clients. If you have a complex binary protocol C++ may be easier (esp. if you already had experience doing it before) while a JSON (or similar) may be easier to parse in Python. Yes, i know C++ and python aren't languages you are limited to (or even considering) but i'm refer to them generally here.
Probably comes down to what language you are the best at. A poorly written program which you hated writing will be worse that one written in a language you know and enjoy, even if the poorly written program was in an arguable more powerful language.
You could also look at jRuby. It comes with lots of the benefits of Java and lots of the benefits of Ruby in one neat package. You'll have access to huge libraries from both languages.
What are your objectives? Not the creation of the game itself, but why are you creating it?
If you're doing it to learn a new language, then pick the one that seems the most interesting to you (i.e., the one you most want to learn).
If it is for any other reason, then the best language will be the one that you already know best and enjoy using most. This will allow you to focus on working out the game logic and getting something up and running so that you can see progress and remain motivated to continue, rather than getting bogged down in details of the language you're using and losing interest.
If your favorite language proves inadequate in some ways (too slow, not expressive enough, whatever), then you can rewrite the problem sections in a more suitable language when issues come up - and you won't know the best language to address the specific problems until you know what the problems end up being. Even if your chosen language proves entirely unsuitable for final production use and the whole thing has to be rewritten, it will give you a working prototype with tested game logic, which will make dealing with the new language far easier.
You could take a look at Stackless Python. It's an alternative Python interpreter that provides greater support for concurrency. Both EVE Online's server and client software use Stackless Python.
Disclaimer: I haven't used Stackless Python extensively myself, so I can't provide any first-hand accounts of its effectiveness.
There is a pretty cool framework in development that addresses all your needs:
Project Darkstar from Sun. So I'd say Java seems to be a good language for game server development :-)
I know facebook uses a combination of Erlang and C++ for their chat engine.
Whatever you decide, if you choose a combination of languages, check out facebook's thrift framework for cross language services deployment. They open sourced it about a year+ back:
http://incubator.apache.org/thrift/
C++ and Java are quite slow compared to C. The language should be a tool but not a crutch.