WinAPI и POSIX , бой насмерть

[shm]

Не вижу никаких проблем работать под *nix в объектном стиле. Хотя api nix тоже далеко не идеально, но вот конкретно об этой проблеме слышу впервые. Тот же Qt как пример.

[scrambrella]

Цитата shm @ 23.04.21, 06:59

Не вижу никаких проблем работать под *nix в объектном стиле. Хотя api nix тоже далеко не идеально, но вот конкретно об этой проблеме слышу впервые. Тот же Qt как пример.

Писать нативные проги вместо QT это задротство. А ещё Жаба есть.

[Qraizer]

Вот как перенесу всё, кроме первой страницы, в Холивары, вот там и флудите на здоровье. Но-таки отвечу, коли сам начал.

Цитата shm @ 22.04.21, 19:22

Не смог сдержаться. На мой взгляд WinAPI - это как раз таки пример как не надо делать api. Сравнить ту же модель синхронизации Event'ах и *nix CV: можно посмотреть различия на примере consumer-producer. А костыли вроде PulseEvent и SignalObjectAndWait откуда взялись? Именно из-за абсолютно кривой архитектуры. Правда со временем до MS это начало доходить и теперь даже futex'ы появились.

Этот API начала создавать IBM для своей (на пару с MS) OS/2 NT. Если уж конкретно за модель синхронизации, то я уже 15 лет утверждаю и буду продолжать это делать, что виндовая модель превосходна и никакая другая мною виденная ей не годится и в подмётки. pthread суть убожество по сравнению с той гибкостью, которая легко и просто позволяет создавать произвольнейшие алгоритмы управления взаимодействием между потоками на WinAPI. Попробуй реализовать простую модель "много писателей/много читателей" с приоритетом у писателей и взаимным неблокированием читателей. На pthread запаришься программить условные переменные и как следствие отлаживать их на дидлоках, на WinAPI обойдёшься четырьмя объектами синхронизации и парой/четвёркой API-вызовов на входе и выходе критической секции у каждого реципиента. Причём с высокой вероятностью без дидлоков, если не забудешь рекомендации Рихтера 15-летней выдержки. Хотя отладка всё ж может понадобиться. За PulseEvent() не скажу, никогда не пользовал, а SignalObjectAndWait() шутка иногда полезная ибо атомарная. Вы просто не умеете готовить синхронизацию.
И это я даже ещё не упомянул модель прав и аудита, без которой ни один ядерный объект, не исключая объекты синхронизации, не обходится и посредством которого высокопривилегированные процессы могут создавать правила взаимодействия процессов в разных сессиях и даже на разных рабочих станциях. Включая как физически разные компьютеры, так и разные WindowStation одного конкретного компьютера. И не надо тут про аналоги в правах доступа и допAPI системных процессов в лине, они и рядом не валялись по гибкости. Вы просто не умеете готовить безопасность в WinAPI. Это не наезд, это сожаление. Как жаль бывает человека, которому показали формулы в Экселе, но забыли рассказать о макросах.
Но вообще, ты вот серьёзно думаешь, что WinAPI – это экспорт kernel32, user32 и gdi32? А как же advapi32? А common controls? Shell? Multimedia? Где OLE с Automation? А что с DirectX? Та просто загляни на Programming reference for the Win32 API и не забудь, что это только ОC API, а помимо этого существует интегрированные в ОС .NET, PowerShell, WBS итд итп. Ну, и как тут сравнивать с POSIX с его жалким man-ом, iOS, Андроидом и чем там ещё?

Цитата shm @ 22.04.21, 19:22

Даже далекому от WinAPI человеку стоит просто взглянуть на ту же CreateWindowEx и все становится понятно.

Далекому будет понятно одно, недалёкому противоположное. Больше гибкости всегда лучше, чем меньше гибкости. Больше удобства всегда лучше, чем меньше удобства. Понятия гибкости и удобства антиколлинеарны и каждый сам для себя решает. Но они при этом неравноправны. Если гибкости недостаточно, ты ничего не сделаешь, чтобы это исправить, если недостаточно удобства, ты легко его себе сможешь обеспечить. Вывод? ИМХО риторический вопрос.

Добавлено 23.04.21, 12:27

