Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Актуальные библиотеки для C++

Как студент, еще нигде не работавший, хочу знать, что актуально сейчас в с++?

Во первых, для реализации алгоритмов, достаточно ли STL?

Во вторых относительно разработки интерфейсов. Что наиболее сейчас востребовано? Windows Forms, MFC или QT?

Как у меня сложилось мнение, то Windows Forms излишне ресурсоемкое, да и CLR не радует, а MFC устаревший, сейчас обратил взгляд на QT.

Что подскажут работающие люди с опытом?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

без обид, но человека у которого спрашивают какая форма лучше, а он отвечает «красный — самый красивый цвет» я считаю идиотом.

Автор топика живет не в прошлом и спрашивает про обучение на перспективы, а ему тут вываливают исторические заслуги MFC. неадекват полный.

без каких обид? не говори ерунду, или покажи где написано что MFC уже не существует.

или иди и лечи свою голову.

Все кто наезжает на MFC — ламеры позорные, если бы вы вспомнили когда ее писали, и то что она до сих пор актуальна и не переписывалась! архитектура по тем временам лучше быть не могла, из за самой ограниченности плюсов тех времен. Да, MFC щас не вписывается в новые стандарты и требования, но вы возмите любой код GUI 95-ого — не думаю что там что-то высокоинтелектуальное...

без обид, но человека у которого спрашивают какая форма лучше, а он отвечает «красный — самый красивый цвет» я считаю идиотом.

Автор топика живет не в прошлом и спрашивает про обучение на перспективы, а ему тут вываливают исторические заслуги MFC. неадекват полный.

Может вы и правы. Время когда в них была потребность я пересидел на Delphi, а сейчас в них потребность еще меньше чем в том же Delphi (новых проектов на ATL/WTL я не видел вообще), на Delphi есть, но мало. Так что если только самообразования по old school.

Значит вы писали на прикладном уровне. Потребность есть, и весьма велика, особенно если нужен СОМ. И со временем используется не меньше. Просто для прикладных задач может быть она не так оправданна. Если писать СОМ-сервера, ActiveX-контролы, плагины для офисов и т.п., или программировать мультимедиа, распределенные системы, короче более системные вещи (а не просто формы и логику) — то тут под виндой только ATL.


Вася 2 час. назад

ATL/WTL — это вообще образец С++ библиотеки и библиотеки GUI для винды номер

Может вы и правы. Время когда в них была потребность я пересидел на Delphi, а сейчас в них потребность еще меньше чем в том же Delphi (новых проектов на ATL/WTL я не видел вообще), на Delphi есть, но мало. Так что если только самообразования по old school.

Для изучения C++ под виндой — я бы рекомендовал Именно WTL/ATL. Ознакомление с API и COM, на мой взгляд — необходимая вещь профессионального C++ разработчика. А дальше уже можно и всякими C# баловаться...

ATL/WTL — это вообще образец С++ библиотеки и библиотеки GUI для винды номер 1. ATL — это супер библиотека, очень изящна, быстра, и не сложная. Я не понимаю воплей о сложности. Что говорить тогда о бусте и других? Да, есть конечно один нюанс — чтоб быть профи на с ATL увы надо понимать СОМ и внутреннее устройство ATL. Но изучив сорцы этой либы вы поймете и научитесь многому — чего не скажешь о других либах типа куте.

Все кто наезжает на MFC — ламеры позорные, если бы вы вспомнили когда ее писали, и то что она до сих пор актуальна и не переписывалась! архитектура по тем временам лучше быть не могла, из за самой ограниченности плюсов тех времен. Да, MFC щас не вписывается в новые стандарты и требования, но вы возмите любой код GUI 95-ого — не думаю что там что-то высокоинтелектуальное...

Никакого Кюта на ВинМобайл скоро не будет, потому что разработка под ФонОС 7 будет только под.НЕТ.

Правда остается открытым вопрос будет ли вообще какой то ФонОС7 или он последует стопами Кина.


Стоимость портирования приложения на wxWidgets меньше стоимости разработки его с нуля под MacOS на их ObjectC.

Тем не менее если Вы хотите что-бы пользователи юзали Ваше приложение ГУИ надо писать с нуля. Посмотрите на серьезных пользователей того же Кьюта: Скайп и Оперу. Под каждую платформу написан нативный ГУИ, а Кьют используеться только для Линукса (и то Опера со временем все больше от него отказывается)

