Форум программистов, компьютерный форум CyberForum.ru

С++ для начинающих

Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 23, средняя оценка - 4.91
YusipovIlsur
11 / 11 / 2
Регистрация: 17.12.2010
Сообщений: 52
#1

Преимущество Win Api - C++

04.10.2011, 07:54. Просмотров 2931. Ответов 22
Метки нет (Все метки)

Буквально вчера создал тему, где задал вопрос о средствах, с помощью которых можно работать некоторым образом в командной строке. Нашлось много ответов, и часть из них сводилась к совету использовать средства Win Api. И, собственно, теперь сам вопрос:
На сколько это перспективно (если можно так сказать), и почему лучше начать работать именно с Win Api, а не, скажем, выучить библиотеку QT и писать на более высоком уровне? Или наоборот, лучше взяться за какую-нибудь среду разработки и изучить все предоставляемые ею возможности? Насколько это вообще "благодарное" дело работать с Win Api, и насколько больше его потенциал? [Надеюсь, что грамотно задал вопрос]

*Очень хотелось бы получить наиболее объективный ответ от людей, которые работали (работают) и с тем, и с тем. Заранее спасибо.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
04.10.2011, 07:54     Преимущество Win Api
Посмотрите здесь:

WIN API - C++
Доброе время суток. Учусь в институте и дали сделать такую хрень: Реализовать приложения Win32API: 1. Окно в центре экрана с фоном...

WIN API, кодировка - C++
Доброго времени суток! Вот если написать: MessageBox(NULL,(LPCWSTR) "Тест",(LPCWSTR)"Системное сообщение", MB_OK); выведется...

Потоки win api - C++
Здравствуйте. Такое задание: необходимо написать программу, которая в главном потоке создает дополнительный поток, и уже в нем...

Построение графика в Win Api - C++
Требуется построить график по точкам. Все координаты даны. Не могу найти в пространстве интернета, с помощью каких функций это можно...

win api точки входа - C++
меня интересуют названия функция получения точки входа файла получения конца файла (feof не подойдёт) и функция изменения точки входа. ...

DrawText win api - Мистика =) - C++
Начинал изучать C++ на FreeBSD, собирал мейкфайлы и горя не знал. Полез в винде разбираться с её API, и начался дурдом. Вот код. Интересует...

Копирование файлов без win api - C++
Добрый день. Что прошу: Мне нужно выполнить копирование моего (ехе) в определенные директории - папки. Мне подсказали что можно...

После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
solar_wind
756 / 747 / 42
Регистрация: 06.07.2009
Сообщений: 2,969
Завершенные тесты: 1
04.10.2011, 08:48     Преимущество Win Api #2
YusipovIlsur,
1. Если ты используешь Qt, MFC или любую другую библиотеку под windows, никто тебе не мешает в той же программе использовать winAPI.
2. winAPI дает самые широкие возможности для работы с windows. В надстройках есть реализации далеко не для всего функционала операционки. То есть некоторые вещи ты можешь сделать только на winAPI.
3. В любой программе или библиотеке есть косяки. Когда ты работаешь с winAPI ты юзаешь только косяки winAPI, а когда используешь другие библиотеки то косяки winAPI+косяки библиотеки. Ведь в конечном итоге все эти библиотеки используют winAPI.
4. Конечно у winAPI есть недостаток: в библиотеках многие вещи делаются проще чем через winAPI, для того эти библиотеки и нужны.

