MFC все еще используется для новой разработки (с каким-либо материальным объемом)?

MFC все еще используется для некоторых новых разработок, а также для развития технического обслуживания (в том числе внутри Microsoft).

Хотя это может быть на минутку медленнее, чем использование Win32 API напрямую, потеря производительности на самом деле незначительна - редко достигает целого процента. При использовании .NET потеря производительности значительно больше (в моем тестировании редко бывает меньше 10%, причем типично 20-30%, и еще выше для тяжелых вычислений. Например, у меня есть программа это делает вычисления Eigenvector / Eigenvalue на довольно больших массивах. Моя оригинальная версия с использованием C ++ и MFC запускает один тестовый случай в всего за минуту на нашей стандартной тестовой машине. Некоторые из моих коллег решили, что было бы здорово - реализовать его в C #. Их версия занимает почти три минуты на одной и той же машине (четырехъядерный процессор, 16 гигабайт оперативной памяти, так что нет, не «устаревшее» оборудование). Я признаю, что я не слишком внимательно смотрел на их код , поэтому может быть его можно улучшить, но они достойные кодеры, поэтому улучшение 3: 1 кажется мне маловероятным.

С MFC также легко обойти среду и использовать Win32 API напрямую, когда / если вы хотите. С .NET вы можете использовать P / Invoke для этого, но это довольно болезненно для сравнения.

Выпуск MFC Feature Pack (один или два года назад, iirc) стал крупнейшим расширением MFC примерно за 10 лет, и это дало совершенно новый импульс развитию MFC. Я полагаю, что многие компании решили сохранить свои унаследованные приложения, продвигать их вперед и удалять на их основе новые приложения.

Для меня (как человека, которому приходится поддерживать большое приложение MFC), большая проблема заключается в уменьшении разработки и поддержки (Microsoft и сторонних) компонентов, а не самого MFC. Например, портировать на 64-битную версию непросто, если в приложении собрано много старых и неподдерживаемых чистых 32-битных компонентов Active-X.

MFC обновлялся с каждым выпуском Visual Studio. Это просто не главное в заголовке.

Что касается новых разработок, то да. Он по-прежнему используется и будет использоваться (хотя я, как и вы, предпочитаю этого не делать). Многие организации приняли технологическое решение много лет назад, и у них нет причин для этого.

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

Это зависит от того, что называется, это отдельные вопросы.

.AsParallel () Параллелизирует перечисление , а не делегирование задач.

Parallel.ForEach Распараллелил цикл , назначив задачи рабочим потокам для каждого элемента.

Таким образом, если исходное перечисление не становится параллельным (например, reader.Match (file) дорого), они равны. К вашему последнему вопросу, да , оба также верны.

Кроме того, есть еще одна конструкция, которую вы можете посмотреть, что сокращает его немного, по-прежнему получая максимальное преимущество PLINQ:

GetFileList().Where(file => reader.Match(file)).ForAll(f => list.Add(f));

Я буду обрабатывать событие PropertyChanged вместо этого. Событие PropertyChanged не отображается в Visual Studio intellisense, но вы можете его уловить:)

 GridViewColumn column = ...
 ((System.ComponentModel.INotifyPropertyChanged)column).PropertyChanged += (sender, e) =>
 {
     if (e.PropertyName == "ActualWidth")
     {
         //do something here...
     }
 };

Я сделал проект в прошлом году на основе MFC. Я не уверен, почему был выбран MFC, но он был адекватен для создания виртуального 3D графического пользовательского интерфейса - системы безопасности управления зданием - с частотой обновления 10 кадров в секунду, эффективно выполняемой на компьютерах на базе win32, начиная с середины 1990-х годов. Исполняемый файл (который требует только ядра win32 системных DLL) меньше 400K - нелегкое достижение с современными инструментами.

Воздержание от управляемого кода дает преимущества (возможно, вы пишете пользовательский интерфейс драйвера или используете COM).

Это и есть тонн кода MFC. Возможно, вы работаете в компании X и вам нужно использовать одну из миллионов DLL, которые они писали за последние десять лет.