Цитата scrambrella @ 22.04.21, 21:03

В QT реализованы наиболее употребляемые контейнеры STL. В ряде случаев они более удобные. В QVector есть метод fill - заполнить заданным значением. В std::vector его нет.
Портирование с STL на QT осуществляется всего лишь заменой имени класса контейнера, так как есть дублирующие методы с названиями из STL.

Да ну. std::fill В языке с 1998 года. Работает с любым контейнером и не только контейнером, была бы пара итераторов. "Алгоритмы + структуры данных" ©. А что там у QT со срезом по контейнеру? Он умеет заполнять диапазон, определённому мною как предикат?
А мне вот понадобился ассоциативный массив с отображением на кортеж «нитка + фючерс с обещанием + композиция лямбд» по... та неважно, по какому ключу, пусть будет некий абстрактный class id . Ну-ка, набросай на QT, я посмотрю.

Сообщение отредактировано: Qraizer - 23.04.21, 12:35

[shm]

Цитата Qraizer @ 23.04.21, 12:16

Попробуй реализовать простую модель "много писателей/много читателей" с приоритетом у писателей и взаимным неблокированием читателей.

Что есть "с приоритетом у писателей"? Эта фраза мне мало о чем говорит. И в чем практический смысл такого приоритета? Собственно, эффективную (без пробуждения всех читателей при записи) и простую (сопоставимую по сложности с CV) реализацию писателей-читателей (можно без приоритетов) на евентах я бы тоже хотел увидеть.

Цитата Qraizer @ 23.04.21, 12:16

На pthread запаришься программить условные переменные и как следствие отлаживать их на дидлоках

А какие с CV дедлоки? Там есть ложные пробуждения, но это не так страшно, как обратная ситуация с Event'ами. И cv в подавляющем большинстве случаев хватает одной, чего не скажешь о event'а.

Цитата Qraizer @ 23.04.21, 12:16

, а SignalObjectAndWait() шутка иногда полезная ибо атомарная

Она нифига не атомарная на SMP системах, о чем у них и написано в документации. MS думают даже не на шаг вперед, а на пол шага. Оттуда и зоопарк фукций с разными приставками и суффиксами.

Цитата Qraizer @ 23.04.21, 12:16

И это я даже ещё не упомянул модель прав и аудита, без которой ни один ядерный объект, не исключая объекты синхронизации, не обходится и посредством которого высокопривилегированные процессы могут создавать правила взаимодействия процессов в разных сессиях и даже на разных рабочих станциях. Включая как физически разные компьютеры, так и разные WindowStation одного конкретного компьютера. И не надо тут про аналоги в правах доступа и допAPI системных процессов в лине, они и рядом не валялись по гибкости. Вы просто не умеете готовить безопасность в WinAPI. Это не наезд, это сожаление. Как жаль бывает человека, которому показали формулы в Экселе, но забыли рассказать о макросах.

Скольким разработчикам этот функционал нужен? 0.1% наберется?

Цитата Qraizer @ 23.04.21, 12:16

Но вообще, ты вот серьёзно думаешь, что WinAPI – это экспорт kernel32, user32 и gdi32? А как же advapi32?

Нет. Где я об этом писал?

Цитата Qraizer @ 23.04.21, 12:16

Ну, и как тут сравнивать с POSIX с его жалким man-ом, iOS, Андроидом и чем там ещё?

У POSIX можно открыть исходники и понять как оно реализовано, что ни скажешь о API MS. Кстати, с документацией я тоже проблем не испытывал.

Цитата Qraizer @ 23.04.21, 12:16

Далекому будет понятно одно, недалёкому противоположное. Больше гибкости всегда лучше, чем меньше гибкости. Больше удобства всегда лучше, чем меньше удобства. Понятия гибкости и удобства антиколлинеарны и каждый сам для себя решает. Но они при этом неравноправны. Если гибкости недостаточно, ты ничего не сделаешь, чтобы это исправить, если недостаточно удобства, ты легко его себе сможешь обеспечить. Вывод? ИМХО риторический вопрос.

Да причем тут гибкость? Адекватно вообще пихать столько аргументов в одну функцию?