Вывод: Используй библиотеки, а где надо winAPI.
ITDeveloper
85 / 85 / 5
Регистрация: 14.01.2011
Сообщений: 263
04.10.2011, 09:13     Преимущество Win Api #3
Функции WinApi - это функции непосредственно самой операционной системы. Следовательно используя только WinApi без сторонних библиотек будет выйгрышь в надежности и стабильности кода, его скорости, а так же меньше проблем с переносом программы (проекта) на другие машины.
easybudda
Эксперт С++
9458 / 5471 / 927
Регистрация: 25.07.2009
Сообщений: 10,495
04.10.2011, 10:05     Преимущество Win Api #4
YusipovIlsur, сильно зависит от того, чем собираетесь заниматься. Если кроссплатформенность для вас пустое слово, приложения будут исключительно под винду + не пугает написание порой довольно громоздких и сложных конструкций ради получения как бы более быстрого кода, это при условии, что наделаете гарантированно меньше ошибок, чем разработчики популярных оконных библиотек, то winapi - ваш выбор!
ITDeveloper
85 / 85 / 5
Регистрация: 14.01.2011
Сообщений: 263
04.10.2011, 10:23     Преимущество Win Api #5
Конечно, используя WinApi, никакой кроссплатформенности не будет. А по поводу хороших библиотек хочется уточнить, что многие из них платные. Соглашусь с YusipovIlsur, что все зависит от того, что хотите сделать в итоге!
YusipovIlsur
11 / 11 / 2
Регистрация: 17.12.2010
Сообщений: 52
04.10.2011, 17:12  [ТС]     Преимущество Win Api #6
Ну, в целом картина ясна. Пожалуй, совместное использование тех и других средств - наиболее правильный вариант, для написание не особо специализированных программ.
Всем огромное спасибо, за участие в обсуждении! (=
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
04.10.2011, 17:27     Преимущество Win Api #7
На WinAPI писать невозможно, код абсолютно нечитаем.
Для примера(выдрал из инэта):
C++
1
2
HANDLE Com2Port; 
Com2Port=CreateFile("COM2",GENERIC_READ|GENERIC_WRITE,0, NULL,OPEN_EXISTING,0,NULL);
Во-первых, такая запись проста ужасна из-за большого количества параметров.

Во-вторых, может показаться, что этот код создает файл. Но нет, функция CreateFile настолько универсальна, что в данном случае используется для получения указателя на порт. Круто, правда?
alkagolik
Заблокирован
04.10.2011, 17:34     Преимущество Win Api #8
YusipovIlsur, да все просто. winAPI это системные вызовы ОС. Например чтение\запись ключей реестра без winapi реализовать вроде как нельзя, а вся конфигурация (да и вообще всё) хранится именно там, следовательно и к железу напрямую вы не сможете обратиться без winapi. Окошки там всякие, менюшки это на выбор... рисованием заниматься ))

Добавлено через 1 минуту
Цитата Сообщение от diagon Посмотреть сообщение
такая запись проста ужасна из-за большого количества параметров
это еще цветочки
Bers
Заблокирован
04.10.2011, 18:21     Преимущество Win Api #9
Цитата Сообщение от diagon Посмотреть сообщение
Во-первых, такая запись проста ужасна из-за большого количества параметров.
Меньшее количество параметров - более кастрированный функционал.
Ничто не мешает сделать мини-обёртку над функцией, если стабильно требуется каждый раз заполнять некоторые аргументы одними и теми же данными.


Цитата Сообщение от diagon Посмотреть сообщение
Во-вторых, может показаться, что этот код создает файл. Но нет, функция CreateFile настолько универсальна, что в данном случае используется для получения указателя на порт. Круто, правда?
А вы думали, что файл - это только поименованная область на жестком диске?
Файл - абстрактное понятие. Это - хранилище данных, которое может быть источником или приёмником данных.

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

В вашем примере, создаётся файл, который будит связан с "физическим устройством" - ком-порт.
Вы на руки получаете описатель созданного файла, с помощью которого можно будит пересылать данные.

Если раньше вы все время думали, что файл - это всякие документики аля Student.txt на вашем жестком диске, то это не проблема имени функции, а проблема вашей недообразованности.

А что касается читаемости - ну меня лично напрягает венгерская нотация. А так в общем то.. все вполне себе читается...
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
04.10.2011, 19:45     Преимущество Win Api #10
Цитата Сообщение от Bers Посмотреть сообщение
Меньшее количество параметров - более кастрированный функционал.
Ничто не мешает сделать мини-обёртку над функцией, если стабильно требуется каждый раз заполнять некоторые аргументы одними и теми же данными.
Более логичной была бы функция, которая принимала бы только один параметр - имя файла.