Но это привело к тому что MacOS реально до Windows по количеству удобного необходимого ПО явно не дотягивает.

Это Ваше мнение. Если говорить именно об удобном ПО, то мне даже так сходу сложно назвать примеры под Виндовс. То что я вижу у друзей и коллег его использующий это какой то ужасный зоопарк контролов, вырвиглазные цвета и полное отсутствие даже зачаточных представлений о юзабилити. Даже тот же Скайп, который терпимо выглядит на других платформах под виндовсом представляет собой какой то непонятный салатовый ужас. Так что не надо о грустном...

MacOS в данном случае пойдёт в качестве мультимедийного/развлекательного (без игр) центра и дизайнерского пакета (со сторонним ПО). В качестве остальной деятельности оно не особо подходит.

И как я живу и работаю без Виндовса уже столько лет... Нет, не живу, существую...


У Java и Qt — тоже несколько разная целевая группа. Java генерит исполняемый на виртуальной машине код (это не всех устраивает), в то время, как Qt генерит нативный код.

Кьютовский Гугл Ерс и Жавовский Эклипс для меня, как для конечного пользователя, одинково ненативно-паршивые. Вопросы виртуальных машин конечного пользователя вообще не сильно волнуют откровенно говоря...

Что касается Qt для мобильных устройств — почитайте здесь

И что мне там читать? Никакого Кюта на ВинМобайл скоро не будет, потому что разработка под ФонОС 7 будет только под.НЕТ. Маемо Нокия закапывает в пользу перехода на совместный с Интелом МиГо. Итого получаем выбор между Нокией с МиГо и Симбианом, хорошая многплатформеность (особенно учитывая, что 90 процентов девелопмента под мобилки сейчас — это ИОС и Андройд).

П.С. Впрочем, от Qt я сам не в восторге -, но для многоплатформенных решений она неплоха.

Еще раз: на МакОС Ваш софт на Кьюте никто не купит. Это проканает только если нет альтернативы (как в случае с Гугл Ерс) или это какой то местный софт написаный для предприятия которые сотрудникам просто придеться юзать.


> Ну, а для изучения winapi вообще фреймворков не нужно.

«лёгкий» ОО-фреймворк (какой из себя представляет WTL) — штука полезная. К тому же, бесплатная.

MFC ещё полезнее и в коммерческих проектах встречается на порядок чаще WTL.
ну, а про существующее количество готов контроллов или фичпаки майкрософта в мфц я думаю писать не стоит.

IMHO, gcc тоже полезная; -)

> к тому что MacOS реально до Windows по количеству удобного необходимого ПО явно не дотягивает

C’MON SON! количество да., но надо брать качеством. примеры в студию


anonymous 1 час назад
Это такая мантра пользователя виндовс и разработчиков на Жава. Они думают, что если покрасили в синий цвет полосу прокрутки в МакОСи, то приложение стало вдруг нативным.
На самом деле если я подвожу курсор к слову в текстбоксе и нажимаю цмд-ктрл-Д и не вижу всплывающего словаря, или в том же текстбоксе не работют стандартные Эмаксовые хоткеи, то я сразу знаю что приложение неюзабельное ненативное гавно. (привет Гугл Ерс на Кьюте и Эклипс на Жаве)

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

Стоимость портирования приложения на wxWidgets меньше стоимости разработки его с нуля под MacOS на их ObjectC. Так что лучше писать полностью под родную платформу это правильно. Но это привело к тому что MacOS реально до Windows по количеству удобного необходимого ПО явно не дотягивает. MacOS в данном случае пойдёт в качестве мультимедийного/развлекательного (без игр) центра и дизайнерского пакета (со сторонним ПО). В качестве остальной деятельности оно не особо подходит.

> Кьют весит значительно больше того же «многоплатформенного» Сановского ЖРЕ
> а мобильная вообще не существует
У Java и Qt — тоже несколько разная целевая группа. Java генерит исполняемый на виртуальной машине код (это не всех устраивает), в то время, как Qt генерит нативный код.
Что касается Qt для мобильных устройств — почитайте здесь:
qt.nokia.com/...bile-platforms

П.С. Впрочем, от Qt я сам не в восторге -, но для многоплатформенных решений она неплоха.

то получается именно Кьют, монстр весящий 200 метров

От куда такие цифры?


них разные целевые группы...NET — это виинда (включая, мобильную), а Qt — это многоплатформенность (включая мобильную)

Во первых следует отметить, что Кьют весит значительно больше того же «многоплатформенного» Сановского ЖРЕ, во вторых «многоплатформенность» десктопная в случае Кьюта означает, что приложение будет выглядеть одинаково плохо и не нативно на всех платформах, а мобильная вообще не существует.

> то получается именно Кьют, монстр весящий 200 метров и все равно сильно не дотягивающий по удобству до точкаНЕТа

У них разные целевые группы...NET — это виинда (включая, мобильную), а Qt — это многоплатформенность (включая мобильную)

> Ну, а для изучения winapi вообще фреймворков не нужно.

«лёгкий» ОО-фреймворк (какой из себя представляет WTL) — штука полезная. К тому же, бесплатная.

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

+1


wxWidgets, особенность этого фреймворка приложения на родной ОС выглядят также как и родные.
Это такая мантра пользователя виндовс и разработчиков на Жава. Они думают, что если покрасили в синий цвет полосу прокрутки в МакОСи, то приложение стало вдруг нативным.
На самом деле если я подвожу курсор к слову в текстбоксе и нажимаю цмд-ктрл-Д и не вижу всплывающего словаря, или в том же текстбоксе не работют стандартные Эмаксовые хоткеи, то я сразу знаю что приложение неюзабельное ненативное гавно. (привет Гугл Ерс на Кьюте и Эклипс на Жаве)

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


Как только необходима обработка больших объемов бинарных структурированных данных то.NET становится неактуальна, так как падение производительности достигает 3000% (точнее настолько быстрее программы на С, даже без вставок на ассемблере).

И много приложений именно с такими требованиями? Вы все время клоны Фотошопа разрабатываете? Сделать обработку таких данных в небольшом не-менеджед модуле религия не позволяет?

Для строковых данных, графических интерфейсов и баз данных (клиент) производительность примерно одинаковая.

Тость для 99 процентов случаев?


Тем не менее, код.NET выполняется на виртуальной машине — потому, помедленнее, чем нативный код будет

Он может быть помедленнее не потому что «выполняется на виртуальной машине», а потому что это значительно более высокоуровневая и безопасная среда с очень мощной стандартной библиотекой. Как только что-то подобное пытаются воспроизвести для низкоуровневых языков вроде С++, то получается именно Кьют, монстр весящий 200 метров и все равно сильно не дотягивающий по удобству до точкаНЕТа.

Ну да, Гномеры будут просто счастливы. «адекватная кросс-платформенность» даже между Линуксовыми ДЕ отсутсвует.

wxWidgets, особенность этого фреймворка приложения на родной ОС выглядят также как и родные.

Именно WTL/ATL. Ознакомление с API и COM

Здесь именно COM так как для того же ActiveX лучше взять VB/Delphi. Ну, а для изучения winapi вообще фреймворков не нужно.

> в WindowsXP SP2 идёт.NET 2.0

Не, ошибся. Даже.NET 2.0 не идёт с SP2 для XP — дополнительно ставить надо.


Ну что Вы, посмотите на календарь, в 2х последних ОС от МС точкаНЕТ сразу утсановлен. С последним сервис паком к ХР вроде тоже?

Так что эта причина стремительно становиться неактуальна.

Как только необходима обработка больших объемов бинарных структурированных данных то.NET становится неактуальна, так как падение производительности достигает 3000% (точнее настолько быстрее программы на С, даже без вставок на ассемблере). Для строковых данных, графических интерфейсов и баз данных (клиент) производительность примерно одинаковая.

> Ну что Вы, посмотите на календарь, в 2х последних ОС от МС точкаНЕТ сразу утсановлен. С последним сервис паком к ХР вроде тоже?
> Так что эта причина стремительно становиться неактуальна.

Тем не менее, код.NET выполняется на виртуальной машине — потому, помедленнее, чем нативный код будет (что, зачастую, является существенным фактором). Да и, зачастую, у конечного пользователя может не оказаться установленной версии — например, в WindowsXP SP2 идёт.NET 2.0, а чтобы пользоваться приложением, использующим более высокую версию — приходится установить её отдельно.

> на C++ под windows стоит писать на MFC

Это, если не заморачиваться вопросами платности MFC (который не входит в VC++ Express). Да и тяжеловат он, в сравнении с бесплатным WTL (при том, что добавляет не так уж много).


