Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Замена MFC и WinAPI  (Прочитано 9387 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« : 13-09-2005 23:01 » 

Не перевариваю MFC и WinAPI
Если пишешь на С++ под windows всегда ли можно обойтись без этих вещей. Если всегда, то что служит заменой? Только собственное написание или что-то ещё?
А если не всегда,то в каких случаях не обойтись.
Как я понял из предыдущих твоих высказываниях MFC это плохая реализация ООП? Неужто WinAPI по той же причине?
« Последнее редактирование: 13-09-2005 23:05 от Olegator » Записан
Alf
Гость
« Ответ #1 : 14-09-2005 00:02 » 

Не перевариваю 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 с таким облегчением - альтернатива появилась весьма разумная. Настолько разумная, что даже не верится, что две столь разные объектные модели делала одна и та же фирма, пусть даже с достаточно большим временным интервалом.
Записан
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 14-09-2005 00:16 » 

У Поста есть забавная статья о том, что настоящие программисты не программируют на Паскале. Гуляет по миру давно, сначала на магнитных лентах, а ныне по Сети. Если не читал, настоятельно рекомендую. Только не забывай, что это стеб, ибо написана в серьезном тоне, легко на это купиться. Так вот, там есть замечательная фраза о том, что "настоящий" программист сумеет написать фортрановскую программу на любом языке  Ага

Перефразируя Поста, MFC является примером того, как можно написать объектную библиотеку, поправ все мыслимые принципы объектного программирования.
Это я прочитал. Ты мне уже давал ссылку.
Собственно, поэтому я и воспринял появление .NET с таким облегчением - альтернатива появилась весьма разумная. Настолько разумная, что даже не верится, что две столь разные объектные модели делала одна и та же фирма, пусть даже с достаточно большим временным интервалом.
В чём разумность. Наверное MFC писали в спешке, чтобы заделать пустоту.
.NET разумен в плане ООП? Или возможность писать на разных языках?
Записан
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 14-09-2005 11:41 » 

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

Когда сравниваешь Windows 3 и Windows NT, тоже не верится, что это делала одна и та же фирма.

Одна из сильных сторон Микрософта -- нанимать правильных людей, если свои не справляются.  Для NT наняли разработчиков VMS, lля .NET они тоже нашли очень хороших людей, к тому же уже были преценденты удачных ООП библиотек -- Java,  Python.

Да, выход .NET -- выдающееся событие для Microsoft.  В кои веки они выпустили не просто большой программный продукт, но ещё и разумно и красиво спроектированный.  Разработка GUI упростилась в разы, очень удобный интерфейс для Platform Invoke, приличная производительность.
« Последнее редактирование: 14-09-2005 11:43 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines