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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почитайте Макконелла "совершенный код", почитайте Алана Купера "Психбольница в руках пациентов".
diagon
Higher
1929 / 1195 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
05.10.2011, 13:14 #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 #19
Цитата Сообщение от diagon Посмотреть сообщение
Как раз из этого и следует то, о чем я писал в начале - с точки зрения конечного пользователя WinAPI слишком ущербен, и использовать его крайне нежелательно. Но в специфичных областях(разработка тех же библиотек, например) его приходиться применять. Т.е. его можно рассматривать как инструмент для разработки библиотек / windows-specific приложений. Но не более.
С точки зрения водителя-таксиста, камаз - ущербный автомобиль. На нем неудобно развозить пассажиров.

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

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

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

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

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

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


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

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

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

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

/зы из личного опыта - класс, перенасыщенный "удобствами" не удобно использовать. (про развитие молчу)
Чем меньше в классе методов, тем он удобнее.
diagon
05.10.2011, 16:34
  #20

Не по теме:

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


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

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

ForEveR
В астрале
Эксперт С++
7970 / 4732 / 321
Регистрация: 24.06.2010
Сообщений: 10,541
Завершенные тесты: 3
05.10.2011, 17:12 #21
diagon, АПИ есть АПИ. Обертки классовые есть в MFC, ATL, Qt, boost etc. В конечном счете все работает через API системы. Так что не стоит гнать на АПИ. Никто же не заставляет юзать напрямую.
alkagolik
Заблокирован
05.10.2011, 17:28 #22
Ребята, вы спорите с "разных колоколен". Следует отталкиваться с того что любая ОС API это система взаимодействия между железом и разработчиком ПО. да да, именно так. api помогает избежать изучения сотен различных ассемблеров для прямого обращения к тому или иному МК, МП... для того чтобы api функционровала с железом ей скармливается драйвер. Сами же знаете, что драйвер одной ОС просто не совместим с другой ОС (исключая отдельные случаи возможности использования драйверов в другой ОС, с помощью костылей). Это я все к тому что на нее (api) нельзя смотреть с высоты прикладного программирования.
А теперь о гигантизме. То что виндовс сегодня поддерживает абсолютное большинство производимого железа - это факт, и этот факт есть одна из причин бесспорного доминирования этой ОС на рынке десктопов. Примечательно то, что мелкософт сегодня уже не ставит линух в список опасных конкурентов. Для того чтобы все это железо без проблем запускалось на единой архитектуре ОС и пишутся дополнительные миллионы строк кода. Я думаю что именно сама идея поддержки абсолютного большинства ассемблеров производителей железа и привела в итоге к такому гигантскому набору средств для работы исключительно с ним (железом).
diagon, это по сути я к вам обращаюсь. Попробуйте посмотреть на компьютер не как программист с++, а как инженер разработчик вычислительных модулей (электрических схем, микроконтроллеров, и т.д.) и тогда конечно станет очевидным тот факт, что кроме ассемблеров никак иначе запрограммировать железа нельзя, так же нельзя и использовать его. Для чего и были разработаны компиляторы (конкретно для обращения к ЦП). Вот вы что писать программы на ассемблере глупо... для мощного компьютера да, а для микроконтроллера просто нет иных средств кроме его личного ассемблера. В мире все относительно.
diagon
Higher
1929 / 1195 / 49
Регистрация: 02.05.2010
Сообщений: 2,925
Записей в блоге: 2
05.10.2011, 18:55 #23
Цитата Сообщение от ForEveR Посмотреть сообщение
diagon, АПИ есть АПИ. Обертки классовые есть в MFC, ATL, Qt, boost etc. В конечном счете все работает через API системы. Так что не стоит гнать на АПИ. Никто же не заставляет юзать напрямую.
Да я в общем-то догадываюсь, что для их реализации API используется... Но за счет инкапсуляции можно реализовать такую же либу средствами API уже другой платформы.

Цитата Сообщение от alkagolik Посмотреть сообщение
diagon, это по сути я к вам обращаюсь. Попробуйте посмотреть на компьютер не как программист с++, а как инженер разработчик вычислительных модулей (электрических схем, микроконтроллеров, и т.д.) и тогда конечно станет очевидным тот факт, что кроме ассемблеров никак иначе запрограммировать железа нельзя, так же нельзя и использовать его. Для чего и были разработаны компиляторы (конкретно для обращения к ЦП). Вот вы что писать программы на ассемблере глупо... для мощного компьютера да, а для микроконтроллера просто нет иных средств кроме его личного ассемблера. В мире все относительно.
Ну я же повторял пару раз -

Цитата Сообщение от diagon Посмотреть сообщение
Но в специфичных областях(разработка тех же библиотек, например) его приходиться применять. Т.е. его можно рассматривать как инструмент для разработки библиотек / windows-specific приложений. Но не более.
С тем что иногда без него не обойтись я не спорю. Но если есть альтернатива в виде какой-либо готовой либы, той же Qt, то имхо выбирать нужно последнюю.
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
05.10.2011, 18:55
Привет! Вот еще темы с ответами:

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 - C++
Всем привет, есть такая штука как autoHotKey смысл ее действия это считывать нажатия клавиш или комбо, и запускать определенные действия...

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

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


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

Или воспользуйтесь поиском по форуму:
Yandex
Объявления
05.10.2011, 18:55
Ответ Создать тему
Опции темы

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