ЗЫ: я раньше тоже был сторонником WinApi. Пока серьезно не занялся осдевом (как хобби) и не понял внутренне устройство ОС. После этого мои взгляды резко изменились.

Сообщение отредактировано: shm - 23.04.21, 16:41

[amk]

Цитата Alexandrietz @ 21.04.21, 20:27

Думаю, что людей, кроме Кнута, осиливших трехтомник, нет.

Если считать и то, что в интернете, то уже четырёхтомник.

Ничего сложного в трёхтомнике, что мешало юы нго освоить, не заметил. Ни при первом чтении (первое издание), ни при втором (последнее)

[shm]

И кстати, если модель синхронизации винды так прекрасна, то почему те же евенты не добавили в c++? Только не надо говорить, что "потому что их нет в ядре nix": там они тривиально реализуются на фьютексах. А причина, насколько я знаю, в том, что в комитете справедливо решили, что Event'ы очень часто порождают весьма не очевидные баги в синхронизации. Поэтому добавили CV.

Сообщение отредактировано: shm - 23.04.21, 13:11

[scrambrella]

Цитата Qraizer @ 23.04.21, 12:16

А что там у QT со срезом по контейнеру? Он умеет заполнять диапазон, определённому мною как предикат?

В цикле пробежаться, реализовав предикат на if-ах. А как на STL и чем это круто?

Добавлено 23.04.21, 13:51

Цитата Qraizer @ 23.04.21, 12:16

А мне вот понадобился ассоциативный массив с отображением на кортеж «нитка + фючерс с обещанием + композиция лямбд» по... та неважно, по какому ключу, пусть будет некий абстрактный class id . Ну-ка, набросай на QT, я посмотрю.

???
А если по-русски?

Сообщение отредактировано: scrambrella - 23.04.21, 13:51

[ЫукпШ]

Цитата shm @ 23.04.21, 13:02

И кстати, если модель синхронизации винды так прекрасна, то почему те же евенты не добавили в c++?

Это сразу можно объяснить.
Потому, что с++ - универсальный язык программирования.
Его можно использовать для Win, *nix, микроконтроллеров
(на голом процессоре) и любых других системах.
Конкретные объекты синхронихации - это принадлежность
системы. Реализация делается для конкретной системы.
---
А вот где у *nix множественное ожидание (ожидание множества объектов) - это Вопрос.
Лудить можно любые костыли, но системой то это не предусмотрено.

Сообщение отредактировано: ЫукпШ - 23.04.21, 14:52

[shm]

Цитата ЫукпШ @ 23.04.21, 14:52

А вот где у *nix множественное ожидание (ожидание множества объектов) - это Вопрос.

Его не сложно реализовать (https://github.com/neosmart/pevents/blob/ma...src/pevents.cpp - один из множества примеров), но будет не так эффективно. С другой стороны, если говорить WaitForMutlipleObject, то вещь это специфическая и для приложений с большой нагрузкой ввода-вывода малополезная (прежде всего сервера): там используются те же очереди на IOCP/epoll. Почему? Все просто: эта функция ограничена 64 объектами ожидания на поток (причем преодолеть это ограничение технически MS не может и на то есть объективные причины), что ставит крест на масштабируемости. Поэтому область ее применения все же не высоконагруженные приложения, где не так много объектов за которыми нужно следить, а в этом случае сложно увидеть разницу в производительности по сравнению с той же реализация на CV (ну проснутся потоки лишний раз и опять уснут, катастрофы нет).

Добавлено 23.04.21, 16:35

Цитата

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

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

Сообщение отредактировано: shm - 23.04.21, 16:36

[OpenGL]

Цитата Qraizer @ 23.04.21, 12:16

И не надо тут про аналоги в правах доступа и допAPI системных процессов в лине, они и рядом не валялись по гибкости.

Вот только почему-то такая штука как docker в лине есть нативно с его стрёмной системой прав, в винде же он надстройка над hyper-v. Без виртуализации, видимо, никак не сделать в столь гибкой системе.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

[ЫукпШ]

Цитата shm @ 23.04.21, 16:26

Стандартная библиотека на голом железе работать не будет.

Почему это вдруг ?
Работает же. Вчера пробовал.
Дать более точное определение я могу попробовать.
---
язык программирования не связан ни с какой платформой.
Именно поэтому исходники для Win (иди DOS) могут
без изменений собираться для *niх.
Если не требуется использовать системные объекты.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

[shm]

Цитата ЫукпШ @ 23.04.21, 20:05

Работает же. Вчера пробовал.

Т.е. я могу собрать бинарь под какой-нибудь голвый stm (без ОС) и написать в нем что-то подобное:

std::thread th({
    std::cout << "Hello world!" ;
});
th.join();

и оно заработает?

Добавлено 23.04.21, 20:18

Цитата ЫукпШ @ 23.04.21, 20:05

язык программирования не связан ни с какой платформой.
Именно поэтому исходники для Win (иди DOS) могут
без изменений собираться для *niх.
Если не требуется использовать системные объекты.

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

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Сообщение отредактировано: shm - 01.05.21, 22:37

[ЫукпШ]

Цитата shm @ 23.04.21, 20:16

Цитата ЫукпШ @ 23.04.21, 20:05

Работает же. Вчера пробовал.

Т.е. я могу собрать бинарь под какой-нибудь голвый stm (без ОС) и написать в нем что-то подобное:

std::thread th({
    std::cout << "Hello world!" ;
});
th.join();

и оно заработает?

А почему нет ?
Реализацией библиотеки занимаются разработчики компилятора.
И они сделают "как надо", не сомневайся.
---
Вот именно это я не пробовал. (Делал printf).
Но этот класс использует (наверняка) putchar.
Так что всё заработает.
Более того, компилер для микроконтроллеров
допускает (я такое сам делал) замену стандартного putchar
на твой собственный. А это значит, вывод будет куда захочется.
В EEPROM, например. Или припаянный лично тобой дисплей.
---
В классе "cout" нет ничего особенно волшебного или запредельно сложного.
Недавно в некотором проекте мне захотелось, чтобы вывод был не только в консоль,
а куда я захочу (или никуда) Тогда я написал класс MyCout. И реализовал
только те возможности, которые мне были необходимы. Только теперь этот класс
писал не в консоль, а в интерфейс. Таким образом, меняя объект-реализацию интерфейса
можно менять вывод по своему усмотрению.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Сообщение отредактировано: ЫукпШ - 01.05.21, 22:37

[scrambrella]

Цитата OpenGL @ 23.04.21, 19:26

Вот только почему-то такая штука как docker в лине есть нативно

Приблуды типа Docker/Kubernetes - это результат того, что программисты стремительно теряют поле для деятельности. Все программы, нужные людям, написаны. Чтоб не потерять работу программисты выдумывают как бы более прогрессивные технологии разработки - DevOps, CI, CD и т.д. и т.п. В результате открывается огромное поле: перевод программ на Docker, обучение Docker-у, обучение DevOps/CI/CD/SCRUM/Kanban и т.д. и т.п. Программист становится паразитом в обществе, который ничего не производит, однако имитирует работу и требует одну из самых высоких зарплат.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

[shm]

Цитата ЫукпШ @ 23.04.21, 20:27

Вот именно это я не пробовал. (Делал printf).
Но этот класс использует (наверняка) putchar.
Так что всё заработает.
Более того, компилер для микроконтроллеров
допускает (я такое сам делал) замену стандартного putchar
на твой собственный. А это значит, вывод будет куда захочется.
В EEPROM, например. Или припаянный лично тобой дисплей.
---
В классе "cout" нет ничего особенно волшебного или запредельно сложного.
Недавно в некотором проекте мне захотелось, чтобы вывод был не только в консоль,
а куда я захочу (или никуда) Тогда я написал класс MyCout. И реализовал
только те возможности, которые мне были необходимы. Только теперь этот класс
писал не в консоль, а в интерфейс. Таким образом, меняя объект-реализацию интерфейса
можно менять вывод по своему усмотрению.

Нет, ты не понял: printf и cout меня совсем не интересуют. Мне хочется, чтобы именно std::thread заработал как в примере. По поводу printf - так я верю, что разработчики чипа осили отправку байт в uart и сделали это в виде отдельной библиотеки, которая, вероятно, даже идёт с компилятором.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"