Цитата Сообщение от Bers Посмотреть сообщение
А вы думали, что файл - это только поименованная область на жестком диске?
Файл - абстрактное понятие. Это - хранилище данных, которое может быть источником или приёмником данных.
Создан специально для того, что бы можно было абстрагироваться от конкретного физического устройства - жесткого диска, принтера, ком-порта и тп.
В вашем примере, создаётся файл, который будит связан с "физическим устройством" - ком-порт.
Вы на руки получаете описатель созданного файла, с помощью которого можно будит пересылать данные.
Ничего при этом не создается.
И настораживает в CreateFile не File, а Create. Это-то слово вполне однозначно, разве нет?
И вообще, чем более универсален код, тем сложнее его применять на практике.
WinAPI слишком универсален, писать программы на нем также приятно, как и на ассемблере. И, как и ассемблер, он морально устарел. Бывают, конечно, области где без него не обойтись...
Но имхо использования WinAPI следует избегать, пока это возможно.
Как минимум из-за непереносимости.
Bers
Заблокирован
04.10.2011, 19:56     Преимущество Win Api #11
Цитата Сообщение от diagon Посмотреть сообщение
Более логичной была бы функция, которая принимала бы только один параметр - имя файла.
Получим очень очень частный случай.
Потом захотим, что бы файл имел дополнительные параметры, потом ещё какие то. И что? Предлагаете Майкрософт написать 100500 разных перегрузок одной и той же функции для всех случаев жизни? И поддерживать их все? Или все таки одну, универсальную?

Система должна подстраиваться под 100500 клиентов, или клиенты под систему?
Библиотека должна подстраиваться под каждого пользователя, или каждый пользователь сам обеспечит себе все необходимое штатными средствами библиотеки?

Добавлено через 5 минут
Цитата Сообщение от diagon Посмотреть сообщение
Ничего при этом не создается.
И настораживает в CreateFile не File, а Create. Это-то слово вполне однозначно, разве нет?
Возвращаемый HANDLE указывает в никуда? Или все таки на какие то внутренние данные, которые были созданы в системе специально по вашему запросу?
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
04.10.2011, 20:06     Преимущество Win Api #12
Цитата Сообщение от Bers Посмотреть сообщение
Система должна подстраиваться под 100500 клиентов, или клиенты под систему?
Первое. Ибо если система не понравиться клиентам, то клиенты выберут другую систему. Что многие и сделали...


Цитата Сообщение от Bers Посмотреть сообщение
Потом захотим, что бы файл имел дополнительные параметры, потом ещё какие то.
Сделать другую функцию, которая меняет права файла.
Функции должны делать то, что должны. Функция, создающая файл, не должна делать что-либо еще.


Цитата Сообщение от Bers Посмотреть сообщение
Возвращаемый HANDLE указывает в никуда? Или все таки на какие то внутренние данные, которые были созданы в системе специально по вашему запросу?
Указывает, но никак не на созданный файл.
Bers
Заблокирован
04.10.2011, 20:11     Преимущество Win Api #13
Цитата Сообщение от diagon Посмотреть сообщение
Первое. Ибо если система не понравиться клиентам, то клиенты выберут другую систему. Что многие и сделали...
Ну.. тогда ищите что нибудь получше.


Цитата Сообщение от diagon Посмотреть сообщение
Сделать другую функцию, которая меняет права файла.
Функции должны делать то, что должны. Функция, создающая файл, не должна делать что-либо еще.
А что ещё по вашему делает функция создания файла, кроме создания файла?


Цитата Сообщение от diagon Посмотреть сообщение
Указывает, но никак не на созданный файл
На что указывает?
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
04.10.2011, 20:18     Преимущество Win Api #14
Цитата Сообщение от Bers Посмотреть сообщение
Ну.. тогда ищите что нибудь получше.
Да я уже давно нашел...) Qt/java


