Мой реальный проект написан на MFC. Т.е. оболочка, конечно. Знаю, знаю всю муть, которую гонят про MFC. И это по большей части правда. Но проекту (виндовой реинкарнации) уже ~15 лет, и тогда особого выбора не было. А сейчас поздно соскакивать - иначе пользователи новой версии рискуют не дождаться. Не устаю радоваться, что в свое время при выборе между Borland'ом и MS выбрала таки MS и его кривое, но очень прозрачное MFC. Ну и потом, окна-диалоги - 66 часть проекта, а алгоритмы обработки от библиотек не зависят, ибо нет готовых. А если бы приложение было сильно формо-зависимо, но я бы выбрала... не знаю, чтобы я выбрала, но скорее всего другую работу. Ну их в ... эти формы, тоска.
А что касается чистого WinAPI, то тебе должно быстро надоесть стока многа букв каждый раз писать, это тоже неинтересно. За что и ценю MFC, так за то что при всей своей кривости, он таки полный контроль дает - если надо. Рекомендовать сейчас, для новых проектов, конечно, не буду. Но я бы, возникни такая нужда, искала бы что-то вроде - тонкое-прозрачное, но с более современной архитектурой. Но с полным контролем, а не как борландовский ужас.

Добавлено через 8 минут и 51 секунду

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

Мне одному кажется, что ТС не спрашивал на чём ему писать?
Вот вам топик http://forum.vingrad.ru/forum/act-ST/f-69/...2/unread-1.html Переезжайте!

о графике я упомянул, тут не вопрос - жопа!)



не пробовал, т.к. стараюсь писать только то где графики поменьше....  


  
принимаю.)


в свои прожи вообще чужого не пускаю - было пару раз что потом приходилось разбираться почему при куче потоков у кого-то что то начинает падать))

Свои либы - да прекрасно, но и писать их для ГУИ - напряг, так что бы они были универсальны...Поэтому с ГУИ не связываюсь...ну разве что по минимуму....


а ТС уже ответили давненько и он вообще пропал) - видимо помогло)

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

В таком случае у нас полный консенсус - все мои высказывания относились ТОЛЬКО к GUI. Общесистемная часть в Win32 API спроектирована и реализована на удивление хорошо. Ее вполне можно применять напрямую, без каких либо библиотечных прослоек (за исключением случаев, когда библиотеки УЖЕ используются в программе, для GUI например, как та же Qt. Для единообразия)

Выскажу мнение. Писать на WinApi гуй не такая уж большая проблема. Да, есть писанина, да, есть метание по MSDN, но если грамотно спланировать, то дальше можно пользоваться своей прослойкой. Поэтому не соглашусь, что большая программа с гуем из WinApi на 50 процентов состоит из WinApi функций. На следующий день после go to бог придумал sub routine. Как правило сообразив какойто контрол раз, потом пользуешь без ограничений.
В принципе можно пойти и дальше стандартных контролов, и написать полностью обработку самостоятельно, в этом плане мне очень сильно импонирует GuiChan, разобраться можно с пол оборота, и потом использовать стиль для своих поделок.
Очень хорошо выполнен Qt, кучу идей можно брать и от туда.
А в целом, как всегда, вопрос выбора обусловлен задачей (включая сроки, заказчика и тд и тп).
Если можно использовать готовое, и проект не для самообразования - вопрос выбора обычно не возникает.
P.S. В последние годы как ни странно стараюсь выполнять все приложения в консоли (по мере сил убеждая заказчика).

Это единственная здравая мысль в вашем послании. Поддерживаю.


На мой взгляд, не очень удачное обобщение.

Это сообщение отредактировал(а) ИванМ - 11.9.2010, 23:33

После чего и получается еще один фрейморк. Внимание, вопрос - нафига нужен ЕЩЕ ОДИН фреймворк, к тому же заточенный под задачу, когда есть куча готовых. Пока вижу один ответ - в готовых лень разбираться   

В смысле? Какое именно обобщение?

Предполагается, что стоит задача написать только с WinApi (почему, не знаю, может архитектор страдает тиранией). Хочу сказать, что это не такая чудовищная проблема, раскидал вызовы по своим классикам-врапперам, и юзай на здоровье.
Как уже писал, если есть возможность юзать готовое, можно не раздумывать (если разобраться с WinApi не есть сама задача).

Вы так уверенно говорите, потому что у вас есть готовая самописная GUI-библиотека или вы просто рассуждаете в теории?


Общесистемная часть очень широкое понятие. Что-то действительно удобно и просто реализовано, что-то не очень.
Далеко ходить не буду, приведу самый простой пример. Пользоваться оператором << для fstream удобнее, чем вызывать WriteFile.

То, что предполагал/хотел ТС забыли уже экрана 2 назад, теперь обсуждается 'API или не API - вот в чем вопрос'   

Ну в общем и целом конечно понятие слишком широкое, но по удобству использования БОЛЬШАЯ часть того, что не GDI+Окна гораздо удобнее того, что есть GDI+Окна

Разумеется. Даже пользоваться FILE* и printf будет удобнее, чем WriteFile. На то они и интерфейсы уровня библиотеки исполнения (наиболее оригинально это представленно в *nix'ах - там интерфейсы системы и библиотеки исполнения явно разделены в документации, но нигде больше   )

Что же касается WriteFile, то когда требуется нечто, не охваченное fstream (например Overlapped IO), то приходится опускаться на уровень CreateFile/WriteFile/ReadFile, и это не является катастрофой   Они даже могут мирно сосуществовать в одной программе

Это несравнимые вещи, даже если забыть о том, что << осуществляет текстовый вывод...
Насчет GUI, да, согласна, не очень неудобная вещь. В основном потому, что все эти долбанные хандлы не имеют семантики копирования + легкость попадания на утечку ресурсов + нехилые тормоза при выборе в контекст. Но это тоже можно улучшить с помощью совместно работающих оберток - над GDI-объектами и над CDC.

Библиотека громко сказано. Приходилось писать интерфейсы WinApi only. Минимум необходимых переходничков для конкретной задачи, ничего более. Но вполне можно писать, и на это не уходило 50 процентов кода, как тут уже писали.
Опять таки повторюсь, мои измышления основаны на факте, что ничего кроме WinApi юзать нельзя.
Если есть выбор - пишу для командной строки 

Вот с этим я уже соглашусь. Это не так категорично, как в вашем сообщении до этого.


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

возможно ли запускать Апи функции удаленно. Т.е. запуская программу на одном компъютере ждать выполнения Апи на другом?

используй http://technet.microsoft.com/ru-ru/sysinte...s/bb897553.aspx
или вот исходники аналогичной команды 

Присоединённый файл ( Кол-во скачиваний: 3 )
 RemCom_SRC_1.2.zip 41,28 Kb