Выбор между C++ и C#

Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации

… или перехода на решения с минимумом синхронизации. На десктопе это, правда, в меньшей степени критично, на мой вкус, но тут вообще все очень занятно даже с банальной точки зрения «а зачем нам столько производительности».

И? с 2009 года морда Autocad перепилена на WPF. MS нанимает спецов по Linux — пилят свой дистр?
Можете ради интереса погуглить Autocad + WPF.
Интерфейс AutoCad 2009 построен на WPF

Спору нет. Просто у них скорее всего ядро и морды для каждой платформы — под Win — скорее всего перепиливают на WPF+XAML. Ядро хоть на бэйсике можно написать, один фиг все будет слито на видеокарту для рассчета.

Он прекрасно работает даже при использовании .NET 2.0 в качестве целевого фреймворка. Я не вижу ни одной причины не использовать его уже сейчас и начал миграцию всех проектов ещё пару месяцев назад.

Хороший комментарий, отражающий давольно полно текущую ситуацию.
Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.

Тренд по переводу проектов с шарпов на плюсы может возникнуть вследствие тренда бездумного выбора языка под проект. Сталкивался с ситуациями когда выбор падал на С++ просто «патамушта не люблю сишарп» или «не люблю языки с gc» или «проприетарщина отстой».

Мне кажется портирование с C# на С++ может стать трендом будущих разработок.

Ох уж эти сказочки! Ох уж эти сказочники!

Вы как будто с другой планеты. Вряд ли заказчики будут платить за такое, дешевле докупить оперативки или уйти в облака, чем переписывать проект с одного языка на другой. Причем необходимость такая может понадобится только в реал-тайм системах требующих молниеносный отклик, но во первых такие системы скорей всего уже написаны на языке под конкретное железо, а если нет то их на столько малый объем, что назвать это портирование, с С# на С++, тредом язык не повернется сказать.

PS. Я все же допускаю, что вы из будущего. В котором к власти во всем мире пришел Тиран с фетишизмом к С++. Был издан закон об святой инквизиции неугодных языков.

в STL: wstring, u16string, u32string — все есть, все прекрасно.

В Qt Qstring поддерживает из коробки. Что вам еще надо?

Если итератор пустой (сиречь ссылается на пустую коллекцию) то в C++ он равен end и проблем никаких. Получить итератор и не начать проход по коллекции — нарушение принципа объявление переменной там где это надо. но не раньше.

Поясню чуть шире: допустим мне по какой-то причине не подходит foreach и я вынужден использовать for,
Пишем такой код:
for (var iterator = list.GetEnumerator(); iterator.HasNext(); iterator.MoveNext()){
Обработка
}
На основе опыта, основанного на доступе по индексу я ожидаю, что если я попал в тело цикла, то для начало работы с элементом мне больше телодвижений делать не надо нарушается. Причины такой логической нестыковки не понятны.

>> А, например, OData? Тот же LINQ, но поверх HTTP.
не знал, можно по-подробнее?

>>И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж
В патерне MVVM Visual Model, как правило, наиболее сложный класс, где зачастую функционал легко разбивается на приватные методы, а вот развал их на классы может привести лишь к неоправданной усложнению.

>>.h-файл
Итого я сказал, что проблемы с оными решаются средствами IDE, вы сказали, что проблемы без оных решается средствами IDE. Концептуально баш на баш.
>> Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д.
Я программирую и на том и на том. Что до итераторов в C++, то я не вижу там зоопарка, begin\end и const их вариации логично и понятно и использование. Что до зоопарка, то не вижу в этом проблем ( www.cplusplus.com/reference/iterator ) все особенности диктуются особенностями коллекции. Знаю и понимаю коллекцию => знаю и понимаю работу итераторов без лишнего напряга памяти.

>> Лямбды с Dangling Reference'ами прэлэстны, право слово.
Если ссылка повиснет, то в 90% случаев вы получите сегфолт при попытке вызова. А вот если вы в C# периодически добавляете лямбды, в качестве обработчика сигнала, то вы получаете тихую утечку памяти. Но и то и то на самом деле в рамках языка не являются проблемой, т.к. это ключевые особенности языка, которые должен отслеживать программист.

>> Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью
Честно говоря async\await не пробывал и не по своей вине, но судя по этой ( habrahabr.ru/post/139734 ) статье разница в опыте с С++ ровно ноль:
Код вызова:

Task task = new WebClient().DownloadStringTaskAsync(«microsoft.com»);
task.Wait(); // Здесь мы ждем завершения задачи, что блокирует поток
TextBox.Text = task.Result;

Аналог в C++, например с Qt
auto task = QtConcurrent:run([&]()={WebClient().DownloadStringTaskAsync(«microsoft.com»)})
task.wait();
TextBox.Text = task.result();

На STL будет тоже самое, разве что вы вызовете поток не из пула потоков.
Т.к. в C# потоки это обертка над потоками системы, то я не вижу принципиальных различий между потоками в C# и С++