Цитата Сообщение от Bers Посмотреть сообщение
что ещё по вашему делает функция создания файла, кроме создания файла?
В данном случае устанавливает права на файл, принимает переменную, указывающую, создавать ли файл при его отсутствии(вполне логичный параметр, да), атрибуты и еще несколько абсолютно лишних параметров.
Цитата Сообщение от Bers Посмотреть сообщение
На что указывает?
Ну, если следовать вашей терминологии, то на уже созданный файл.
Но как-то не ассоциируется у меня порт с файлом, хоть убей.
Bers
Заблокирован
04.10.2011, 21:40     Преимущество Win Api #15
Цитата Сообщение от diagon Посмотреть сообщение
В данном случае устанавливает права на файл, принимает переменную, указывающую, создавать ли файл при его отсутствии(вполне логичный параметр, да), атрибуты и еще несколько абсолютно лишних параметров.
Вы получаете описатель файла, который для вас создаёт система где то в своих недрах.
Допустим, вы хотите создавать файл вот так:

описательФайла = СоздатьФайл(имя);

А режим работы файла (считай устройства), задавать позднее при необходимости:

УстановитьРежим(описательФайла, режим);


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

Добавлено через 15 минут
Можно например, пойти таким путём:

описательФайла = СоздатьФайлПринтера(имя, режимПринтера);
описательФайла = СоздатьФайлТекстовый(имя);
и тп.

Но ведь реальные устройства могут быть нестандартными. Как тогда быть со всеми этими сеттерами и геттерами?
Писать для кождого устройства свои наборы?

ИзменитьРежимПринтера()
ИзменитьРежимТекстовогоФайла()
изменитьРежимКомПорта()
и тд?

Вы представляете себе какое количество функций придётся написать, и сколько их придётся поддерживать?


Что значит для крупного проекта добавление всего одной функции?
Я сам по опыту не знаю. Но читал из книг, что это что-то такое:
- изменения во всех документах проекта (работа руководителей проекта)
- изменения в архитектуре (не всегда, но если имеет место быть - стоимость функции взлетит многократно)
- изменение модуля, в который вводится функция (оплата высокооплачиваемых специалистов)
- тестирование модуля, тестирование всех модулей которые хоть как то могут быть связанны с модифицированным.

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

В общем, чем лаконичнее и минималистичнее интерфейс, тем ниже в нем вероятность ошибок, он проще и дешевле и в разработке, и в сопровождении.

Поэтому, если вы сделаете мини-обёртку над функцией винапи для собственного же удобства - вам это будит стоить копейки.
Если Майкрософт для вашего удобства будит делать дополнительную функцию - ей это будит стоить тысячи рублей.
А поскольку Майкрософт одна, а вас - клиентов, очень много, и каждый со своим прибабахом, то Майкрософт решили сделать максимально минималистичный, но в тоже время универсальный интерфейс, что бы каждый мог пользоваться по своим потребностям. Кому не нравится - те могут пользоваться библиотеками, типа кьют, которые на самом деле - всего лишь надстройки над интерфейсами ОС.
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
05.10.2011, 07:18     Преимущество Win Api #16
Цитата Сообщение от Bers Посмотреть сообщение
Вы получаете описатель файла, который для вас создаёт система где то в своих недрах.
Допустим, вы хотите создавать файл вот так:
описательФайла = СоздатьФайл(имя);
А режим работы файла (считай устройства), задавать позднее при необходимости:
УстановитьРежим(описательФайла, режим);
что делать, если реальное устройство таково, что задать режим его работы можно только в момент создания файлаУстройства, а позднее создавать нельзя?
Добавлено через 15 минут
Можно например, пойти таким путём:
описательФайла = СоздатьФайлПринтера(имя, режимПринтера);
описательФайла = СоздатьФайлТекстовый(имя);
и тп.
Но ведь реальные устройства могут быть нестандартными. Как тогда быть со всеми этими сеттерами и геттерами?
Писать для кождого устройства свои наборы?
ИзменитьРежимПринтера()
ИзменитьРежимТекстовогоФайла()
изменитьРежимКомПорта()
и тд?
Есть такое понятие как ООП. Можно сделать класс принтер, и уже туда засунуть все необходимое(что и сделано во многих библиотеках).
Но фишка WinAPI в универсальности(а без нее он даром никому не нужен). Т.е. никакого ООП, а следовательно удобства, читабельности, эстетичности и просто юзабильности в нем нет и быть не может. Это как ассемблер - теоретически написать на нем можно все, но практически это неоправданно трудно и глупо. И также, как и код ассемблера, он непереносим. Зато можно использовать библиотеки более высокого уровня, код становиться в 100500 раз лучше(легче сопровождается, быстрее пишется, меньше вероятность допустить ошибку, лучше читается и тд и тд) и при этом компилируется под разными платформами.