— Native GUI приложение под windows. Требование native может быть обусловлено разными факторами (нежелание заставлять пользователей ставить.NET X.Y, внутренняя полиси компании).
Ну что Вы, посмотите на календарь, в 2х последних ОС от МС точкаНЕТ сразу утсановлен. С последним сервис паком к ХР вроде тоже?

Так что эта причина стремительно становиться неактуальна.

Кросс-платформенное GUI-приложение. IMHO адекватная кросс-платформенность может быть только между Linux/Windows.

Ну да, Гномеры будут просто счастливы. «адекватная кросс-платформенность» даже между Линуксовыми ДЕ отсутсвует.

OS X слегка выпадает из этой когорты, там чуть другие идеи и неродное приложение видно сразу.

Я рад что мне не придеться Вам доказывать, что Кьют приложения под Маком выглядят и ведут себя как унылое гавно.

Но если надо чтобы работало на всех трех, Qt — наш выбор.

Работало _одинаково криво_ на всех трех. Получиться не нативное приложение, абсолютно не интегрированное в систему.

Для изучения C++ под виндой — я бы рекомендовал Именно WTL/ATL. Ознакомление с API и COM, на мой взгляд — необходимая вещь профессионального C++ разработчика. А дальше уже можно и всякими C# баловаться...

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

Девайсы от Sharp (шутка):)
— Native GUI приложение под windows. Требование native может быть обусловлено разными факторами (нежелание заставлять пользователей ставить.NET X.Y, внутренняя полиси компании). Почему Qt, а не MFC/WTL? Нет геморроя с unicode/ansi, Layout manager из коробки, подключаемые форматы изображений, удобные классы типа QSettings. XML DOM, сокеты, http/socks прокси, i18n из коробки. — Кросс-платформенное GUI-приложение. IMHO адекватная кросс-платформенность может быть только между Linux/Windows. OS X слегка выпадает из этой когорты, там чуть другие идеи и неродное приложение видно сразу. Но если надо чтобы работало на всех трех, Qt — наш выбор.
А идеальный юзкейс — когда заказчик ищет Qt разработчика.

wxWidgets выношу за скобки потому, что очень давно с ним не работал. Последний раз, когда я на него смотрел, где-то лет 5 назад, это был яркий представитель полочка-дизайна («а давайте здесь присобачим полочку»). Неряшливо.


В изучение разработки исключительно под девайсы нокиа — нет. В изучение Qt — да. Qt аккуратная универсальная библиотека, с единым стилем (для меня — образец С++ библиотеки). Очень легко осваивается. Кроме GUI там есть куча других компонент, all inclusive.

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


да, теперь я вижу какой вы спец в бизнесе и как ктото пишет не дальше лабораторных.
Школьник, тут под ников anonymous пишет более 9000 человек.

Я с тобой диал закончил пока ты не скажешь сколько тебе лет.

Java — Java кофе наливай
С++ сахар
С# в тюрьму
Qt кто ты?
Рубины на рельсах

Унесите отсюда голову Альфреда Гарсии!

Или же послать его подальше и писать под LINUX, как некоторые дальновидные разработчики поступают. Но мне то все равно я пишу на Java-е.


THE ONE 1 мин. назад — C# (интерфейс) +C++ (ядро системы). Самая оптимальная сборка, 90% буржуев для разработки десктоп-приложений перешли на эту связку. И сейчас моя любимая.
а что в нй оптимального?
Максимальная производительность, как в разработке, так и в работе алгоритмов.
Очень чувствуется если нужно на C# написать высокопроизводительное ПО для обработки мультимедиа данных. Все толстые класса по обработке мультимедия пишутся на С++ и вызываются из C# кода (интерфейс и управление).

Если еще использовать не только SIMD-комманды, а CUDA (сам еще не использовал, но хотел бы поработать с этим) то производительность системы может достигать до пол-терафлопса, а это большущий кластер использующий Java.

2anonymous,

школота ты на каникулах после окончания 9го класса?

Раньше был проект один JavaDelphi или Delphi2Java назывался, там очень много общего нашли, а сегодня я искал COM Automation который гдето застрял на MS JVM. А из Delphi это делать было так удобно... И зачем этот.NET вооще был нужен, как и Visual Basic. На С++ неплохо даже писалось с использованием STL и ATL.

ну что тут не понятного. не всех за мозги берут, большое количество идёт за откат.

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

Раньше был проект один JavaDelphi или Delphi2Java назывался, там очень много общего нашли, а сегодня я искал COM Automation который гдето застрял на MS JVM. А из Delphi это делать было так удобно... И зачем этот.NET вооще был нужен, как и Visual Basic. На С++ неплохо даже писалось с использованием STL и ATL.

