Two big reasons come to mind:

Standard Library Support
The C++ Standard Library lacks data structures, algorithms, and functionality that other "higher-level" languages like C# have for standard support. C++11 added a good amount of new functionality to C++'s Standard Library, but think about it: before C++11, there was no support for threads in C++'s Standard Library (whereas Java, Python, C#, etc. offer support for threads right out of the box). As another example, there is no networking/sockets support in C++'s Standard Library, but other languages again provide support for this right out of the box. The list of (commonly used/needed) features missing in C++ and its Standard Library is quite long. So developers have to spend a good amount of time in C++ either a) re-inventing the wheel, b) finding, downloading, compiling, and debugging 3rd party libraries, or c) picking a different language, where the list of lacking features is much smaller.

Bugs
The father of C++, Bjarne Stroustrup, has said "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." Other languages, like C#, Java, Python, etc. try to protect you from yourself. But let's be honest. We all make mistakes (even if you don't want to admit it (*cough* Linus *cough*)). In C++ (and C), there are lots of places in the standard where it says "undefined behavior," "unspecified behavior," and "implementation defined behavior." It says these things a lot. There are lots of times you can do something totally wrong in C++, but you'll have no clue because it magically works (and you somehow think you wrote valid code). It works because the C++ standard doesn't say "doing x will not work and will result in the program crashing." It says "doing x is undefined," and who knows, it may work today and then crash your program tomorrow. But let that subtle bug of undefined behavior you introduced sit in your code base for a few months, and suddenly BOOM! Your program starts crashing. Now you've got to stop what your doing and dig through your code with your debugger. Other languages try to make it easier by a) making it so you can do less wrong, and b) telling you as soon as you do something wrong so you don't build an entire system on a broken foundation. Even if you don't introduce a bug in your C++ code, there's a good amount of mental book keeping and edge case handling that must be done to avoid these bugs, and this can also slow you down.

Is it just about compile time, which seems to be the reason that developing in a scripting language is faster than a compiled one?

Not _just_ but it helps.

Does it have to do with memory management and garbage collection, because it just takes forever to remember to delete your pointers?

That helps, but isn't a huge contributor.

Possibly it involves inherent access to libraries or functions such as the printf("") in Python as compared to cout << "" in C++, is that the case?

This is a big one. Even basic stuff like unicode strings and a sane date class are simply non-existent in core C++.

Another big contributor is the lack of tooling (static analysis, good intellisense, good refactoring support, good debugger tie ins) that C++ suffers from due to issues in its design. So C# developers fix syntax errors quicker, identify bugs faster, and generally spend more time making stuff go than figuring out what C++ bear trap they stepped in now.

the performance of that running code is worse.

While that is the consensus, it is (at the very least) debatable. Skill of the developer and the problem at hand matter a lot more to that sort of thing than some inherent language disparity.

Even basic stuff like unicode strings [...] are simply non-existent in core C++.

Just to expand on this: [font=courier new,courier,monospace]std::basic_string[/font] doesn't really care about encoding, and although C++ has some support for unicode (like [font=courier new,courier,monospace]char[/font] being required to be at least 8 bits so it can be used in UTF-8 strings), it (and other algorithms/functions in C++ that deal with strings) doesn't work with actual unicode code points. [font=courier new,courier,monospace]std::string::length()[/font] won't return the number of UTF-8 code points in the string; it just returns the number of code units. Gotchas like this can make something that seems like it should be a simple operation into a rather complex and time consuming (development wise) one.

I see a lot of comments about how writing code in something like C# is faster than C++, and I fail to understand why. This has nothing to do with performance of applications; simply the difference in taking say 3 weeks to develop in a certain language and 6 in another. Also, I am really just concerned with mainstream languages such as C#, C++, VB, Java, Lua, Python, etc.

Which of the following could you do faster:
1) Write an essay with perfect grammar/spelling on the First World War in English?
2) Write an essay with perfect grammar/spelling on the First World War in Japanese; using a textbook and translation software?