Цитата Сообщение от Bers Посмотреть сообщение
В общем, чем лаконичнее и минималистичнее интерфейс, тем ниже в нем вероятность ошибок, он проще и дешевле и в разработке, и в сопровождении.
Не спорю, только не вижу связи между лаконичностью, минималистичностью и WinAPI. Это скорее антонимы.
Bers
Заблокирован
05.10.2011, 12:47     Преимущество Win Api #17
Цитата Сообщение от diagon Посмотреть сообщение
Есть такое понятие как ООП. Можно сделать класс принтер, и уже туда засунуть все необходимое(что и сделано во многих библиотеках).
Но фишка WinAPI в универсальности(а без нее он даром никому не нужен). Т.е. никакого ООП, а следовательно удобства, читабельности, эстетичности и просто юзабильности в нем нет и быть не может. Это как ассемблер - теоретически написать на нем можно все, но практически это неоправданно трудно и глупо. И также, как и код ассемблера, он непереносим. Зато можно использовать библиотеки более высокого уровня, код становиться в 100500 раз лучше(легче сопровождается, быстрее пишется, меньше вероятность допустить ошибку, лучше читается и тд и тд) и при этом компилируется под разными платформами.
ВинАпи - это интерфейс операционной системы. Какая к чорту кроссплатформенность?
Вы понятия не попутали?

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

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

Поддержка ООП библиотекой - это написание дополнительных классов-обёрток над глобальными функциями, с экспортом методов классов из длл.

По сути - дополнительная работа. Дополнительная нагрузка на весь персонал, как следствие - резкое удорожание стоимости разработки.

Слой винапи - один из наиболее низкоуровневых с точки зрения разработчика целевого проекта.
Если бы Майкрософт обеспечивали бы поддержку ООП, со всеми кастрированными, но более удобными версиями методов - это привело бы:

1. Процедурные языки не поддерживают ООП. И все эти "удобные штуки" прошли мимо сишников-системщиков. Потеря основного сегмента рынка.

2. Резкое удорожание продукта (который к тому же окажется более глючным. Все классы унаследуют косяки самого винапи + добавят свои собственные).

Это не выгодно экономически. Вот этой очевидности вы никак не можете понять. Майкрософт зарабатывает деньги своими продуктами. Виндовс со своей винапи - коммерческий продукт.
И продукт этот создаётся таким образом, что бы его можно было выгодно продать. А не для того, что бы лично вам им было удобно пользоваться.

Потребности к удобству и функциональности конечного потребителя-программиста целевого проекта слишком разнообразны. И удовлетворять их призваны библиотеки-надстройки.
Которые создаются программистами-инструментальщиками.

Вы так и не поняли сути модульного программирования: винапи предназначен не для конечного пользователя-программиста. А для разработчиков-инструментальщиков, которые и разрабатывают относительно небольшие, но очень специализированные библиотеки-инструменты, которые и адаптируют громоздкий универсальный интерфейс винапи для решения любых конкретных задач.