— C# (интерфейс) +C++ (ядро системы). Самая оптимальная сборка, 90% буржуев для разработки десктоп-приложений перешли на эту связку. И сейчас моя любимая.

а что в нй оптимального?

на C++ под windows стоит писать на MFC.

Стоит писать на: — C# (интерфейс) +C++ (ядро системы). Самая оптимальная сборка, 90% буржуев для разработки десктоп-приложений перешли на эту связку. И сейчас моя любимая. — C++ + wxWidgets/QT, если потребуется портировать по на другую систему или проблемы с установкой фреймворка.

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

Процент не скажу, но он сейчас очень популярен и его используют многие известные компании: facebook, yahoo, hulu, last.fm, linkedin, twitter, etc, wiki.apache.org/...adoop/PoweredBy

Но в некоторых местах все еще видны дырки, например нету аналога Hadoop.

Apache Hadoop является свободным Java фреймворком, поддерживающим выполнение распределённых приложений, работающих на больших кластерах, построенных на обычном оборудовании.

ru.wikipedia.org/wiki/Hadoop

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

можно кстати и такое, можно и html диалоги, дело не в этом.
на C++ под windows стоит писать на MFC.
конечно это в случае если вам надо написать быстро с оптимизированным кодом.

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

.Net = Delphi + Java на синтаксисе С (так как C# основной язык фреймворка). И пока единственный недостаток.NET де-факто отсутствие нормальной кросплатформенности (Mono отстаёт на пару версий).

Еще недостаток — экосистема пока что отстает от джава в некоторых областях, частично это покрывается клонами джавовских проэктов..., хотя их функциональность часто хуже чем у оригиналов. Но в некоторых местах все еще видны дырки, например нету аналога Hadoop.


на базе шаблонов диалогов можно создавать и sdi и mdi окна, а что вам ещё надо?
Без танцев с бубном менять дизайн на лету, так как заказчик сейчас пошёл хитрый и от декстопного приложения может потребовать редесинг дизайна, примерно как веб-сайта.

Идеально, чтобы еще в виде конфигов как тот же XAML ru.wikipedia.org/wiki/XAML

а в MFC с 98-во года правились только баги без нового функционала.

отож, идеальная библиотека; -), в которую время от времени вносят небольшие изменения., а какие баги MFC вы знаете?

Нашёл возможность визуального редактирования только диалоговых окон.

на базе шаблонов диалогов можно создавать и sdi и mdi окна, а что вам ещё надо?

.NET создали по образу и подобию Java, пытаясь тем самым замазать ошибку VB.

.Net = Delphi + Java на синтаксисе С (так как C# основной язык фреймворка). И пока единственный недостаток.NET де-факто отсутствие нормальной кросплатформенности (Mono отстаёт на пару версий).

Java в общем-то тоже по синтаксическому удобству недалеко от С++ ушёл.


ещё раз повторяю, в большинстве.net проектов используются вызовы WINAPI.

Они не в большинстве, они во всех проектах. Так как создание нового процесса уже вызов winapi, что по сути является вызовами функций из системных библиотек.

на MFC можно визуально редактировать окна.

Нашёл возможность визуального редактирования только диалоговых окон. Отчего почти во всех своих проектах на С++ пересаживаю заказчиков на wxWidgets. Кроме того wxWidgets — динамически развивающийся фреймворк (даже если забыть про многоплатформенность), а в MFC с 98-во года правились только баги без нового функционала.

.NET создали по образу и подобию Java, пытаясь тем самым замазать ошибку VB. Но идеи VB все более переходили на новую технологию чем Java-вские. Слишком уж много было некачественного кода бинарного.

т, а в C++MFC по стоимости интерфейс равен разработке ядра системы.

это ошибочное мнение. на MFC можно визуально редактировать окна.
всё остальное вышесказанное не имеет ценности.
т.е. вы рекомендуете топикстартеру изучать программирование под виндовз с использованием визульного программирования?

ещё раз повторяю, в большинстве.net проектов используются вызовы WINAPI.


THE ONE 12 мин. назад
почему?, а ATL или WINAPI?
архитектура самой винты я полагаю тоже «бред буйнопомешанного»?
wxWidgets/QT позволяет проектировать интерфейс мышкой и не заморачиватся на визуальном представлении данных. А MFC/ATL/WinApi — нет. Так что эти три технологии отличает от нормальных очень страшный и неудобный интерфейс написанного на них ПО, так как в данном случае интерфейсы разрабатывает программист, а не аналитик или дизайнер.
Конечно для больших проектов уровня Office/PhotoShop это не заметно, так как там сперва идёт долгое проектирование, а потом уже кодинг по сгенерированным шаблонам классов и нарисованным в графическом редакторе формам.

Почему же тот же Delphi, не смотря на все его недостатки держится на плаву. На нем без особых сложностей можно написать нативное ПО (без фреймворков) с удобным и качественным интерфейсом, так как проектирование интерфейса в том же C#/Delphi почти ничего не стоит, а в C++MFC по стоимости интерфейс равен разработке ядра системы.


это бизнеса ради.

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

Кстати, Вы считаете, что Ваш любимый Майкрософт ошибочно продвигает платформу точкаНЕТ? Столько денег угрохали, а разрабатывать под нее медленее и программы «не пурформансные»!

это бизнеса ради., а у вас что другое мнение? в школе по другому рассказывали?


это пацаны без опыта задвигают.

А можно поинтересоваться в каком году вы школу закончили? Просто Ваш стиль изложения мыслей и грамматика доставляют...

у меня по времени будет приблизительно одинаково, знаю и то и др., но на mfc быстрее; -) и перформанснее чен на других двух

