xenotron
Всегда есть вещи низкого уровня и очень высокого уровня и постепенный переход между ними. В windows, если мы говорим о графическом интерфейсе, то самым низким уровнем является WinAPI, который представляет собой процедурный интерфейс C (расположенный в основном в пользовательских библиотеках и библиотеках gdi), а интерфейс действительно хорошей высокоуровневой реализации GUI framework обычно объектно-ориентирован и обычно не имеет ничего общего с чистым графическим интерфейсом C WinAPI windows.
Фреймворк высокого уровня (например, Qt, java swing, Delphi, .Net gui framework) может показаться сложным в использовании сначала, если вы привыкли использовать winapi или MFC, но после их изучения (и шаблона MVC, который они используют) эти фреймворки более высокого уровня намного лучше, и с ними намного проще писать более приятный / повторно используемый код. Не говоря уже о том, что большинство хороших высокоуровневых библиотек предоставляют инструменты для визуального редактирования окон (гораздо лучше, чем редактор ресурсов диалогового окна winapi, используемый в winapi и mfc). API высокого уровня обычно полностью скрывают от вас API низкого уровня (и простой / обычный код gui не содержит уродливых вещей, таких как подключение к Winapi HWNDS / диалоговым элементам управления с объектами MFC).
Если вы сосредоточитесь на хорошем дизайне кода, то узнаете, как работает высокоуровневая объектно-ориентированная библиотека gui. Если вы заинтересованы в том, что происходит под капотом, то изучите также некоторые низкоуровневые winapi, это определенно делает вас лучшим программистом, и вы понимаете еще более высокоуровневые графические библиотеки, особенно если вы узнаете, как реализовать простой объектно-ориентированный графический фреймворк поверх winapi. На мой взгляд, борьба с книгой Чарлста Петцольда-не пустая трата времени.
MFC: забудьте об этом и изучайте его только в том случае, если это необходимо. Кстати MFC это очень большая библиотека которая занимается не только графическим интерфейсом: http://msdn.microsoft.com/en-us/library/ws8s10w4.aspx[^]
MFC содержит несколько полезных классов высокого уровня (например, для работы в сети, ...), но их использование затрудняет перенос вашей программы на другие платформы. Если мы говорим о GUI-части MFC: она гораздо ближе к сырому winapi, чем к высокоуровневой объектно-ориентированной хорошей структуре. Фактически, MFC довольно устарел, и MS поддерживает его из-за огромного кода наследия, но он не имеет большого отношения к современной среде графического интерфейса пользователя, и большинство его методов класса имеют то же имя, что и функции winapi, и обычно они делают то же самое. Большинство механизмов MFC построены на необработанных механизмах winapi, и MFC не пытается скрыть это (на мой взгляд, это иногда ужасно). MFC только наполовину (а может быть, треть) объектно-ориентирован, а остальное в основном является прямым Winapi. Если вы все еще хотите изучить MFC (или если вам нужно изучить MFC, потому что вам нужно поддерживать некоторые проекты в MFC), то изучение книги Чарльза Петцольда является обязательным, вы должны знать winapi, чтобы работать с MFC, потому что MFC gui в основном представляет собой набор классов, которые имеют те же методы, что и часть графического интерфейса winapi. период. Если вас устраивает посредственное знание MFC, вы можете сделать это, не изучая winapi, просто скопировав вставленные примеры из сети, но в случае некоторых сложных проблем вам часто понадобится помощь других.
Если вы хотите попробовать некоторые хорошие графические фреймворки, то найдите пример кода графического интерфейса, написанного в вышеупомянутых графических фреймворках, и сравните их с примерами mfc. Проверьте уровень "объектно-ориентированности" и связь с winapi или любыми другими низкоуровневыми API этих фреймворков и MFC. Вы увидите разницу, особенно если у вас есть опыт winapi.
Открытым исходным кодом и кроссплатформенным родным братом MFC является wxWidgets, для меня решения/механизмы wxWidget очень похожи на решения / механизмы MFC.
Правка: забыл упомянуть некоторые важные вещи:
Qt довольно хорош, единственное, что мне в нем не нравится,-это сверхпрочный механизм сигнального слота и его генератор кода перед компиляцией. Но сам либерал-это вполне нормально. В Qt тоже есть много неграфических вспомогательные классы (например, контакты, в формате XML, ...)
Еще одна очень хорошая альтернатива-C++ Builder. Его графический редактор похож на графический редактор Delphi или .Nets gui builder, который, на мой взгляд, является лучшим. C++ Builder имеет тот недостаток, что вы должны придерживаться его компилятора C++, но если это нормально, то этот gui builder, вероятно, является лучшим инструментом RAD для редактирования графического интерфейса C++. Если вам интересно, каково это-разрабатывать GUI-интенсивное приложение с лучшими инструментами разработки gui, то обязательно попробуйте .Net, Delphi (pascal) или C++ Builder (который имеет точно такую же IDE, как Delphi).