Как разобраться со всем разнообразием библиотек, framework'ов и т.д. для C++ на Windows

#windows #winapi #net #qt #cpp

Есть знания C++. Допустим, надо написать программу. Можно ее написать разными способами.
Можно с помощью Qt, можно через Win32, можно через MFC и т.д. Зависит от того, что
будет делать программа. Но для этого надо знать какие есть способы и что они могут.

Какие есть самые популярные способы? Я в этом всем запутался. 
.NET для C++. Как конкретно этот способ называется? C++/CLI? 
Эти способы обычно совмещаются? Допустим есть библиотека, которая решают что-то одно,
например, графические библиотеки GTK/FLTK/wxWidgets. А если этого не достаточно, то
чем то дополняют или используют тот способ, в котором есть все что нужно?
Можете описать задачи, которые выполняют эти способы(хотя бы сказать про самые популярные
типа Qt, Win32)? В описании этих способов все как-то расплывчато написано. Для меня
пока это не очень понятно.
Framework отличается от библиотеки тем, что он имеет более широкую функциональность? 
Мне Qt нравится тем, что там много чего есть, хотя я им не разу пользовался. Но я
не знаю востребован ли Qt на рынке труда. Не могу пока определиться, что лучше учить.
Qt, Win32 или еще что-то.
    

Ответы

Ответ 1

Что подразумевается под способами? Вы уже выбрали язык. Можете разве что выбрать
ту среду, в которой будете работать, и компилятор, которым собирать, а еще библиотеки,
с помощью которых уменьшите объем работы.
Да, C++/CLI.
Еще раз. Это не способы. Вы назвали библиотеки. Действительно, можно писать на голом
С++, но это очень трудоемко. И программы будут консольные. Сейчас это уже для большинства
задач неприменимо. Получается, что придется все равно использовать какие-то вызовы
для конкретных платформ - Windows, Linux. Уже получается какая-то привязка к определенной
ОСи и ее интерфейсам. Вот смотрите. В Windows существует минимум три интерфейса, с
помощью которых можно что-либо сделать:


Native API — самые низкоуровневые вызовы. Идут через библиотеку NTDLL.DLL в само ядро.
Win32 API — обертка вокруг Native API для обеспечения работоспособности классических
Windows-программ. Обеспечивает работу граф. интерфейса, сеть и пр. Работа Win32API
обеспечивается подключением кучи библиотек, но основные — это KERNEL32.DLL, USER32DLL
и GDI32.DLL
MFC — библиотека, разработанная M$ для облегчения участи программистов, т.к. писать
на голом WinAPI весьма грустно. Очень много вызовов, Win32 API не объектноориентирован
в категориях С++ и пр.

Читайте описание. Задачи разные. Native API разрабатывался для обеспечения работы
самой операционной системы. Поэтому с его помощью можно творить такие вещи, которые
с помощью других интерфейсов нереально сделать. Правда приходится расплачиваться двумя
моментами: недокументированностью и сложностью использования. Никто не гарантирует,
что в следующей версии ОС этот интерфейс кардинально не изменят. WinAPI — это сложившийся
интерфейс для написания графических приложений под среду Windows. Qt и MFC — это еще
более высокоуровневые библиотеки, в которых есть множество модулей, начиная от работы
с графическим интерфейсом (причем это проще, чем работать напрямую через WinAPI), кончая
работой с конкретными типами файлов (аудио-видео) и сетью.
Понятно, что MFC под линукс нет. И если вы хотите кроссплатформенное приложение,
то нужно использовать библиотеки, которые более широко распространены. Тот же Qt. Задача
какая? Просто писать программу, не отвлекаясь на специфику каждой из платформ. Да и
Qt сам по себе более мощен, чем MFC, но это на мой взгляд. Никто не мешает взять, да
и самому произвести сравнительный анализ.
Framework по отношению к .net подразумевает, что это не просто библиотека, а среда.
Среда выполнения программ. И, в принципе, существуют совместимые с .net среды, вроде
проекта mono. А библиотека - ну, она одна. Или их несколько. Они реализуют какой-то
функционал. Но он не такой всеобъемлющий как в framework'е, который предоставляет функции
практически на все случаи жизни. И есть более мелкие отличия — как-то, что фреймворк
имеет свой формат исполняемых файлов, свой загрузчик таких файлов и пр.


Хорошая блок-схема, разъясняющая взаимоотношения между разными интерфейсами: