О Жизни и про Жизнь

Здравствуйте. Хочется продолжить изучение С++. Базовые знания, понятие ООП, практика написания несложных программ под DOS - есть. Как я понимаю, следующий шаг создание оконных приложений под Windows. Вроде обычно это делали на MFC, но как говорят некоторые, она умерла. Вот абсолютно случайно, попала в руки книга по Qt. От чего плясать?

У меня была проблема с трудоустройством по специальности, которая уходила корнями в прошлое. Спасибо авторам ресурса за поддержку. Устроился Web мастером, отработал уже больше месяца.

Вообще, конечно, лучше такие вопросы на форуме по C++ размещать.

>Как я понимаю, следующий шаг создание оконных приложений под Windows. Вроде обычно это
>делали на MFC, но как говорят некоторые, она умерла. Вот абсолютно случайно, попала в руки
>книга по Qt. От чего плясать?
Т.е. вы хотите создавать оконные приложения для Windows или оконные приложения и для Windows, и для UNIX? Если второе - дальше можно не читать, Qt - это хороший выбор.

Дело в том, что создание Windows-приложений на чем-то отличном от продукции Microsoft, без хорошей базы Windows API дело довольно рискованное - выходит новая версия Windows, библиотеки отстают, не работают, программы выглядят черт знает как, а заказчику нужны программы уже сейчас, а не когда библиотеки подлатают. Понятно, что библиотеки (Qt, MFC, .NET) помещают в код приложения массу всего, что там никогда использоваться не будет. Понятно, что если вы не знаете Windows API - ваши приложения будут делать только то, что умеет библиотека и с той скоростью, которая эта библиотека позволяет. Кроме того, не все эти библиотеки есть на машинах клиентов, это только программы на Windows API можно запускать и они будут работать везде (по крайней мере, этого можно добиться без обновления тысячи машин локальной сети, а лишь обновлением программы).

>Вроде обычно это делали на MFC, но как говорят некоторые, она умерла.
По-моему живет и здравствует... просто MFC не нужно воспринимать, как независимую технологию создания оконных приложений - это FrameWork. Т.е. переводя на Web-язык - это что-то вроде Joomla, отталкиваясь от которой можно побыстрее делать программы (если вы знаете как пользоваться этим FrameWork и вообще технологией). Понятно, что если вы беретесь за MFC без знания Windows API, а за Joomla без знания HTML и PHP получаются малоконкурентные продукты, которые не позволяют ни заказчику, ни разработчику двинуться в сторону.

Как было дело? Когда появился С-ориентированный Windows API, разработчики бросились создавать программы - была золотая лихорадка, как сейчас (ну или некоторое время назад) в Web. Создавать в том числе и на новом C++ (Windows API был на C), т.е. писались FrameWork-и, библиотеки, которые в общем делали одно и тоже, упаковывали C-вызовы в C++-классы. В Microsoft решили создать универсальную библиотеку MFC, которая бы позволила миновать этот утомительный этап и сразу позволить отталкиваться от классов. Я описываю упрощенно, так как до MFC был Com (и сейчас тоже есть и даже развивается - теперь это ATL), от которого все на стену лезли и нужно было что-то попроще. Кому-то понравилось, кому-то нет. MFC ругают за размер, да это было проблемой в начале 2000-х, когда были слабые каналы и важно было уложить супер-программу в 2Мб. Если вы посмотрите на текущие скорости и объемы современных программ, то согласитесь, что сейчас такой проблемы не стоит. Однако, факт остается фактом, MFC он для тех, кто знает как программировать, с использованием Windows API.

Проблема в другом - MFC вас закидывает на определенную точку, от которой вам нужно отталкиваться, только зачастую вам нужно в другую сторону, приходится слазить и забираться на другую точку (т.е. проделывать лишнюю работу, если без вреда для результата, то и без пользы). MFC создавалось во времена, когда нужно было много редакторов и самых обычных программ, сейчас их столько, что в новых нет нужды. В этом плане MFC потерял популярность — программы другие нужны и не в таком количестве, как раньше. Сейчас нужна хорошая графика, сетевое взаимодействие — это все можно делать без MFC и в любом случае требует знания Windows API.

В этом плане свой собственный FrameWork - гораздо лучше, он не позволит вам решать многие задачи, которые позволяет MFC, но зато вы любую нужную вам задачу реализуете моментально. Нужно чтобы приложения стартовало с тремя или большим количеством независимых окон (Builder, Mathematica, Photoshop)? Пожалуйста. Нужен элемент управления в виде пяти круглых кнопок расположенных по эллипсу? Ради бога. В общем, вы контролируете работу программы на гораздо более глубоком уровне (в том числе архитектурном, MFC, положим, вам мелочь позволит изменять, но архитектуру пожалуй, что нет).

Понятно, что модель, представление в MFC можно куда угодно применять, но ничто не мешает вам сделать тоже самое без MFC. Вывод такой, если вы знаете Windows API, вы можете построить FrameWork вроде MFC сами, ну если вы не очень сильный программист, в этом случае вас возможно заинтересует MFC, которая действительно написана хорошо и использует недоступные вам вызовы. Однако, обычно пользуются своим — маленьким и в котором разработчик знает каждый винтик. А уж при разработке игр, приложений DirectX и вопросов нет, там нужно идти в обход медленной обработки событий Windows, поэтому вся Windows-оконтовка пишется на Windows API (а элементы управления и интерфейс вы реализуете сами).