Ну это Вы один такой уникум. А вот рынок доказывает что 99.99 процентов программистов быстрее напишут с применением точкаНЕТ. Кстати, Вы считаете, что Ваш любимый Майкрософт ошибочно продвигает платформу точкаНЕТ? Столько денег угрохали, а разрабатывать под нее медленее и программы «не пурформансные»!


почему?, а ATL или WINAPI?
архитектура самой винты я полагаю тоже «бред буйнопомешанного»?

Попробуйте написать какую то простенькую графическую тулзу с применением указанных Вами технологий, а потом повторите эксперимент на точкаНЕТе и сравните количество затраченного времени.

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

у меня по времени будет приблизительно одинаково, знаю и то и др., но на mfc быстрее; -) и перформанснее чен на других двух


почему?, а ATL или WINAPI?
архитектура самой винты я полагаю тоже «бред буйнопомешанного»?

Попробуйте написать какую то простенькую графическую тулзу с применением указанных Вами технологий, а потом повторите эксперимент на точкаНЕТе и сравните количество затраченного времени.


Что подразумевается под тонущим кораблем? с++? просто как я смотрю, то большинство вакансий идет под с++ или Java.
Если вы не видите огромного количества вакансий точкаНЕТ то Вы куда то не туда смотрите:)

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

намерянный холивар детектед.

... MFC — бред буйнопомешанного...

почему?, а ATL или WINAPI?
архитектура самой винты я полагаю тоже «бред буйнопомешанного»?

ЗЫ. со стороны похож на линуксоида кричащего на винду.


Я бы не сказал, что Qt тонущий.

Я назвал тонущим С++ как язык разработки десктоп-приложений, а не Кьют. Но у него за пределами смартфонов Нокия и КДЕ тоже будущее туманно...

Особенно с учетом распространения ее на девайсах Nokia и переходом к LGPL.

Глядя на динамику роста ИОС и Андройда вы правда уверены, что вкладывать свое время в изучение разработки под девайсы нокия — это мудрое решение на 5−10 лет вперед?


Waylander 1 час назад

Во вторых относительно разработки интерфейсов. Что наиболее сейчас востребовано? Windows Forms, MFC или QT?

Win Forms — не С++, а С++/CLI или.NET
MFC — бред буйнопомешанного
QT — вещь очень класная, но жирная (+10-+18 Мб к приложению).
Оптимально для GUI — wxWidgets (+800 Кб при статической линковке)
www.wxwidgets.org
С визуальными редакторами форм
wxformbuilder.org
или платным и очень навороченным

www.dialogblocks.com

Что подразумевается под тонущим кораблем? с++? просто как я смотрю, то большинство вакансий идет под с++ или Java.


Работающие на С++ люди с опытом подсказывают, что на Qt вполне себе пишутся десктопные приложения.

Кто ж спорит. Но если у Вас уже нет кучу опыта, то никакого смысла запрыгивать на этот тонущий корабль нет.


Что подскажут работающие люди с опытом?

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

Підписатись на коментарі