Так_забежал_просто LordMADОсобенно приятно читать, как радуются поклонники C# грядущему появлению в "их" языке возможностей, которые программисты на C++ имеют возможность использовать много лет
Ну, они в C++ были, конечно, но пользоваться ими было существенно небезопасно. В C# изначально были только "относительно безопасные" конструкции, вот теперь, сохраняя уровень безопасности, прикрутили к нему похожие на C++ возможности.По поводу разницы между "существенно небезопасно" и "относительно безопасные" - это на форум по маркетингу. Это, очевидно, надо понимать так, что в то время как на C++ у программиста есть возможность выбирать между статическими и простыми assert'ами, на C# это делает компилятор (понятно в пользу какого варианта), не оставляя программисту выбора? И это считается для кого-то благом?
Так_забежал_простоПо теме: C++ - очень стрёмный язык. Ну не хочу я вручную управлять памятью (на каждом шагу рискуя ошибиться), работать с какими-то непонятными указателями (без возможности узнать наверняка, что там библиотека с моим указателем делает), с какими-то непонятными переходами с 32 бит на 64... Чёрт возьми, вообще не хочу знать, сколько бит в моих переменных. Хочу хранить там числа и осмысленные значения, а не указатели на какую-то память.Не вижу связи между C++ и данными утверждениями. Ни одно из них не имеет отношения к этому языку.

Так_забежал_простоНе имеет? Т.е. в C++ нет указателей?Есть, но это не означает, что тебе придется ими пользоваться, если ты считаешь указатели "слишком сложными". C++ педоставляет возможность пользоваться различнымии способами решения одной и той же проблемы.
Так_забежал_простоВ C++ не надо помнить об освобождении памяти?Не надо, если есть такое желание. Можно предоставить это GC.
ак_забежал_простоВ C++ не используются на каждом шагу замечательные типы DWORD и т.д.?Такого типа нет в C++. Этот тип определен в WinAPI (например). Если программа напрямую использует WinAPI - этот тип придется использовать из любого языка. Использовать WinAPI напрямую в наше время имеет смысл при создании чего-то низкоуровневого.
ак_забежал_простоВ C++ нету проблем при переводе приложений с 32 бит на 64?Не больше, чем в C#.

beluginНадо ли для этого переписывать все библиотеки, которые ты собираешься использовать?
Нет. Все уважающие себя библиотеки, включая стандартную, поддерживают GC. Причем не только по принципу "или все или ничего", но и эффективно комбинируя использование обычной кучи, управляемой кучи, пулов и пр.
beluginБудет ли его использование так же гладко как и C#?Более "гладко". Можно избежать многих проблем с GC, которые есть в .net, например, за счет использования нескольких управляемых куч.

beluginМожно ли ткнуть носом в то, как STL поддерживет GC?allocators

Random_Goodmanт. е. никаких проблем что ли?Смотря что считать проблемой. ;) Так же как и для C#, переход с одной платформы на другую (например, с Win32 на Win64) требует перекомпиляции и, если необходимо, повторной оптимизации (связанной с неизбежными недостатками конкретных компиляторов). При этом бывает, что баг, существовавший в коде, но никогда не проявлявшийся на одной платформе проявится на новой платформе или сильно проявятся ошибки проектирования программы, но это не имеет отношения к языку и наблюдается как для C++, так и для C# в одинаковой степени.