Теперь к вопросу, что делать (раз уж я практически составил бесплатный консультационный ответ :)? Если вас интересует разработка программ под Windows, а также надежный фундамент, который не устареет и к 2020 году, ну разве только немного и знания можно будет быстро восстанавливать, нужно научиться разрабатывать Windows-программы с нуля на Windows API, построить свой собственный FrameWork (пусть плохой и с течами). А потом делайте что хотите, хотите на Windows API пишите, хотите на MFC, хотите на Qt. Вы будете понимать, что стоит за каждым пикселом на мониторе, сколько это стоит и как это реализовать самостоятельно, если разработчики библиотеки сгинули.

PS У меня была мысль в рамках C++-проекта создать online-учебник построения такого Windows API FrameWork (благо наработок полно – только оформляй в виде текста), но понятно что времени на все проекты выделить невозможно, а этот для студии не самый приоритетный. К сожалению, самостоятельно изучать Windows API сложно – книг мало или практически нет. Сам локти кусаю, что в свое время не приобрел некоторые (того же Петцольда), а на те, что есть нарадоваться не могу. Когда в отрасли золотая лихорадка – часто создаются очень мощные книги.

Благодарю за столь информативный и развернутый ответ.

Целое эссе)

Кстати, вот вы говорите:
> программы другие нужны и не в таком количестве, как раньше

А в самом деле, какие сейчас могут быть задачи у программистов? Ведь программ уже написано — чёртова уйма. Надо только найти нужную и грамотно применить. Мелкие утилитки, конечно, не в счёт, но для более-менее серьёзных задач уже давно всё есть. Зачем писать программу-считалку, если есть Маткад, зачем писать программу-чертилку, если есть Компас? Да, они стоят денег, но и работа программиста небесплатна.

>А в самом деле, какие сейчас могут быть задачи у программистов?

Полно. Я ж Вам на softtime.ru сказал - учите Lisp :)
То, о чем Вы говорите относится к общей практике. Типа "пипл всё схаватает". А мы, к примеру, работаем над экслюзивными вещами. И мы не одни такие. Те, которые не ставят Битрикс или Джумлу на сайт тот же, и потом чешут башку, как туда всобачить блок, который можно всобачить, только всё переписав. Я уж молчу о спец.ПО. Угу. Возьмём что-то дядей Васей из деревни Васюська писаное, и поставим его на подлодку. Чтоб Булава у нас не просто упала, а улетела прямо в резиденцию Президента. (Дмитрий Анатольевич, не пугайтесь :) Я про Президента США. Тоже шучу, конечно же.)

>но для более-менее серьёзных задач уже давно всё есть
Для менее - да, для более - нет.

Ну, с «серьёзными дядьками» всё понятно, они и настольный калькулятор просто так не пропустят)

Хм. Написал было длинный пост с тем смыслом, что «всё равно не понимаю», но рассудил, что конкретных примеров всё равно никто мне не скажет, так что вопрос так и останется для меня открытым)

Задачи положим есть, скажем так денег с населения уже не собрать (нужны другие каналы монетизации) и не отвадить от ПО, на обучение, закупку, сопровождение которого было потрачено огромное количество денег и времени. А вообще заказывают и довольно много, у нас, например, вся "тяжелая артиллерия" занята и её работа расписана на годы вперед, поэтому зачастую отказываемся от предложений, которые поступают в студию.

Вопрос даже не в том, что нет задач, а в том, что C++ (с GUI) это тяжелая работа, требующая длительного времени, высочайшей квалификации, большого количества разработчиков и которая скорее всего не будет оплачена достойно. Т.е. написать хорошую программу и выйти с ней на рынок почти не реально - затраты не окупятся... ну разве только что вы игру пишите, причем по технологии "блокбастер", т.е. выделяем миллионный бюджет, половина которого сразу идет на рекламу, пишем в срок и играбельно, поднимаем во всем мире денег в несколько раз превосходящих первоначальные затраты (ну если, конечно, вы нигде не ошиблись и знаете как эта схема работает). В индустрии программирования крутятся большие деньги - одним они помогают, другим мешают.

Тот же Photoshop, кстати, не такая уж неподъемная задача (особенно, если ориентироваться только на Windows, что правда в области графики опасно). Тем более, когда весь интерфейс продуман другими до мелочей :))) Другое дело, что вашу разработку, даже в два раза более дешевую, даже бесплатную, скорее всего не заметят, а времязатраты там приличные.

Но вообще программы нужны и довольно много, персональному компьютеру не так много лет, мобильным устройствам еще меньше - не все ПО есть. Зачастую в некоторых областях персоналки не используются, так как нет ПО, а разработка его не задалась или не окупается, или никто пока не догадался окучить нишу, или банально у разработчиков на эту область нет времени. Так как большой проект может отнимать почти все силы.

PS Те же дебагеры для JS в браузерах появились спустя 10 лет после того, как они были нужны. Так это программистское ПО, которое должно появляться первым. В общем говорить о том, что ПО больше не нужно, наверное не правильно, скажем так, получить денег за разработку стало сложнее (это раньше, можно было получить деньги за что угодно), так как есть отлаженные и прекрасно работающие образцы, которые переплюнуть с первого раза довольно трудно, и с которыми вас обязательно будут сравнивать.

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

Лучше для чего? Имеете в виду в качестве первого языка программирования? Да, это может оказаться не плохой идеей. Я считаю, что любой программист должен освоить C++, так как это хребет современной IT-индустрии, вообще являюсь страстным поклонником этого языка, но в качестве первого языка, пожалуй, никому его не посоветую... Это язык профессионалов, причем с корнями как в системном программировании, так и в абстрактно-архитектурной области. Он большой и сложный, его часто за это ругают и нужно сказать, повод для этого есть. Лучше его вторым-третьим по счету изучать...

А я считаю, что лучше - первым си два плюса изучать... После него - "море по колено".

Что ж ты сам с Pascal начинал? :)))