Выбор технологии
Всем привет!
У меня такой вопрос
Вот я сейчас работаю в компании, которая занимается разработкой ПО на С++
Начал разработку проекта
Про технологию речи не шло, я скачал много учебников (имею небогатый опыт прогарммирования на С++, и в учебниках есть необходимость)
Так уж получилось, что почти во всех учебниках, которые я скачал, и которые затрагивают Visual C++, речь идёт об MFC
Поэтому я и выбрал MFC, потому что про него много написано умными людьми (Том Арчер, Эндрю Уайтчепел, ну и в других книжках тоже есть)
Но последнее время с слышу отзывы вроде "Я бы не стал использовать MFC", "Вообще, не пиши на MFC", "Я больше к QT привык, MFC втопку" и т.д.
Но, при этом, эти комментарии неаргументированы.
Но мне всё равно очень интересно
А что тогда использовать?
Windows Forms? WinAPI?
Что вы посоветуете?
Очень важно
Буду благодарен за любой ответ
У меня такой вопрос
Вот я сейчас работаю в компании, которая занимается разработкой ПО на С++
Начал разработку проекта
Про технологию речи не шло, я скачал много учебников (имею небогатый опыт прогарммирования на С++, и в учебниках есть необходимость)
Так уж получилось, что почти во всех учебниках, которые я скачал, и которые затрагивают Visual C++, речь идёт об MFC
Поэтому я и выбрал MFC, потому что про него много написано умными людьми (Том Арчер, Эндрю Уайтчепел, ну и в других книжках тоже есть)
Но последнее время с слышу отзывы вроде "Я бы не стал использовать MFC", "Вообще, не пиши на MFC", "Я больше к QT привык, MFC втопку" и т.д.
Но, при этом, эти комментарии неаргументированы.
Но мне всё равно очень интересно
А что тогда использовать?
Windows Forms? WinAPI?
Что вы посоветуете?
Очень важно
Буду благодарен за любой ответ
На MFC писать не легче, а иногда и труднее, нежели на голом WinAPI. Это довольно тупая и не доделанная обертка над последним.
Если в других библиотеках можно взять и использовать какой то объект как он есть, т.е. он класс разработан до конца, то в MFC надо наследоваться, писать что то свое.
К примеру, поместить MFC объекты в контейнеры не получится, ибо нет у них нормального конструктора копирования. Визуальная разработка GUI вообще никакая, и все равно придется много руками писать.
VCL, WinForms, Qt в этом плане далеко впереди.
ЗЫ: раз пишешь на плюсах, то о WinForms забудь или учи решетку. VCL тоже к плюсам очень относительно принадлежит. Qt остается.
Если в других библиотеках можно взять и использовать какой то объект как он есть, т.е. он класс разработан до конца, то в MFC надо наследоваться, писать что то свое.
К примеру, поместить MFC объекты в контейнеры не получится, ибо нет у них нормального конструктора копирования. Визуальная разработка GUI вообще никакая, и все равно придется много руками писать.
VCL, WinForms, Qt в этом плане далеко впереди.
ЗЫ: раз пишешь на плюсах, то о WinForms забудь или учи решетку. VCL тоже к плюсам очень относительно принадлежит. Qt остается.
Цитата: oxotnik333
Qt остается.
Я тут забыл написать, но QT, к сожалению, не подходит, по одной простой причине - слишком дорог для коммерческого использования...
Решётка (C#?) не подходит, пишем только на плюсах, скорость работы всё-таки...
А что за VCL кстати?
К WinAPI пока не притрагивался особо, её вроде как сложнее изучать и писать на ней, поэтому начал с MFC...
Потом, когда наберусь практики, может перейду на WinAPI...
Или это потом может быть критическим решением? И лучше сразу на WinAPI?
Цитата: oxotnik333
На MFC писать не легче, а иногда и труднее, нежели на голом WinAPI.
Я так понял, что особой разницы нет?
Можно делать коммерческий софт на LGPL Qt, никто не предъявит претензий по этому поводу, и даже не предоставлять свои исходники, главное в недра Qt не лазить и не править там ничего.
С винапи скажу чесно - зае...шься, с МФС чуть попроще, если только формы клепать, но она к стати платная.
VCL - билдер, тоже платный
С винапи скажу чесно - зае...шься, с МФС чуть попроще, если только формы клепать, но она к стати платная.
VCL - билдер, тоже платный
Цитата: oxotnik333
с МФС чуть попроще, если только формы клепать, но она к стати платная.
А не знаешь, случайно, сколько примерно она стоит?
Цитата:
Решётка (C#?) не подходит, пишем только на плюсах, скорость работы всё-таки...
Qt тоже тормозной. правда, не знаю насколько в сравнении с C#.
Цитата: Alm3n
Qt тоже тормозной. правда, не знаю насколько в сравнении с C#.
1. Тормозной, где? Вы бы еще QT с питоном сравнили.
2. У всего своя область применения, у QT, MFC и иже с ними. Выбирается в зависимости от специфики проекта.
Помоему тормознутость софта напрямую зависит от кривоты рук кодера, а не от среды разработки :) :trollface: (я за Qt, хоть у него и runtime много весит в нестатике)
Афтар,пиши на WinAPI.Никакого рантайма таскать не надо,платности тоже нет,допиливать ничего не надо.Да,коду прибавится,но вышеозначенных проблем иметься не будет
И искать не придётся никаких компонент/функций,всё реализовано в системе(ниже WinAPI для пользователя ничего и нет:))
И искать не придётся никаких компонент/функций,всё реализовано в системе(ниже WinAPI для пользователя ничего и нет:))
Цитата: @pixo $oft
Афтар,пиши на WinAPI.
Нет, всё же скорее всего на Qt писать буду
где я вижу тормоза:
1) наследования от Qobject для любого объекта, у которого должны быть методы.
2) работа со строками. shared data - это, конечно, круто, но у меня был баг, где нужно было именно копировать строку, но она не копировалась(счетчик ссылок увеличивался), а в конечном итоге даже терялась после выхода из процедуры. пришлось прикрутить "на месте" добавление и удаление одного символа, чтобы создавалась копия строки.
3) общая перегруженность фреймворка. каждый объект наследует кучу всего из других объектов и получается очень уж большой. хотелось бы поменьше.
1) наследования от Qobject для любого объекта, у которого должны быть методы.
2) работа со строками. shared data - это, конечно, круто, но у меня был баг, где нужно было именно копировать строку, но она не копировалась(счетчик ссылок увеличивался), а в конечном итоге даже терялась после выхода из процедуры. пришлось прикрутить "на месте" добавление и удаление одного символа, чтобы создавалась копия строки.
3) общая перегруженность фреймворка. каждый объект наследует кучу всего из других объектов и получается очень уж большой. хотелось бы поменьше.
Цитата: Alm3n
где я вижу тормоза:
1) наследования от Qobject для любого объекта, у которого должны быть методы.
1) наследования от Qobject для любого объекта, у которого должны быть методы.
Не методы а слоты/сигналы.
Цитата: Alm3n
2) работа со строками. shared data - это, конечно, круто, но у меня был баг, где нужно было именно копировать строку, но она не копировалась(счетчик ссылок увеличивался), а в конечном итоге даже терялась после выхода из процедуры. пришлось прикрутить "на месте" добавление и удаление одного символа, чтобы создавалась копия строки.
Глюк какойто, ниразу с таким не встречался.
Цитата: Alm3n
3) общая перегруженность фреймворка. каждый объект наследует кучу всего из других объектов и получается очень уж большой. хотелось бы поменьше.
Помоему всё по теме наследуется QLabel->QFrame->QWidget->(QObject,QPaintDevice). С другой стороны перегруженость лишь даёт кучу функционала.
По своему опыту скажу. Использовал до этого только VCL. Да удобно. Клепаешь формочки быстро уже не говоря о дополнительных примочках типа DevExpress - красиво и удобно(про качество и скорость работы промолчу, не об этом).
Чуть более месяца назад пришлось перейти на VS2010 и соответственно остался только MFC. Тут даже где то моя тема была с вопросом. И сейчас я уже не задумываюсь хорош или плох MFC. Привык. Да, писанины по сравнению с VCL-ми компонентами побольше, но и контроля больше. Только вот одно НО. Если пишешь на WinAPI, то ты заботишься только о системных объектах, а когда на MFC, то заботишься не только о своевременном освобождении объекта, но и, в некоторых случаях, и об освобождении и системного объекта и объекта класса MFC.
От сюда следует, хватает опыта следить за объектами и памятью, умеешь читать английский(MSDN) - MFC не так уж и плох. Надо быстро склепать приложение - QT/VCL.
Чуть более месяца назад пришлось перейти на VS2010 и соответственно остался только MFC. Тут даже где то моя тема была с вопросом. И сейчас я уже не задумываюсь хорош или плох MFC. Привык. Да, писанины по сравнению с VCL-ми компонентами побольше, но и контроля больше. Только вот одно НО. Если пишешь на WinAPI, то ты заботишься только о системных объектах, а когда на MFC, то заботишься не только о своевременном освобождении объекта, но и, в некоторых случаях, и об освобождении и системного объекта и объекта класса MFC.
От сюда следует, хватает опыта следить за объектами и памятью, умеешь читать английский(MSDN) - MFC не так уж и плох. Надо быстро склепать приложение - QT/VCL.