Не перевариваю MFC и WinAPI
Если пишешь на С++ под windows всегда ли можно обойтись без этих вещей. Если всегда, то что служит заменой? Только собственное написание или что-то ещё?
Если задаться целью избежать использования MFC, то вполне можно обойтись и без нее.
Во-первых, существуют альтернативные компиляторы, например, от Borland, которые имеют свои библиотеки подержки. Хорошие или плохие - обсуждать здесь не будем, однако факт, что можно написать
работающую программу без использования MFC.
Во-вторых, и с компилятором C++ от MS можно использовать другие библиотеки - STL, ATL, WTL... Если их достаточно, вполне можно обойтись без MFC.
В-третьих, можно писать на "голом" API. Поскольку MFC представляет собой в основном настройку над API и добавляет не так уж много собственной функциональности, все то же самое можно сделать и напрямую, дублируя его функции. Правда, в большинстве случаев для прикладных задач это занятие больше смахивает на мазохизм и скорее приемлемо для студента, который хочет глубже разобраться в системных механизмах, чем для программера, которому нужно уложиться в отведенный срок с поставленной задачей. Однако теоретически возможно и такое. Правда, сочетание C++ и API выглядит несколько нелепо, тут скорее уместнее "чистый" C, использование которого для многих задач также является разновидностью мазохизма. Конечно, в отдельных случаях такой подход оправдан, но как универсальный я бы его не рекомендовал.
По поводу же избегания API... Для большинства прикладных задач его использование избыточно, вполне достаточно имеющихся в языке и его библиотеках средств. Однако если тебе нужно использовать специфические системные средства, вроде отслеживания других процессов и их окон, перехвата клавишных комбинаций и т.п., без него не обойтись. Так что тут не обойтись без чувства меры - использовать API ровно настолько, насколько необходимо, без злоупотреблений; если же острой необходимости нет, то и не использовать вовсе. Глупо, например, городить чтение файла через API, если того же результата можно добиться обычным потоком из <stdio.h>. Ну и, конечно же, написание красивой программы с использованием API требует виртуозного умения, помноженного на мастерское владение шаблонами проектирования. Иначе получится каша из низкоуровневых вызовов, перемешанных с бизнес-логикой, которая кое-как работает, но лучше ее не трогать от греха.
А если не всегда,то в каких случаях не обойтись.
Насчет API - см. выше. Насчет MFC - я таких случаев не знаю, IMHO обойтись можно всегда.
Как я понял из предыдущих твоих высказываниях MFC это плохая реализация ООП?
У Поста есть забавная статья о том, что настоящие программисты не программируют на Паскале. Гуляет по миру давно, сначала на магнитных лентах, а ныне по Сети. Если не читал, настоятельно рекомендую. Только не забывай, что это стеб, ибо написана в серьезном тоне, легко на это купиться. Так вот, там есть замечательная фраза о том, что "настоящий" программист сумеет написать фортрановскую программу на любом языке
Перефразируя Поста, MFC является примером того, как можно написать
объектную библиотеку, поправ все мыслимые принципы
объектного программирования.
Неужто WinAPI по той же причине?
WinAPI - это совсем другая тема.
По большому счету, WinAPI вовсе не предназначен для прикладных программистов. Это полный набор примитивов операционной системы, дающий доступ ко всем ее возможностям. Главное тут - не удобство, а полная функциональность.
Создавая среду программирования (VC++, VBasic, Delphi и т.п.), задача разработчика - оснастить эту среду такой библиотекой, которая позволит наиболее легко и логично решать большинство задач средствами языка. Они создают абстракции высокого уровня (файл, диалоговое окно, кнопка и т.п.), пряча в глубине детали низкоуровневого взаимодействия с системой через API. Чем выше уровень абстракции, тем легче программировать.
Так что в процитированной тобой фразе я не совсем точно выразился. Нельзя любить или не любить API - это бессмысленно, равно как и критиковать API - так уж устроена система, не нравится - выбирай другую. Мне не нравится не сам WinAPI, а необходимость к нему прибегать из-за несовершенства MFC.
Собственно, поэтому я и воспринял появление .NET с таким облегчением - альтернатива появилась весьма разумная. Настолько разумная, что даже не верится, что две столь разные объектные модели делала одна и та же фирма, пусть даже с достаточно большим временным интервалом.