Причем библиотека-надстройка над винапи предоставляет решение лишь конкретной задачи. И по сути является более удобной (и более кастрированной) версией самой винапи.

Если вам понадобилось создавать окошко, вы можете реализовать это на винапи, и написать километр кода.

А можете взять глют, и написать несколько десятков строчек.

Но фишка в том, что глют использует лишь часть апи ОС, и может себе позволить добавлять всякие фичи для удобства конечного потребителя. Ведь ей не нужно поддерживать все 100500 винапишных функций. Только те, что отвечают за создание и типовую обработку окна. (строго говоря, инструмент рассчитанный на конечного потребителя обязан быть удобным. Или от него откажутся) .

(я специально опускаю тот факт, что инструментальные библиотеки юзают ограниченный набор АПИ разных осей, с претензией на кросс-платформенность, тем самым расширяя свои сегменты рынка)

Если потом понадобится функционал не предусмотренный самой архитектурой глюта - вам придётся либо менять его на другую библиотеку ( И как следствие - лавинообразные изменения по всему вашему целевому проекту).

Либо написание собственной библиотеки аналога-глют, либо написания адаптера, который преобразует другую библиотеку к интерфейсу глют + позволит юзать доп. плюшки новой библы.

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

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

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

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

Если же Майкрософт сама начнёт шлёпать такие инструменты и внедрять их в собственную винапи, это приведёт к резкому удорожанию их продукта. Что плохо скажется на бизнесе, и пострадают все.

Вот так это можно отобразить графически:

Целевые проекты
|
|
движки типовых проектов <--> бизнес-логика целевых проектов
|
|
набор различных инструментальных библиотек
|
|
АПИ различных ОС, ГАПИ, и тп

Как видите АПИ ОС - наиболее низкий уровень.
Ниже его уже начинаются модули самой ОС.

Цитата Сообщение от diagon Посмотреть сообщение
Не спорю, только не вижу связи между лаконичностью, минималистичностью и WinAPI. Это скорее антонимы.
Это компромисс между минималистичностью и универсальностью, с помощью которого можно свести к минимуму количество разных функций, что позволяет упростить и удешевить процесс разработки и сопровождения. Я об этом выше уже написал.

Почитайте Макконелла "совершенный код", почитайте Алана Купера "Психбольница в руках пациентов".
diagon
Higher
1928 / 1194 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
05.10.2011, 13:14     Преимущество Win Api #18
Цитата Сообщение от Bers Посмотреть сообщение
ВинАпи - это интерфейс операционной системы. Какая к чорту кроссплатформенность?
Никакой. Но если использовать готовые библиотеки(та же qt), то кроссплатформенность в них присутствует.

Цитата Сообщение от Bers Посмотреть сообщение
И какой к чорту ооп в уже откомпилированном коде?
ООП существует только на этапе разработки. После компиляции никаких классов уже не существует. Приплюснутые классы сначала преобразуются в си-структуры, потом ассемблируются.
При чем здесь бинарный код? Я про плюсный писал.


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




Цитата Сообщение от Bers Посмотреть сообщение
По сути - дополнительная работа. Дополнительная нагрузка на весь персонал, как следствие - резкое удорожание стоимости разработки.
Не вижу связи. Вроде как переход к ООП наоборот облегчает и ускоряет процесс написания и отладки кода.


Цитата Сообщение от Bers Посмотреть сообщение
Слой винапи - один из наиболее низкоуровневых с точки зрения разработчика целевого проекта.
Если бы Майкрософт обеспечивали бы поддержку ООП, со всеми кастрированными, но более удобными версиями методов - это привело бы:
1. Процедурные языки не поддерживают ООП. И все эти "удобные штуки" прошли мимо сишников-системщиков. Потеря основного сегмента рынка.
2. Резкое удорожание продукта (который к тому же окажется более глючным. Все классы унаследуют косяки самого винапи + добавят свои собственные).
Это не выгодно экономически. Вот этой очевидности вы никак не можете понять. Майкрософт зарабатывает деньги своими продуктами. Виндовс со своей винапи - коммерческий продукт.
И продукт этот создаётся таким образом, что бы его можно было выгодно продать. А не для того, что бы лично вам им было удобно пользоваться.
Здесь вы правы, но из этого же следует, что людям, пишущим на высокоуровневых языках попросту невыгодно пользоваться WinAPI. цпп - не исключение. Мелкомягким проще делать универсальный интерфейс, пользователям проще использовать готовые библиотеки. Все довольны.



