@ManipUni wrote: The reason C# is good has nothing at all to do with it being managed. Any idiot can learn how to deallocate memory or how pointers work. (*)
A managed (execution environment) or language, if you will, is not equivalent to having automatic memory management (garbage collection) or to not having pointers. Proof: there are several garbage collectors available for native C++ and there are pointers in C#. Managed execution environment means that the code you write is compiled for (and executed by) a virtual machine. Programs written for a VM are much more descriptive and "self-aware" than natively compiled programs. You can build simple-to-use and easy-to-configure environments, it is easy to build binary compatible and easily deployable frameworks. That's why you don't have to deal with piss poor compiler/linker output and what I broadly call the "ecosystem" (*) and far too complex libraries (*) which I'd rather put as "libraries which are far too complex to configure and build correctly".
Although @ManipUni's opinion was expressed a bit too radically, I basically agree with her/him. Simply put: IMHO, adding even more complexity to C++ language could be counter-productive, if the "ecosystem" (= compilers, linkers, build environments, libraries + standardized support for deployment of components, etc...) is not evolving at adequate pace.
While I do appreciate all the efforts to pop the native ANSI C++ back to the foreground, I must admit I am a bit sceptical about all the enthusiasm you guys are spreading... I have been working with native C++ for many years and I was going through all the ups and downs of the language evolution. Today, I must admit, the standardized language starts to connect up to the current (increasingly concurrent, functional and framework-based) way of writing software.
However, in my humble opinion, the biggest progress made in software business during the last decade is the level of abstraction introduced by managed execution environments. It completely changed the way of writing and deploying reusable and extensible software libraries. For those stuck with native C++ exclusively, this part remains hard (Not taking the open source way of deploying software into account here - which is not easy either, take a look at boost and the way it is configured for the various supported platforms - hats off to the boost configuration team...).
Remember Ale Contenti's remark on dozens of string implementations in all the "foundations" and libraries around? One could continue with all the Lists, Arrays, Threads, etc. in Qt, POCO, boost and of course those available from Microsoft via COM, ATL, MFC, or the PPL (which I'd love to see standardized, by the way...). Of course, we all use the standardized C++ library which is a most valuable tool set to use but because of the lack of compatibility between the implementations and no guarantees with regard to binary compatibility it is banned to "internal usage" only.
Long story short: If you are a library writer (you target other developers which reuse you products for their own development) you end up with some kind of own (mostly COM-like) infrastructure which wraps your algorithms and data structures PLUS a plethora of various layers on top of it to make your libraries usable for those who have chosen to use one of the "foundations" mentioned above. This is an annoying and, sort of, fragile part of developing in native C++ and the one which - to paraphrase Mr. Contenti - makes me envy the colleagues from the "managed" world.