Obviously, you will be able to deal with the English essay much faster (unless, by some chance, you're a native Japanese speaker). English is what makes sense to you. It's grammar (syntax) is familiar to you and just seems "right", as you've grown up speaking, reading and writing it. You focus your time on the quality and content of the essay, rather than struggling with the language itself. Likewise, some programming languages are more familiar to humans while others are more cryptic and difficult to read/comprehend.

Take a look at the language called brainfuck...yes, it's a real language and I'm not trying to use profanity on the forums. It's incredibly cryptic... designed to be obfuscated and virtually unreadable to amuse and challenge programmers. Now, if you will, imagine how much longer it would take you to write a Windows application in brainfuck than it would in C++. C and C++ are much more "human-friendly" and understandable, so you can turn the ideas in your head into working code more easily than you can convert it into cryptic brainfuck or x86 assembly language. This is precisely the answer to your question. As newer languages come out and grow to maturity, many of them become more "human-friendly" than their ancestors. C#, for instance, is a lot more "elegant" and readable than C.

Is it just about compile time, which seems to be the reason that developing in a scripting language is faster than a compiled one?
Does it have to do with memory management and garbage collection, because it just takes forever to remember to delete your pointers?
Possibly it involves inherent access to libraries or functions such as the printf("") in Python as compared to cout << "" in C++, is that the case?

"Compile time" means one of two things: 1) the amount of time it takes to compile code 2) the time when code is compiled. For example:

1) "The compile time for this project is unbelievable! We need to speed up our builds somehow!"
2) "In C#, a readonly variable is assigned at compile-time."

This doesn't have anything to do with how fast you can finish a project in a language because the languages humans find hardest to understand (assembly language, C, C++, etc) tend to compile faster than a managed language like C#.

Basically, I am trying to understand why the general consensus seems to be that writing code in C# (for example) is better than writing code in C++ (for example), but the performance of that running code is worse.

That used to be the "consensus", but not so much anymore... And it has never been a consensus that any practical language was necessarily "better" than another...

About speed, you will be surprised at what a modern C# application can do. I'm amazed every time I do a new project. The real overhead with a .NET application is in the JIT ("Just In Time") compiling process... this is, essentially, when code is compiled on-the-fly as the application runs. The JIT compiler only compiles portions of the IL assembly that are needed. For instance, if the "PrintDocument(string name)" method is never called it is never compiled. JIT compiling slows the application down a bit, but this tends to only occur when the application is starting and everything is being "JIT'ed" or when a particular method is compiled for the first time. Wanna see it yourself? Write a C# method that takes a long time to iterate through a large sequence. Wrap it in the "Action" delegate-type and use a System.Diagnostics timer/stopwatch to time the code. Call it 5x's in a row and record the time it takes to complete. The first call will seem sluggish, but the following 4 will be almost indistinguishable from native code in terms of speed. Why? Because the JIT compiler turned the IL into native code behind the scenes!

I have seen many occassions where a C# application can not only out-perform but burn a C or C++ application (and surprisingly, sometimes even assembly language as hand-written instructions aren't always optimized for speed). The first notable instance I saw of C# outperforming C was when I had to write a special tool for creating software patches for a larger project. My C version performed very well, but we weren't quite pleased with it... Rewrote the entire thing in C#, optimized the code and disabled some of the CLRs checks, and the damn thing outran the C version. But why?

A C# application has a smaller "memory footprint"... only the needed code is compiled to begin with. The CLR manages objects and collects garbage transparently, not only reducing general programming errors and memory leaks but greatly increasing memory efficiency. Once the code is run through the JIT process it is essentially a native binary image itself, with all the added benefits of being a managed application. Imagine how much faster C and C++ would be if they had highly efficient garbage collection, automatic memory management and reduced memory footprints! This is just part of the reason, but some of the most important things.

Of course, results can vary from application to application, programmer to programmer and algorithm to algorithm. But don't fall into the trap of thinking languages have "fixed" performance... they can perform as good (or as awful) as you make them, to a certain extent.