Цитата Сообщение от Bers Посмотреть сообщение
Вы так и не поняли сути модульного программирования: винапи предназначен не для конечного пользователя-программиста. А для разработчиков-инструментальщиков, которые и разрабатывают относительно небольшие, но очень специализированные библиотеки-инструменты, которые и адаптируют громоздкий универсальный интерфейс винапи для решения любых конкретных задач.
А я хотел вам это объяснить...)
Как раз из этого и следует то, о чем я писал в начале - с точки зрения конечного пользователя WinAPI слишком ущербен, и использовать его крайне нежелательно. Но в специфичных областях(разработка тех же библиотек, например) его приходиться применять. Т.е. его можно рассматривать как инструмент для разработки библиотек / windows-specific приложений. Но не более.





Цитата Сообщение от Bers Посмотреть сообщение
Если вам понадобилось создавать окошко, вы можете реализовать это на винапи, и написать километр кода.
А можете взять глют, и написать несколько десятков строчек.
Но фишка в том, что глют использует лишь часть апи ОС, и может себе позволить добавлять всякие фичи для удобства конечного потребителя. Ведь ей не нужно поддерживать все 100500 винапишных функций. Только те, что отвечают за создание и типовую обработку окна. (строго говоря, инструмент рассчитанный на конечного потребителя обязан быть удобным. Или от него откажутся) . То бишь глют - это лишь надстройка над апи оси, и представляет собой весьма-весьма кастрированный интерфейс использованных апи функций оси, и рассчитан на выполнения только частных случаев конкретных задач.
(я специально опускаю тот факт, что инструментальные библиотеки юзают ограниченный набор АПИ разных осей, с претензией на кросс-платформенность, тем самым расширяя свои сегменты рынка)
Если потом понадобится функционал не предусмотренный самой архитектурой глюта - вам придётся либо менять его на другую библиотеку ( И как следствие - лавинообразные изменения по всему вашему целевому проекту).
Либо написание собственной библиотеки аналога-глют, либо написания адаптера, который преобразует другую библиотеку к интерфейсу глют + позволит юзать доп. плюшки новой библы.
Все это создаст большой гемморой, который приведёт к потерям времени и денег. Обычно ещё на этапе проектирования максимально тщательно определяются требования к используемым инструментам, что бы подобного не произошло.
В последнем предложении из цитаты и раскрывается вся суть =)
Если правильно спроектировать проект, то никаких лавинообразных изменений не потребуется.

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



Цитата Сообщение от Bers Посмотреть сообщение
Это компромисс между минималистичностью и универсальностью, с помощью которого можно свести к минимуму количество разных функций, что позволяет упростить и удешевить процесс разработки и сопровождения.
Как-то не вижу я логики. По-вашему, если написать одну большую функцию с парой сотен параметров, то ее будет проще сопровождать?
Bers
Заблокирован
05.10.2011, 15:54     Преимущество Win Api #19
Цитата Сообщение от diagon Посмотреть сообщение
Как раз из этого и следует то, о чем я писал в начале - с точки зрения конечного пользователя WinAPI слишком ущербен, и использовать его крайне нежелательно. Но в специфичных областях(разработка тех же библиотек, например) его приходиться применять. Т.е. его можно рассматривать как инструмент для разработки библиотек / windows-specific приложений. Но не более.
С точки зрения водителя-таксиста, камаз - ущербный автомобиль. На нем неудобно развозить пассажиров.

