ENIGMA Development Environment

Not sure how to deal with DLLs, but usually I'd compile my source code with option '-g', then call "gdb executablename", then use command "run" and then, after it crashed, "backtrace".

You're missing the [][] in all cases, not just the first.

In this case, all three are basically the same. However, note that when *calling* the function, there are differences(array vs &array. when using plain integers instead of int** or int[][] there's also the problem of using constants with reference members).
Finally, if instead of int[][] we were talking about some big data member, such as a huge class/struct, then using the * or & would be use less memory and would probably be faster.

truly amazing (...) in a bit

Are you going to announce that ENIGMA R4 is so efficient that games written in it can fill in a single bit?

"Also, that same bloat can get in the way of adding new features to C++."
Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.

Well, judging by the horrible ugly syntax of lambdas in C++0x, it would appear they don't have many options without introducing syntactical ambiguity.

Singularity's one screen shot was so transparently propaganda-laden it made me sick.

Well, Singularity's core innovation was being in pseudo-C#(I think it's not exactly C#, but I can't remember), so obviously there wasn't much impressive about it aside from that fact and, therefore, being written in C# was probably the only notable detail about Singularity.

Of course, C# is my least favorite example of such languages, and there are far better ways of accomplishing type safety that don't end up removing mad pointer tricks as a method of accomplishing something.

That could be the root of our disagreements. C# is my favorite language(although I notably hate C# APIs).
BTW, C# has pointers. Both IntPtr(a nice safe way to deal with them) and ordinary *& C syntax. The first way is often used with P/Invokes. The second way requires the "unsafe" keyword to be used since, well, it's unsafe. I never needed to use the second syntax. The first syntax I only used for P/Invokes.

...Until you need to pass arguments that aren't strings.

Well, Brainfuck has integers. It can represent any type C can. It can represent pointers(in fact, Brainfuck is designed on the concept of pointers), it can represent integers, floating point(see IEEE 754 for how to represent float in integers), it can represent characters and, with that, it can represent strings, structs and unions. So, basically, Brainfuck(with those few command extensions) could do anything.

By RetroX's definition, there are no infinite loops, then.

Also, kernels don't need to have main methods. They often have some sort of replacement, but the name "main" doesn't imply being the entry point in kernels.

know what is a pointer and what is not, and that is impossible in C++.

You disagree with this, Josh?
Tell me, how many variables are pointing to 0x043030FE in your program. You can't ever be sure in C++. In Java, you can.
So you're left with few options:
1. You use something like Pointer<T> instead of T*. It's ugly, you still need to figure out circular references(which somehow means you need the stack trace too, yet another problem C++ makes hard to solve). You can of course just have a simple reference counter and somehow hope nobody messes around with it. Possible and I've used this method before. Still, templates mean worse compile times, harder-to-read code, and it's still unable to deal with cyclic references.
2. You iterate through the whole memory and build a conservative memory collector. Less painful to handle since you can use ordinary pointers, but it's still vulnerable to circular references and it can't be sure whether something is a pointer or something else. Say, if an integer has value 0x043030FE for some unrelated reason, a leak occurs.
3. You use macros or something else to register the stack.
void myfunction(StackPosition& pos) {
  pos.push();

  Pointer<int> p(pos, new int(5));

  pos.pop(); //p is released here
}
that plus several more tricks could possibly solve, but it's simply pain ugly and makes code readability worse.
4. You use something like a C++ preprocessor to automatically generate solution 3 in a pretty way. At this point, you can barely call it C++.

Destructors are useful, and garbage collectors could be built to take advantage of them. However, while destructors can simplify some memory management, they aren't enough by themselves to replace GCs.

People get used to strings; I myself have become spoiled by them, and feel so every time I use them. C gave no way of returning new strings, save allocating them yourself. With C++, std::string is a great example of how the annoying bits are handled for you. String keeps its own reference count at the beginning of the char* in memory. When you return a string in C++, the constructor of the new string increments that count, the destructor of the old string then decrements it, and a string is returned with no manual allocation.

Shame on them. They dared to automatically dispose of strings in C++? BUT THAT'S SO INEFFICIENT!!!
That aside, strings in C++ are often much better than const char*s, for similar reasons that GCs are often much better than manual memory freeing system.

Is it possible to get C++ to wipe all the memory management ickiness off your ass for you? No.

Therefore, when it comes to wiping out the memory management ickiness, other languages are better.

Personally, all considered, I prefer it that way.

For some use-cases, that indeed is the best way.
For most applications, memory management is not the problem we're trying to solve. We're trying to render a document, to figure out what 3D position the 2D mouse click refers to in the computer game or what GM version the read file refers to. In those cases, memory management is an obstacle.

Either way, regarding bloatness, a quote from one of Go's designers:

it wasn't enough to just add features to existing programming languages, because sometimes you can get more in the long run by taking things away.

I have no doubt that if we could just forget legacy and design C++ from the bottom up, we could come up with something really good.
Unfortunately, C++ is not that language.

Even though I don't think C++'s feature set is needed for the vast majority of applications, one can actually see how it can be useful. But just not C++. C++ has so much legacy that adding anything to the language is painful.

Also, C++ isn't infinitively extensible. At some point, it's better to just design a C++-made VM and use something else. Garbage collection(yes, it is useful) is notably bad in C++. Although I heard they intend to add it to a later version, I just don't see any way to add it nicely.