Thank you for these clarifications so far, and I would like to note that I asked this exact question on Stack Overflow and watched it be mocked and closed within minutes. Kudos to the GameDev.net community!

Quick off-topic but in their defense, this wasn't an ideal question for Stack Overflow - even if I agree that they tend to be a bit overzealous with respect to their FAQ. However, it would have made for an excellent Programmers.SE question... Glad you posted here though.

The essential difference is more or less what Paul Graham described as the Blub paradox (approximately half way down, though the overall essay is worth reading too).

If you've ever transitioned from using one language to another, you know this feeling. In the newer language, when you eventually get to the comfortable point, you will generally find that you are either more or less productive than you were (hopefully more, but you might be moving to maintaining something like this).

I felt it when I moved from a Basic dialect to C++, but I didn't know how to program at all back then. Likewise when using Java or C#, I find I get more done than when I write C++. Now, when using something like Ruby I can complete entire programs in a fraction of the time it would take me to write them in Java or C# - an hour instead of half a day (mostly small utilities, I don't believe this particular productivity ratio scales linearly!).

The reasons for this are many, and include:

• Simple syntax (e.g. not perl)
  
• Availability and easy of installing/linking to helper libraries (e.g. Ruby gems vs C libraries)
  
• Consistent naming/behaviour (curse your oily hides PHP/Javascript!)
  
• Strong conventions that eliminate style mismatches
  (e.g. C++ libraries tend to be a mix of variations on old_c_convention with ModernCamelCase, rarely happens in Java or C#).
  
• Language features:
  
  
  
  • Automatic garbage collection and foreach loop (reduce mental overhead)
    
  • First class functions and closure (reduce boilerplate).
    
  • etc...
    

Tool support (good IDE, debuggers, profilers ...)

• Consistent naming/behaviour (curse your oily hides PHP/Javascript!)
  

Forgive me for going off topic, but this line made m LOL. It was a pained LOL, though, with plenty of bitterness. Because, yes. Curse them.

• Language features:
  
  
  
  • Automatic garbage collection and foreach loop (reduce mental overhead)
    
  • First class functions and closure (reduce boilerplate)
    

[/quote]

These are the big ones for me, and why I increasingly use Lua over C++ even though I've been using C++ since the early 90s. It's interesting to see how much time you spend in lower-level languages just ensuring that you are allocating and managing your memory correctly, and tracking down the leaks that still slip through. And the boilerplate that rip-off mentions. You can spend so much time just building the structures upon which to hang things, then even more time building the things to hang on those structures, when the simple choice of using another higher-level language means that a lot of those structures are already built into the language, or are rendered redundant due to alternatives that are now available.

Of course, it all comes down to the exact task you are trying to perform. Languages all have their strong and weak points, and it is important to gain the experience to be able to match up a particular task with the language that most closely matches the requirements of the task. Otherwise, you get bogged down.

The language matters but not as much as the library support and IDE.
When people say 'language' they generally mean 'platform' which includes the whole-shebang not just the language.

C++ was suppose to bring on lots of reuse and lots of libraries but this resulted [generally] in free low-quality libraries or very expensive high-quality libraries (with notable exceptions but generally).
So when you want to create a thread in C++ and have it execute within the context of your class... it's a PITA.
The language isn't thread-aware, the libraries aren't thread-aware, the language is barely object-aware, so you have to write a bunch of esoteric OS-level code to make it happen.
If you want it to be easily usable & dynamic then you have to write a complex template class and it will be buggy and require debugging, etc...

C# already had all of this built in. So creating a thread in C# is a 10 second task whereas it's a day or two of work in C++ if you're starting from scratch.
If you move jobs, you move code-bases, so now you have to relearn their C++ code-base.
Move jobs with C# and you create a thread the same way.


Intellisense was the single most productivity enhancing invention of the 1990's (regarding coding).
Using a language that doesn't have a modern IDE is painful and slows you down.