С точки зрения водителя-камазиста, легковушка - ущербный автомобиль, на нем неудобно возить большие объёмные грузы.

С точки здравого смысла - рассуждать с такой позиции об ущербности инструментов - само по себе ущербно.

ВинАпи не ущербный. Он отлично справляется со своим назначением. И он не предназначен для того, что бы его хардкорно размазывали по всему коду, и при этом сетовали: "чото как то не удобно блин"

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

Цитата Сообщение от diagon Посмотреть сообщение
Как-то не вижу я логики. По-вашему, если написать одну большую функцию с парой сотен параметров, то ее будет проще сопровождать?
Функцию-универсал с 10тью аргументами проще сопровождать, чем 10 разных функций, с одним аргументом.

При развитии продукта (а удачный продукт всегда развивается), функция с 10тью аргументами может породить ещё одну функцию с 10тью аргументами. Получится 20 аргументов на две функции.


10 функций по одному аргументу при развитии породят по десять функций с одним аргументом на каждую старую. Получим 100 аргументом на 100 функций.

Что проще сопровождать, 20 аргументов на две функции, или 100 аргументов на 100 функций?

При разработке интерфейса библиотеки/класс и тп - всегда нужно стремится к минимально-возможному количеству методов. Чем меньше - тем лучше.
При этом, при конструировании метода нужно стремится к минимальному количеству аргументов.

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

/зы из личного опыта - класс, перенасыщенный "удобствами" не удобно использовать. (про развитие молчу)
Чем меньше в классе методов, тем он удобнее.
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
05.10.2011, 16:34     Преимущество Win Api
Еще ссылки по теме:

Глобальное считывание комбинаций win api - C++
Всем привет, есть такая штука как autoHotKey смысл ее действия это считывать нажатия клавиш или комбо, и запускать определенные действия...

Win Api ошибка undefined reference to - C++
пишу функцию BOOL OnCreate(HWND hwnd,LPCREATESTRUCT) { HDC hdc; hBitmap=(HBITMAP)LoadImage(NULL, &quot;IMG.bmp&quot;,IMAGE_BITMAP, 0,...

Win api GetDlgItemInt что за второй параметр - C++
второй параметр функции UINT WINAPI GetDlgItemInt( _In_ HWND hDlg, _In_ int nIDDlgItem, _Out_opt_ BOOL...

win API:найти информацию о логических дисках. - C++
Определить типы логических дисков, обьём диска, колличество секторов в клястере, тип драйвера.

Нужен код самого простого проекта в Win Api - C++
Скажите начальный код самого простого проекта в WinApi только самое основное основные функции структура.. Просто начал учить а по книжке...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
diagon
05.10.2011, 16:34     Преимущество Win Api
  #20

Не по теме:

Цитата Сообщение от Bers Посмотреть сообщение
Проблема не в винапи, а в вашей психологии програмиста-пользователя, который, пользуясь готовым инструментом, привык писать на самом верхнем уровне.
Не совсем привык... Просто начинаю потихоньку осваивать ООП, и его преимущества мне уже очевидны. Писал когда-то на яве класс, который находит корни уравнения дихотомией, нужно было для решения одной олимпиадной задачки. Сейчас задали реализовать дихотомию на паскале, но мне было как-то лень ее писать с нуля, и я решил просто скопипастить готовый исходник. Но jvm у нас на компьютерах не установлена, следовательно продемонстрировать, что прога работает, я не мог. В итоге убил часов 6, но принес рабочую прогу на телефоне(пришлось немного изучить Android =) ). Ну это так, оффтопик.


Цитата Сообщение от Bers Посмотреть сообщение
Функцию-универсал с 10тью аргументами проще сопровождать, чем 10 разных функций, с одним аргументом.
А по-моему наоборот...)

Ладно, надоело мне спорить, это уже вопросы философии. Заканчиваю оффтоп...

Yandex
Объявления
05.10.2011, 16:34     Преимущество Win Api
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru