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

Читаем 3 книги!

Саммерфилд QT4 Программирование GUI на С++
Бьерн Страуструп Язык программирования С++
М.Грабер SQL

Книги по С++ взаимозаменяемы.

Web-языки (Прохоренок Н.А. HTML, JavaScript, PHP и MySQ) - по желанию.


Ассемблер - нахер. Стандартную библиотеку - нахер (QT её заменяет).

Кормен Т. Алгоритмы: построение и анализ - нахер. Написано ужасно, непонятно ничего. Быстрее сам придумаешь алгоритм, чем поймёшь что имел в виду Кормен.

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

Цитата scrambrella @ 21.04.21, 09:08

Стандартную библиотеку - нахер (QT её заменяет).

QT – не C++.

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

Такое ощущение, что боты между собой общаются.

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

Цитата Qraizer @ 21.04.21, 09:23

QT – не C++.

Как предложите писать графические проги на С++ кроме как с помощью QT ?

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

Цитата shm @ 21.04.21, 11:13

Такое ощущение, что боты между собой общаются.

Такое ощущение, шо Циана Куль воскрес.

Ряд вопросов по терминологии C++

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

Цитата scrambrella @ 21.04.21, 11:34

Как предложите писать графические проги на С++ кроме как с помощью QT ?

Какое это имеет отношение к совету не использовать стандартную библиотеку? QT вяжет по рукам и ногам своей инфраструктурой. Это отдельный фреймворк, использующий кастрированный C++ в качестве бак-энда. Давай ещё посоветуй кому-нить использовать Delphi в режиме Object Pascal.

Добавлено 21.04.21, 14:40

Цитата DrUnkard @ 21.04.21, 13:02

Такое ощущение, шо Циана Куль воскрес.

Тьфу-тьфу-тьфу, но разница невелика.

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

Цитата scrambrella @ 21.04.21, 09:08

Читаем 3 книги!

Саммерфилд QT4 Программирование GUI на С++
Бьерн Страуструп Язык программирования С++
М.Грабер SQL

Книги по С++ взаимозаменяемы.

Web-языки (Прохоренок Н.А. HTML, JavaScript, PHP и MySQ) - по желанию.


Ассемблер - нахер. Стандартную библиотеку - нахер (QT её заменяет).

Кормен Т. Алгоритмы: построение и анализ - нахер. Написано ужасно, непонятно ничего. Быстрее сам придумаешь алгоритм, чем поймёшь что имел в виду Кормен.

Хорошо. Давайте допустим, что я прочитал эти книги. Выучил все структуры данных, алгоритмы по Кормену, исключения выучил, констркуторы, STL. А как написать проект, который убедит того, кто будет принимать меня работу, что я не овощ в С++?

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

Алгоритмы учим по Кнуту, пропуская математику, которой там много. Кормен - отстой.

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

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

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

Цитата scrambrella @ 21.04.21, 20:13

Алгоритмы учим по Кнуту, пропуская математику, которой там много. Кормен - отстой.

Проекты ваши никто смотреть не будет. Спросят базовые алгоритмы. Проверят знание языка программирования.

Трехтомник Кнута я точно не осилю. А сколько хватит для программирования?

Добавлено 21.04.21, 20:37

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

Цитата scrambrella @ 21.04.21, 20:13

Алгоритмы учим по Кнуту, пропуская математику, которой там много. Кормен - отстой.

Проекты ваши никто смотреть не будет. Спросят базовые алгоритмы. Проверят знание языка программирования.

Трехтомник Кнута я точно не осилю. А сколько хватит для программирования?

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

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

Цитата Qraizer @ 21.04.21, 14:40

Цитата scrambrella @ 21.04.21, 11:34

Как предложите писать графические проги на С++ кроме как с помощью QT ?

Какое это имеет отношение к совету не использовать стандартную библиотеку? QT вяжет по рукам и ногам своей инфраструктурой. Это отдельный фреймворк, использующий кастрированный C++ в качестве бак-энда. Давай ещё посоветуй кому-нить использовать Delphi в режиме Object Pascal.

Добавлено 21.04.21, 14:40

Цитата DrUnkard @ 21.04.21, 13:02

Такое ощущение, шо Циана Куль воскрес.

Тьфу-тьфу-тьфу, но разница невелика.

Что есть в STL чего нет в QT?
Контейнеры QT
QT как фреймыворк применять вы не обязаны. Можно взять только контейнеры. А понадобится GUI - вот вам GUI, а не censored WINAPI.

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

Сообщение отредактировано: Qraizer - 22.04.21, 11:49

WinAPI является одним из лучших ОС API в мире. Объём его документации превышает таковой для любых других API вместе взятых, количество аспектов, охватываемых WinAPI, от безопасности и криптографии до робастности 24/7 приложений, сравним с суммой аспектов остальных API вместе взятых, и то при условии навешивания поверх них ассетов сторонней разработки. Неудивительно, что регулярно попадаются неосилившие его индивидуумы.
Графический API операционных систем семейства Windows является самым гибким графическим API в мире. Имея в своей основе процедурный подход, он требует от программиста серьёзных усилий для вхождения, это оборотная сторона медали. Личное дело каждого выбрать: простота или гибкость. Любой фрейморк для Windows способен покрыть лишь некоторый срез графического API. И зачастую он весьма невелик: чуть в сторону, и никуда от API не деться.
Фреймворки выбирают обычно из-за простоты в ущерб гибкости, когда последняя невосстребована. Что до конкретно QT, его выбирают из-за кроссплатформенности, а не простоты. Кто пробовал писать под *никсы, сами могут рассказать, каково там писать графические приложения в условиях кучи графических морд их ОСей.

M

И снова спрашиваю: какое это имеет отношение в тезису о ненужности стандартной библиотеки C++? Третий раз повторять вопрос не буду, просто вкачу за флуд.

Добавлено 22.04.21, 18:10

Цитата scrambrella @ 22.04.21, 09:20

QT как фреймыворк применять вы не обязаны. Можно взять только контейнеры.

Пф.
C++ Standard Library headers
Qt Core
Что-то я вижу там кучу классов... которые мапятся буквально на десяток аспектов. Серьёзно? И ради этого мне предлагается тащить в приложение библиотек на десятки мегабайт? Спасибо, обойдусь.

Сообщение отредактировано: Qraizer - 22.04.21, 18:16

Цитата Qraizer @ 22.04.21, 18:06

WinAPI является одним из лучших ОС API в мире.

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

Цитата Qraizer @ 22.04.21, 18:06

Графический API операционных систем семейства Windows является самым гибким графическим API в мире.

Жирно. Даже очень. Даже далекому от WinAPI человеку стоит просто взглянуть на ту же CreateWindowEx и все становится понятно. Видимо из-за "удобности" этой графической подсистемы добрая половина десктопоного ПО (причем иногда той же MS)сейчас рендерит пользовательский интерфейс на web-движке, не редко даже вставляют прямо хромиум целиком. И опять же тот же Qt что-то отличное от примитивной кнопки рендерит через OGL.

Цитата Qraizer @ 22.04.21, 18:06

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

В линухе с созданием морд ещё хуже чем в винде. Если надо чтоб работало и там и там осваивать QT придётся неизбежно.

Добавлено 22.04.21, 21:11

Цитата Qraizer @ 22.04.21, 18:06

Qt Core
Что-то я вижу там кучу классов... которые мапятся буквально на десяток аспектов. Серьёзно? И ради этого мне предлагается тащить в приложение библиотек на десятки мегабайт? Спасибо, обойдусь.

Мегабайты сегодня не экономят.

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

Добавлено 22.04.21, 21:20
Нативные сеть и потоки это полный ад, независимо от ОС. Писать нативный код на C++ качественно и быстро практически не реально.

Alexandrietz

Цитата

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

Увы, даже он сам не осилил одно из упражнений.
Он его оценивал в 50 баллов, а когда Уайлс справился - изменил на 45.

Сообщение отредактировано: MBo - 23.04.21, 04:29

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

Не смог сдержаться. На мой взгляд WinAPI - это как раз таки пример как не надо делать api.

Сравнение было бы очень уместно.
я попробовал и Win, и Linuх.
Так вот, WinApi смастерили с учётом возможности
программирования с объектами, т.е. для C++.
А nix Api - это для C.
Почувствуйте разницу, она принципиальна.
Эта разница неизбежно проявится в производительности труда
и в общем качестве работ.

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

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

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

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

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

Цитата 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

Цитата 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

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

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

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

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

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

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

Цитата 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

Цитата ЫукпШ @ 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

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

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

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

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

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

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

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

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

Цитата ЫукпШ @ 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

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

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

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

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

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

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

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

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

Цитата scrambrella @ 19.04.21, 16:01

1) Страуструп - чисто по С++
2) Фреймворк QT 5
3) Кнут. Искусство программирования. - по всем остальным вопросам

А Лафоре норм?

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

Цитата Alexandrietz @ 24.04.21, 13:55

А Лафоре норм?

Это кто?

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

Цитата scrambrella @ 26.04.21, 07:23

Цитата Alexandrietz @ 24.04.21, 13:55

А Лафоре норм?

Это кто?

Книга по С++ от Роберта Лафоре. У него еще вроде по Питону есть. Есть еще Шильдт, Липманн, Страуступ(но для нуба она тяжелая)

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

Цитата shm @ 23.04.21, 12:40

Что есть "с приоритетом у писателей"? Эта фраза мне мало о чем говорит. И в чем практический смысл такого приоритета?

В том, что перед записью нужно захватить ресурс монопольно, и следовательно читатели должны его держать, когда они есть, и отпускать, когда ни один из них не держит ресурс, но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют. В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества. Серьёзно? Мне пришлось это написать?
С одним писателем достаточно двух объектов синхронизации и по одному API-вызову на входе/выходе в/из КС со стороны читателей и по два для писателя. В ситуации с несколькими писателями дело усложняется.

Цитата shm @ 23.04.21, 12:40

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

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

Цитата shm @ 23.04.21, 12:40

А какие с CV дедлоки? Там есть ложные пробуждения, но это не так страшно, как обратная ситуация с Event'ами.

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

Цитата shm @ 23.04.21, 12:40

И cv в подавляющем большинстве случаев хватает одной, чего не скажешь о event'а.

И это абсолютно неважно, когда речь идёт о скорости и стоимости выхода в стадию продакнша.

Цитата shm @ 23.04.21, 12:40

Она нифига не атомарная на SMP системах, о чем у них и написано в документации.

Она выполняется ровно так, как описано. Пробуждение другой нити перед вызвавшей SignalObjectAndWait() суть нормальное явление, ибо для объектов синхронизации все ожидающие нитки равноправны. Такова их архитектура. Ничего не поменялось бы, если б сигнализирующий объект переводился бы в сигнальное состояние после того, как вызывающая SignalObjectAndWait() нитка реально вошла б режим ожидания. Всё равно при наличии нескольких ожидающий проснуться может любая, и решает это планировшик потоков. То, что написано в документации как предупреждение, суть просто напоминание, фактически ему там делать нечего, просто Note для забывчивых. Я ж говорю, мат.часть надо знать.
Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.

Цитата shm @ 23.04.21, 12:40

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

Всем, кто пишет сервисы. Таковых много? Я не знаю. Но без этого функционала они связаны по рукам и ногам.
Просто посмотри, например, на такую ситуацию: ты пишешь код обновления своего ПО, которое может эксплуатироваться одновременно под разными учётками в терминальных сессиях или даже просто под fast user switch, и тебе нужно сделать это правильно, т.е. выгрузив все свои экземпляры и после обновления загрузить снова, не потеряв при этом данных пользователей, которые вот прям счас с твоим ПО активно работают, а главное – не быть уязвимым к злонамеренным атакам, посредством фэйковых служебных пакетов саботирующих работу твоего ПО. Конечно, это вполне себе решается и в POSIX, но насколько это проще, безопаснее и быстрее решается в WinAPI, лично я могу сравнивать. Там тебе всё готовое уже. Даже журналирование стандартизировано, что легко автоматизирует множество административных задач, на которых уже построена значительная часть корпоративной инфраструктуры твоей компании, и встроить туда ещё один объект аудита занимает пару минут. На рубеже прошлых десятилетий мне пришлось плотно окунуться в сферу сервисов и security API. Если заглянешь в раздел WinAPI у нас, то я отметился, пожалуй, в каждой теме по сервисам. Правда, о security вопросов там, вроде бы, не было.

Цитата shm @ 23.04.21, 12:40

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

Этот аргумент не просто ни разу не аргумент, а никогда им и не был. Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.
Для сравнения могу предложить такую задачку. В Холиварах никто не захотел задуматься, предлагаю задуматься тут. Чтоб не отправлять по ссылке, сцитачу сюда:

Цитата Qraizer @ 14.04.21, 11:11

В документации сказано: «функция void sort(int *vec, size_t size) должна выполнять сортировку массива vec, размером size. Сортировка осуществляется по возрастанию, результат замещает исходный vec.» Требуется разработать набор тестовых сценариев для проверки этого требования. Естественно так, чтобы их можно было рассматривать как доказательную базу корректности реализации sort() согласно описанию её поведения.

Поначалу может показаться, что это некая ересь, как можно что-то тестировать глубже, чем интуитивно потыкать по кнопкам, не зная, как оно устроено, а тут аж доказательную базу хотят. Но немного подумав, внезапно окажется, что алгоритм и сырцы для этого без надобности от слова совсем. Мы знаем, как должна вести себя эта функция. Мы можем однозначно определить, каким должен быть её результат по абсолютно любому набору входов. Что ещё надо-то? Качество документации — вот главный пасс-критерий качества кода, и его реально достаточно.
Это, конечно, простой пример, потому что мы все прекрасно знаем, что такое сортировка, но а чем качественно-то отличается любая другая функция от этой? Риторический вопрос. В общем, забудьте и больше никогда не вспоминайте о тезисе, что открытый код якобы надёжней, потому что в него всегда можно заглянуть. Это миф.

Цитата shm @ 23.04.21, 12:40

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

Напиши прокси для своих более узкоспециализированных нужд. Собственно любой фрейморк именно это тебе и делает, и выбирая фреймворк, ты не более чем выбираешь комплект сужений имеющейся изначально гибкости. Это же возможно? А как иначе, при таком-то количестве наблюдаемых фреймворков. Это было бы возможно без изначально спроектированной и реализованной гибкости? Отнюдь не факт, всё зависит от потребностей. Вот нет в POSIX гибкой системы секьюрити и межпроцессного взаимодействия, приходится юзать богомерзкие сокеты, проектировать, программировать и отлаживать свои протоколы, строить вокруг него стену из файрвола и правил фильтрации портов и адресов. Ну ок, это ваш выбор. Точнее, вашей ОСи. Ещё точнее – вашего API. Так что наблюдаемое разнообразие фреймворков над WinAPI говорит лишь за то, что я прав. И именно благодаря гибкости WinAPI у вас богатый выбор проксей над ним.

Цитата shm @ 23.04.21, 12:40

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

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

Добавлено 30.04.21, 22:12

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

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

Нет, в Комитете решили, что на этот момент существует уже слишком много доСтандартных решений, и так будет гораздо проще рефакторить много легаси. А почему их много, думаю, объяснять не надо: проще было с...лямзить готовый и открытый pthread, чем писать и отлаживать свои самокаты.

Добавлено 30.04.21, 22:32

Цитата scrambrella @ 23.04.21, 13:50

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

Пробежаться в цикле тебе и без QVector::fill() было бы несложно, согласись, но коли речь зашла за сервисные функции и методы, то речь идёт об обобщённой задаче, ибо на каждую хотелку методов не напасёшься. Например

std::replace_if(db.begin(), db.end(), [](auto i) { return i % 7 == 4; }, 0);

зануляет все, которые при делении на 7 дают в остатке 4. При этом db может быть чем угодно, лишь бы поддерживало модель контейнер+итераторы, и предикат пиши сам, какой нужен. А ещё первым параметром можно указать политику параллельного исполнения, типа там std::execution::parallel_policy, и если в твоей библиотеке оно реализовано, то ок. Ну, не реализовано, ну и ладно, а у кого-то реализовано, и этот код получит профит. Наверно, получит профит... слишком простая задача. Но ведь и гораздо сложнее бывают.

Цитата scrambrella @ 23.04.21, 13:50

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

Эм... забей. Слишком много писать объяснений для того, на что ответ я и так представляю.

Добавлено 30.04.21, 22:44

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

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

Так её и не используют на высоких нагрузках. Так-то для этого уже мульён лет другие объекты синхронизации предназначены. А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):

HANDLE evAllowReaders = CreateEvent(NULL, TRUE, TRUE, NULL);
HANDLE mtExclusived   = CreateMutex(NULL, FALSE, NULL);
HANDLE rdLock[] = { evAllowReaders, mtExclusived };
 
// читатели
WaitForMultipleObjects(2, rdLock, TRUE, INFINITE);
/* бла-бла-бла */
ReleaseMutex(mtExclusived);
 
// писатель
ResetEvent(evAllowReaders);
WaitForSingleObject(mtExclusived);
/* бла-бла-бла */
SetEvent(evAllowReaders);
ReleaseMutex(mtExclusived);

Добавлено 30.04.21, 22:47

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

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

А причём тут права?

Добавлено 30.04.21, 22:50

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

Недавно в некотором проекте мне захотелось, чтобы вывод был не только в консоль,
а куда я захочу (или никуда) Тогда я написал класс MyCout. И реализовал
только те возможности, которые мне были необходимы. Только теперь этот класс
писал не в консоль, а в интерфейс.

А зачем было себя ограничивать в интерфейсе, если можно просто написать потомка std::basic_streambuf<> и перекрыть несколько виртуальных методов? И пиши себе стандартными классами хоть в сокеты, хоть в COM:, куда там ты напрограмишь в методах.

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

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

Цитата Qraizer @ 30.04.21, 22:08

но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют

Как не меняют-то? Типа извлечение элемента из очереди это "не меняют"?

Цитата Qraizer @ 30.04.21, 22:08

В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества.

Если программист идиот, то он может и сделать 100500 потоков-читателей, а также сделать множество других глупостей. На практике крайне редко имеет смысл их создавать больше, чем количество логических процессоров.

Цитата Qraizer @ 30.04.21, 22:08

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

Да вот нифига. Сами мелкомягкие не дают адекватного решения на событиях с автосбросом. И призывают использовать iocp, или, внезапно, cv Пруф, разумеется, будет.

Цитата Qraizer @ 30.04.21, 22:08

Такие, что ты сам их пишешь и сам же управляешь потоками событий по ним.

Не понял аргумента вообще.

Цитата Qraizer @ 30.04.21, 22:08

Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.

Это понятно, но...

Цитата

Use extreme caution when using SignalObjectAndWait and PulseEvent with Windows 7, since using these APIs among multiple threads can cause an application to deadlock. Threads that are signaled by SignalObjectAndWait call PulseEvent to signal the waiting object of the SignalObjectAndWait call. In some circumstances, the caller of SignalObjectAndWait can't receive signal state of the waiting object in time, causing a deadlock.

Очевидно, что в SMP системах профит от нее намного меньше. И в отличие от фьютексов функция непригодна для user-mode примитивов синхронизации.

Цитата Qraizer @ 30.04.21, 22:08

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

Про бизнес очень сомнительные утверждения.

Цитата Qraizer @ 30.04.21, 22:08

Правда, о security вопросов там, вроде бы, не было.

Вот вот...

Цитата Qraizer @ 30.04.21, 22:08

Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.

Ты пытаешься натянуть сову на глобус. Юридические аспекты в этом вопросе лично меня мало волнуют. Для отдельных отраслей есть специальные дистрибутивы linux'а, где много чего гарантируется и документировано. По факту там просто деньги отмыли на этом, но это разговор для другой темы.

Цитата Qraizer @ 30.04.21, 22:08

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

Я нигде не писал о надежности, я писал о кривости архитектуры, что не одно и тоже. На кривой архитектуре можно вполне построить работоспособное приложение.

Цитата Qraizer @ 30.04.21, 22:08

А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):

Спасибо, капитан!

Скрытый текст

Аналог этой функции для своей игрушечной ОС я написал еще будучи студентом младших курсов

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

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

Цитата shm @ 01.05.21, 12:58

Как не меняют-то? Типа извлечение элемента из очереди это "не меняют"?

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

Цитата shm @ 01.05.21, 12:58

Если программист идиот, то он может и сделать 100500 потоков-читателей, а также сделать множество других глупостей.

Или 100500 коннектов к онлайн-магазину. Вот только не надо тут, что на API мол такого не пишут. Ага.

Цитата shm @ 01.05.21, 12:58

Пруф, разумеется, будет.

Пруф чего? Того, как доC++11легаси, разработанный под WinAPI, переделать под std? А что ещё ты там вычитал? Ах да, ты ж написал, что.
Ну, молодец он, что могу сказать. Хорошая статья для чьего-нибудь FAQ-а. Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std. К тому же нет путаницы с названиями классов и интуитивным их пониманием, к которой в std нужно привыкнуть. А уж CV просто жуть. Я-то надеялся, что их поправят под что-то более удобоваримое, как-никак 21-ый век 10 лет уж как шагает по миру. Но нет, как были неудобным фуфлом в pthread, так им и остались.

Цитата shm @ 01.05.21, 12:58

Очевидно, что в SMP системах профит от нее намного меньше.

И снова просто note, эта фраза явным образом следует из... Я как будто и не писал выше о Рихтере, да? Его советы по недопущению дидлуков никем не читаны, да? Ну да фиг с ним, с Рихтером, как вы вообще тогда CV пишете, без знания теории? ...пожалуй, я не буду комментировать мат.часть. Ну вот как нет желания объяснять, почему, например, к std::string_view нельзя относиться так же, как к std::string. Джуну надо целый курс лекций читать, а профи и так знает.

Цитата shm @ 01.05.21, 12:58

Ты пытаешься натянуть сову на глобус. Юридические аспекты в этом вопросе лично меня мало волнуют

Опять троллишь? Причём тут юриспруденция? Речь о корректно поставленном бизнес-процессе. Который корректно поставлен, благодаря полноте и качеству документации. Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?

Цитата shm @ 01.05.21, 12:58

Спасибо, капитан!

Зачем тогда IO приплетал? Всё-таки троллишь? Ну ок, тогда до свиданья. Поехали!

Сообщения были разделены в тему "WinAPI и POSIX"

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

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

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

M

Флудите на здоровье!

Цитата Qraizer @ 30.04.21, 22:08

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

И где же винда правит крупным бизнесом?

Цитата Qraizer @ 01.05.21, 22:24

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

И что ты предлагаешь? Lock-free queue? Давай без загадок. К тому же про высоконагруженную области я не писал в контексте блокирующей очереди.

Цитата Qraizer @ 01.05.21, 22:24

Или 100500 коннектов к онлайн-магазину.

Ещё кто-то создаёт по потоку на соединение?

Цитата Qraizer @ 01.05.21, 22:24

Пруф чего?

Ты статью читал? Судя по всему, только заголовок. Ок, мой изначальный вопрос в силе: хочу увидеть реализацию блокирующей очереди (несколько писателей - читателей) на событии с автосбросом. Ты же сам сказал, что это проще, чем с cv. Я могу сразу прогнать тесты.

Скрытый текст

все простые реализации на event'ах, которые я тестировал, с треском проигрывают решениям на cv по производительности

Цитата Qraizer @ 01.05.21, 22:24

Ну да фиг с ним, с Рихтером, как вы вообще тогда CV пишете, без знания теории

Откуда такие выводы? Если уж на то пошло, то Рихтер - это ни разу не теория. Теория - этот тот же Таненбаум.

Цитата Qraizer @ 01.05.21, 22:24

Джуну надо целый курс лекций читать, а профи и так знает.

Ммм. Кто-то страницу назад доказывал, что с евентами все просто, а cv одни дэдлоки. А вот оно как... И про smp я не зря говорю, что там может произойти с состоянием эвента (особенно с ручным сбросом) в момент SignalObjectAndWait? А ведь большая часть программистов вообще плохо понимает как оно там устроено в ядре на smp-системах.

Цитата Qraizer @ 01.05.21, 22:24

Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?

А с чего ты взял, что:
1. ваши производственные процессы идеальны?
2. Им нужно следовать в других компаниях (других отраслей и направленности)?
И вообще это оффтоп.

Цитата Qraizer @ 01.05.21, 22:24

Зачем тогда IO приплетал? Всё-таки троллишь? Ну ок, тогда до свиданья. Поехали!

Ты серьезно думаешь, что я не знаю как работает waitformultipleobjects? По моему троллишь как раз ты. Давно мог дать ссылку на простую (проще чем на cv) и эффективную реализацию очереди на евентах... Тогда бы вопрос был исчерпан.

Если самолёты управляются софтом на windows, то мне страшно.

По поводу крупного бизнеса нужны пруфы. Насколько мне известно, там мало windows.

По поводу сравнения с POSIX. Не очень понятно, зачем сравнивать конкретную ОС со стандартом, под который попадает очень широкий спектр ОС. А если рассмотрим частичную совместимость, так вообще большая часть существующих ОС.
Можно взять конкретный linux, например, и сравнивать, будет более корректно.

Добавлено 02.05.21, 08:38

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

там используются те же очереди на IOCP/epoll

На io_uring не смотрел случаем?

Добавлено 02.05.21, 08:43

Цитата Qraizer @ 30.04.21, 22:08

Так её и не используют на высоких нагрузках.

А саму винду-то на высоких нагрузках кто-то использует? Насколько мне известно, по крайней мере на серверах, её довольно мало.

Добавлено 02.05.21, 09:06
Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность
Придется им повозиться с совместимостью, но по-моему тенденции последних изменений намекают на возможность такого перехода.

Добавлено 02.05.21, 09:10

Цитата D_KEY @ 02.05.21, 08:34

А саму винду-то на высоких нагрузках кто-то использует? Насколько мне известно, по крайней мере на серверах, её довольно мало.

Даже в Azure самая используемая ОС - Linux

Добавлено 02.05.21, 09:21

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

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

Ну справедливости ради, docker и основан на API линукса
Кстати, на POSIX голом никакой docker ты не сделаешь.

Ещё мне кажется, что в новых версиях винды таки смогли поддержать docker без виртуализации. WSL же, нет?

Цитата Qraizer @ 01.05.21, 22:24

Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std.

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Цитата Qraizer @ 22.04.21, 18:06

WinAPI является одним из лучших ОС API в мире. Объём его документации превышает таковой для любых других API вместе взятых, количество аспектов, охватываемых WinAPI, от безопасности и криптографии до робастности 24/7 приложений, сравним с суммой аспектов остальных API вместе взятых, и то при условии навешивания поверх них ассетов сторонней разработки.

В первый раз вижу, чтобы жирность расценивалась как преимущество. Есть, конечно, борцы сумо, но это скорее исключение, чем правило.

Добавлено 02.05.21, 11:36

Цитата D_KEY @ 02.05.21, 08:34

Ну справедливости ради, docker и основан на API линукса

Если под «основан» ты понимаешь «построен», то да. Иначе — нет. Основан он на (идеях из) API Plan 9.

Сообщение отредактировано: korvin - 02.05.21, 11:36

Цитата korvin @ 02.05.21, 11:34

Цитата D_KEY @ 02.05.21, 08:34

Ну справедливости ради, docker и основан на API линукса

Если под «основан» ты понимаешь «построен», то да.

Да, имел в виду "построен"

В Microsoft давно поняли, что на WINAPI программировать невозможно и создали C#.

Линь в плане графических прог вообще жопа. X, KDE, Gnome, чего там ещё, и под каждого свой API. Под линь QT вообще без вариантов. Ну или Жаба, если религия позволяет.

Сообщение отредактировано: scrambrella - 02.05.21, 18:07

Цитата shm @ 02.05.21, 05:38

К тому же про высоконагруженную области я не писал в контексте блокирующей очереди.

Зато писал я, упомянув 100500 читателей. Это ты так внимательно читаешь, что, даже ответив теми же 100500, не понял, что прочёл? Я ж предложил забить.

Цитата shm @ 02.05.21, 05:38

Ещё кто-то создаёт по потоку на соединение?

А причём тут потоки?

Цитата shm @ 02.05.21, 05:38

Ок, мой изначальный вопрос в силе: хочу увидеть реализацию блокирующей очереди (несколько писателей - читателей) на событии с автосбросом.

Для этого события с автосбросом не нужны. Серьёзно, забей, плз.

Цитата shm @ 02.05.21, 05:38

Кто-то страницу назад доказывал, что с евентами все просто, а cv одни дэдлоки. А вот оно как... И про smp я не зря говорю, что там может произойти с состоянием эвента (особенно с ручным сбросом) в момент SignalObjectAndWait? А ведь большая часть программистов вообще плохо понимает как оно там устроено в ядре на smp-системах.

Доказывал, что они более уязвимы, да. Как и любой код, писаный руками, вместо использования готовых отлаженных решений. И smp с этим никак не связано, а вот связано как раз с плохим представлением программеров, что не в последнюю очередь связано с нежеланием читать маны, потому что читать код гораздо интереснее.

Цитата shm @ 02.05.21, 05:38

1. ваши производственные процессы идеальны?

Я не говорил, что они наши. Хотя, вообще-то да, и наши тоже таковы. Я вообще говорил не за процессы, а за то, к каким результатам это ведёт, что и является причиной следования этим принципам везде, где не положить на риски. Если для тебя это не показатель качества процесса, то прости, что побеспокоил.

Цитата shm @ 02.05.21, 05:38

2. Им нужно следовать в других компаниях (других отраслей и направленности)?

Я не говорил, что им нужно обязательно следовать. Вот что я сказал, так это то, что сознательный отказ от них обозначается как ССЗБ. Видишь ли, если язык, скажем, не даёт тебе доступа к приватным сущностям класса, это не есть плохой язык, это у тебя странные желания.

Цитата shm @ 02.05.21, 05:38

Ты серьезно думаешь, что я не знаю как работает waitformultipleobjects?

Что не знаешь, как работает – не думаю. Думаю – что не знаешь, как и где его использовать. Это нормально, я на своём веку много раз думал, что отлично (неважно, о чём я; это и к Плюсам отнести можно, и к технологиям программирования, и к парадигмам, и к патернам проектирования, и многому ещё чему) знаю и умею, что освоил и неоднократно применял, но вот внезапно оказывалось, что я глубоко заблуждался, потому что уже вроде бы хорошо знакомое вдруг раскрывало свой потенциал куда масштабнее моих о нём представлений.

Цитата D_KEY @ 02.05.21, 08:34

Если самолёты управляются софтом на windows, то мне страшно.

Есть по меньше мере одна кампания, у которой изделия летают на софте под эмбеддед ОС, построенной на WinAPI. И эта компания является крупным подрядчиком хорошо вам известной, недавно некисло оскандалившеся, кампании государственного значения. Нет, винды на самолётах нет, она плохо портабельна на те могзи, которые там используются, а WinCE давно не поддерживается, но вот как раз у того подрядчика широко используются индустриальные камни Intel-а. В ходу больше ARM, PPC и кучи микроконтроллеров. Чем больше разных, тем лучше, потому что надёжнее, меньше зависимостей от аппаратных багов. Так-то там обычно если не самописное, то некое производное от POSIX. Это дешевле, т.к. код зачастую открыт, портировать недолго. Но фаза сертификации никуда не девается, и знаково дешевле всё равно не выходит. Так что да, деньги там ...хм, "отмываются" некислые.
Но вот где винды много, я бы даже сказал, где кроме неё ничего и нет, но побоюсь за всё и всех говорить, так это в процессах проектирования, создания, тестирования, верификации и сертификации. Я знаком с процессами трёх забугорных кампаний, две из которых упомянул, везде винда. За наши кампании, думаю, говорить излишне. Как думаешь, это крупный бизнес? Ему не наплевать на риски? Он предпочтёт выбирать решения по принципам надёжности и гарантиям или по сферическим проприетарность vs открытость?

Цитата D_KEY @ 02.05.21, 08:34

Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность

Этого не случится. Это никому не выгодно. Вообще никому.

Цитата korvin @ 02.05.21, 11:34

В первый раз вижу, чтобы жирность расценивалась как преимущество

И ты брут? Не жирность, а гибкость. Жирность – это std::basic_string<>, а вот <algorithm> – это гибкость.

Сообщение отредактировано: Qraizer - 02.05.21, 18:17

Цитата Qraizer @ 02.05.21, 18:13

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

Печально. Это связано с инструментами, консервативными взглядами, или еще с чем-то, на твой взгляд?

Цитата

Как думаешь, это крупный бизнес?

Не знаю.

Цитата

Ему не наплевать на риски? Он предпочтёт выбирать решения по принципам надёжности и гарантиям или по сферическим проприетарность vs открытость?

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Цитата

или по сферическим проприетарность vs открытость?

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

Цитата

Цитата D_KEY @ 02.05.21, 08:34

Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность

Этого не случится. Это никому не выгодно. Вообще никому.

MS вполне выгодно. Развитие WSL это показывает. Да и такие штуки, как windows terminal, winget и пр. так же показывают, что люди идут в сторону близких к *nix решений.

Добавлено 02.05.21, 18:30
И как показывают проекты в духе Proton от Valve, MS может относительно дешево отделаться в плане совместимости.

Но посмотрим, как оно дальше пойдет.

Сообщение отредактировано: D_KEY - 02.05.21, 18:32

Цитата D_KEY @ 02.05.21, 18:26

Цитата

Цитата D_KEY @ 02.05.21, 08:34

Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность

Этого не случится. Это никому не выгодно. Вообще никому.

MS вполне выгодно. Развитие WSL это показывает.

Вы ещё на Android переведите M$

Цитата

Да и такие штуки, как windows terminal, winget и пр. так же показывают, что люди идут в сторону близких к *nix решений.

Нормальным пользователям(не IT-гикам) линь даром не нужен.

Цитата Qraizer @ 02.05.21, 18:13

А причём тут потоки?

А что ты понимаешь под читателями? Я говорю в контексте изначальной задачи. Ты же постоянно уводишь разговор в другую сторону.

Цитата Qraizer @ 02.05.21, 18:13

Для этого события с автосбросом не нужны. Серьёзно, забей, плз.

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

Добавлено 02.05.21, 19:48

Цитата Qraizer @ 02.05.21, 18:13

Доказывал, что они более уязвимы, да

Что значит "уязвимы"? Для рядового кодера вероятность накосячить с cv на порядок меньше. Мне даже сложно представить ситуацию, когда гонка или дэдлок буду прямо неочевидны. Если ты сможешь привести буду рад. Про эвенты легко могу привести. У них даже в msdn в примере работы с com-портом была гонка. Нативная реализации блокирующей очереди на эвентах страдает от "кражи" события другим потоком, что для для многих джунов весьма неочевидно.

Добавлено 02.05.21, 19:59

Цитата Qraizer @ 02.05.21, 18:13

Если для тебя это не показатель качества процесса, то прости, что побеспокоил.

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

Добавлено 02.05.21, 20:04

Цитата Qraizer @ 02.05.21, 18:13

Думаю – что не знаешь, как и где его использовать.

Мне это становится очевидно после прочтения описания при условии знакомства с виндовыми эвентами.

Добавлено 02.05.21, 20:12

Цитата scrambrella @ 02.05.21, 19:24

Нормальным пользователям(не IT-гикам) линь даром не нужен.

Вот из-за представления о нем как игрушке для гиков он так плохо распространен на ПК. На само деле многие рядовые юзеры живут на убунте ничуть не хуже, чем на Винде. Стереотипное мышление + it-неграмотность.

Добавлено 02.05.21, 20:19

Цитата D_KEY @ 02.05.21, 08:34

На io_uring не смотрел случаем?

Не знаком с ним.

Цитата korvin @ 02.05.21, 11:34

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

Из WinApi можно 80% всего выкинуть без ущерба функциональности. Там большая часть для обратной совместимости, а если покопать внутри, то это просто обертки.

Цитата scrambrella @ 02.05.21, 19:24

Вы ещё на Android переведите M$

В андроиде Linux ядро используется.

Цитата

Нормальным пользователям(не IT-гикам) линь даром не нужен.

"Нормальные пользователи" даже не заметят, если винда переедет на linux ядро.

Цитата D_KEY @ 02.05.21, 08:34

По поводу сравнения с POSIX. Не очень понятно, зачем сравнивать конкретную ОС со стандартом, под который попадает очень широкий спектр ОС.

Если что, я тоже не знаю. Я лишь возразил Qraizer, что winapi - с архитектурной точки зрения кривоват, и тем более, странно считать его эталоном реализации api ос. Про сравнение Linux/posix это уже его домыслы, я нигде не писал, что считаю posix эталоном: там есть свои проблемы. Про cv был просто пример, так получилось, что в pthreads они появились раньше. И да, я считаю, что модель синхронизации на cv более высокоуровневая и удобная для программиста. Но это лишь один из примеров.

Сообщение отредактировано: shm - 02.05.21, 20:34

Цитата shm @ 02.05.21, 19:40

Цитата D_KEY @ 02.05.21, 08:34

На io_uring не смотрел случаем?

Не знаком с ним.

Новое API линукса для асинхронного ввода/вывода (упрощённо говоря). Если работаешь на системном уровне, то полезно ознакомиться. На прикладном уровне наверное не актуально, библиотеки всякие будут переползать на него постепенно.

Сообщение отредактировано: D_KEY - 02.05.21, 20:46

Цитата Qraizer @ 02.05.21, 18:13

И ты брут? Не жирность, а гибкость.

API, у которого документация (да и которое, видимо само) больше чем все другие API вместе взятые — это жирность, а не гибкость. Гибкое API не нуждается в тоннах жира. Plan 9 API — гибкое, а WinAPI — жирное.

Добавлено 02.05.21, 20:52
Qraizer, пример кривости POSIX API есть и по-проще, чем все эти ваши ивенты, cv и хз, что вы там обсуждаете.

Сообщение отредактировано: korvin - 02.05.21, 20:53

Цитата shm @ 02.05.21, 19:40

Вот из-за представления о нем как игрушке для гиков он так плохо распространен на ПК. На само деле многие рядовые юзеры живут на убунте ничуть не хуже, чем на Винде. Стереотипное мышление + it-неграмотность.

Линь хорош только в серверном применении. Работать в лине, за исключением серверного программирования, невозможно. Нет даже приличного аналога MS Office, не говоря о более специализированном софте. Копаться в горах open source мусора - дело гиков.

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

Цитата scrambrella @ 03.05.21, 09:30

Нет даже приличного аналога MS Office

Не смеши меня. Рядовому юзеру возможностей опенсорсных аналогов хватит за глаза.

Добавлено 03.05.21, 10:11

Цитата scrambrella @ 03.05.21, 09:30

не говоря о более специализированном софте

1С уже есть. Это на половину (если не больше) покрывает потребность в "специализированном софте" в РФ Игрушек почти нет, это да, жирный минус для большинства.

Ну пошел типичный срач винда vs линь

А я вот думаю, что мы двигаемся к слиянию. Т.е. винда рано или поздно будет этаким дистром линукса на стероидах.

Цитата D_KEY @ 03.05.21, 11:40

А я вот думаю, что мы двигаемся к слиянию. Т.е. винда рано или поздно будет этаким дистром линукса на стероидах.

Думаю, всё же, будет не так:

Цитата D_KEY @ 02.05.21, 08:34

Вообще есть мнение, что MS скоро может переехать на linux ядро

а windows будет поддерживать практически весь POSIX/Linux API и (почти) весь линуксовый юзерспейс сможет полноценно работать на винде, т.е. любители linux смогут использовать окружение GNOME/KDE/X11/Wayland/cli-tools/whatever так же легко, как и в linux (сейчас, насколько я понимаю, это лишь частично возможно), но в то же время спокойно запускать windows-only софт (игры, всякие специализированные программы) и т.п.

Т.е. это будет скорее этакий GNU/Windows, чем MS/Linux.

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

Сообщение отредактировано: korvin - 03.05.21, 15:12

Цитата korvin @ 03.05.21, 15:10

а windows будет поддерживать практически весь POSIX/Linux API и (почти) весь линуксовый юзерспейс сможет полноценно работать на винде, т.е. любители linux смогут использовать окружение GNOME/KDE/X11/Wayland/cli-tools/whatever так же легко, как и в linux (сейчас, насколько я понимаю, это лишь частично возможно), но в то же время спокойно запускать windows-only софт (игры, всякие специализированные программы) и т.п.

Я думаю, что с какого-то момента будет проще и дешевле взять ядро Linux и сверху/сбоку сделать слой windows-only. Но это произойдет не быстро, конечно. С другой стороны, будут развиваться проекты в духе Proton.

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

Цитата D_KEY @ 03.05.21, 15:22

Я думаю, что с какого-то момента будет проще и дешевле взять ядро Linux и сверху/сбоку сделать слой windows-only

Ты не читал, что Qraizer написал про документацию WinAPI? =) Думаю, полноценно портировать всё WinAPI на Linux будет крайне сложно/затратно даже для самой MS. Сколько времени уже wine развивается? А ReactOS?
А с другой стороны тот же WSL уже есть, и развивать его мне видится более простым и целесообразным для MS решением.

Цитата D_KEY @ 03.05.21, 15:22

в любом случае, противостояние постепенно переходит в некое слияние.

Тут полностью согласен. Может, мы оба ошибаемся, и в итоге произойдёт некоторая (большая) модуляризация и стандартизация интерфейсов windows/linux/gnu kernel/api/userspace и можно будет взять любую часть от любого из «поставщиков», скомбинировать и получить нужную тебе систему, с теми функциями, какие ты хочешь, в том числе и Максимальную^TM версию, умеющую и поддерживающую вообще всё. И MS станет поставщиком «деталей» и различных готовых сборок с их компонентами, а ля Red Hat.

Сообщение отредактировано: korvin - 03.05.21, 15:32

Цитата D_KEY @ 02.05.21, 18:26

Это связано с инструментами, консервативными взглядами, или еще с чем-то, на твой взгляд?

Не отвечу на пацана, но если я правильно представляю ситуацию, так в итоге дешевле. Поясню, что итог складывается из многих факторов, и из качества документации далеко не в последнюю очередь. Для POSIX ОС требуется гораздо больше работы по квалификации процессов. К тому же стоимость владения лицензией винды ниже, и нередко ниже стоимости лицензий специализированного ПО под неё. Последнее в связи с рыночным спросом, естественно.

Цитата D_KEY @ 02.05.21, 18:26

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Подумай сам. Если б Windows не имела бы преимуществ перед *nixами, MS бы давно сменила политику. Что касается безопасности и надёжности, потроллю немного, в манах по обеспечению того и другого при обсуждении той или иной уязвимости за POSIX ОС обычно читаешь "отключить", "отказаться от использования", "составить белый список и следить за логами", "заменить на новое" или там "пропатчить", и всё это примерно равномерно. А за Винду чаще всего "настроить" или "пропатчить". И лишь иногда что-то другое. В конце концов я не слышал, чтобы что-то из POSIX было сертифицировано по C2 Level, тогда как такие сертификаты имеют WinNT 3.5, 4.0 и 2000. Но это может быть связано с тем, что те просто не заморачивались, а если и заморачивались, то это отдельные специальные сборки, в широком кругу неизвестные. Впрочем, это тоже показатель.

Цитата D_KEY @ 02.05.21, 18:26

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

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов.

Цитата D_KEY @ 02.05.21, 18:26

MS вполне выгодно. Развитие WSL это показывает. Да и такие штуки, как windows terminal, winget и пр. так же показывают, что люди идут в сторону близких к *nix решений.

Не-а. Банальная борьба за расширение рынка влияния. Если людям кое-что кое-где удобнее не как тут, а как там, давайте тут им сделаем так, как они там привыкли. В конце концов WinNT изначально, с 1993-го года (!), поддерживала POSIX и была сертифицирована на совместимость с ним. Поддержка была убрана лишь в WinXP. По очевидным, думаю, причинам. Нынче вот возвращают. Ничего особенного, обычный рыночный виток.

Сообщение отредактировано: Qraizer - 03.05.21, 15:53

Цитата Qraizer @ 03.05.21, 15:31

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов.

Да можно и не вспоминать, есть совсем недавний скандал:

Цитата

Исследователи из университета Миннесоты — Цюши У и Канцзе Лу в рамках исследования «небезопасности» OSS модели пытались выяснить, насколько вероятно намеренное добавление уязвимостей в проекты. Среди прочего патчи были отправлены в ядро Linux.

В результате код ревью прошли 4 патча, в том числе 3 содержащих уязвимости. Представители проекта Linux обратились с жалобой на исследование к администрации университета, однако не нашли поддержки. Потому было принято решение больше никогда не принимать патчи от людей из этого заведения.

P. S. Сам скандал не столько из-за результатов исследования, сколько из-за того, как они были опубликованы.

Сообщение отредактировано: korvin - 03.05.21, 15:53

Цитата shm @ 02.05.21, 19:40

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

Та ладно, я сам процитирую.

Цитата Qraizer @ 30.04.21, 22:08

Цитата shm @ 23.04.21, 12:40

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

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

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

Цитата shm @ 02.05.21, 19:40

Ты говорил, что это просто, но решения и даже ссылки до сих пор нет. Расцениваю как слив.

Ну естественно. Как же ещё это было расценить. Но намекну: тебе нужны события с автосбросом, которые не бинарные, а со счётчиком. Это семафоры. Но мой вариант использовал бы кольцевой буфер с тремя служебными полями индексов/указателей, для которых достаточно интерлокед операций. То, что непонимание с твоей стороны этой банальщины я ещё в апреле посчитал сливом, я писать не стал, просто предложил забить, но хозяин барин.

Цитата shm @ 02.05.21, 19:40

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

Та легко. Я указал объём и качество документации по WinAPI как огромное преимущество, ты с этой точкой зрения не согласился, предпочёв посчитать таковым открытость. Ты посчитал большое количество параметров или полей в структурах кривостью, я это назвал гибкостью. Тут мы, думаю, не договоримся, ибо это вопрос предпочтений, объективизмом и не пахнет. Но я хотя бы аргументировал, чем с моей точки зрения гибкость лучше.

Добавлено 03.05.21, 16:14

Цитата korvin @ 02.05.21, 20:49

API, у которого документация (да и которое, видимо само) больше чем все другие API вместе взятые — это жирность, а не гибкость. Гибкое API не нуждается в тоннах жира. Plan 9 API — гибкое, а WinAPI — жирное.

Ты ошибаешься. Документации никогда не бывает много, даже когда её много. Хотел бы я, чтобы было иначе, но увы. Типичнейший пример, притча по языцах:

const int *data;
/.../
long *header_ptr = (long*)data;

Почти наверняка без понимания того, что хотел написать программист, ты не сможешь определить, корректен ли этот код. Тут может быть три различных варианта того, что он хотел, но без пояснений выбрать правильный невозможно. Хоть усмотрись в этот код всеми четырьмя глазами, высмотри до дыр, не определишь. Это ставит огромный крест на код-ревью только лишь по коду. Если только не знать всю подноготную архитектуры кода, которая, конечно же, является документацией на проект. К слову, у нас в отрасли всегда есть множество уровней документации — системные требования, требования верхнего уровня, требования нижнего уровней (последние могут уходить вглубь на несколько уровней), описание проекта ПО, описание процесса сборки ПО, описание архитектуры ПО, совместимость с целевым вычислителем, анализ стратегии управления кешем, анализ использования стека, анализ наихудшего времени исполнения — и это только то, что под нашей сферой ответственности со стороны верификации. Конечно, наша отрасль весьма особенная, и отраслевые стандарты очень строги, но как раз это и показывает роль моего тезиса о роли количества и качества документации. При желании документацию можно сделать очень хорошей, было бы желание тратить на это ресурсы. У MS желание было.

Сообщение отредактировано: Qraizer - 03.05.21, 16:15

Цитата Qraizer @ 03.05.21, 15:31

Цитата D_KEY @ 02.05.21, 18:26

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

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов

Так зависит не качество кода, а скорость обнаружения и исправления уязвимостей и косяков.

Сообщение отредактировано: D_KEY - 03.05.21, 16:19

Ой, пропустил.

Цитата D_KEY @ 02.05.21, 09:38

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Нет. В 2001-ом в std ещё ничего для этого не было, тогда как мы, работая тогда в КБ на военку, постоянно были под возможностью того, что нас отрежут от буржуйских инструментальных средств. Даже OS2000 кто-то из наших занимался. Вот я и написал себе простую обёртку над объектами синхронизации, чтоб при необходимости можно было переписать реализацию под pthread. И даже переписал, но потом, уже там не работая. Поверхностно, т.е. на синтетике, прочекал под AstraLinux, был у нас дистр.

Добавлено 03.05.21, 16:22

Цитата D_KEY @ 03.05.21, 16:19

Так зависит не качество кода, а скорость обнаружения и исправления уязвимостей и косяков.

Ну так потребителю-то пофик. У него в ПО косяк, для негатива в адрес ПО этого ему будет достаточно.

Цитата Qraizer @ 03.05.21, 15:31

Цитата D_KEY @ 02.05.21, 18:26

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Подумай сам. Если б Windows не имела бы преимуществ перед *nixами, MS бы давно сменила политику.

Во-первых, она меняет. Во-вторых, все преимущества лежат не в технической сфере

Цитата

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

Во-первых, ты продолжаешь сравнивать конкретную ОС со стандартами ОС Нужно взять какой-нибудь конкретный red hat и посмотреть на его примере.
Во-вторых, давай какой-то конкретный пример рассмотрим.

Добавлено 03.05.21, 16:27

Цитата Qraizer @ 03.05.21, 16:21

Цитата D_KEY @ 03.05.21, 16:19

Так зависит не качество кода, а скорость обнаружения и исправления уязвимостей и косяков.

Ну так потребителю-то пофик. У него в ПО косяк, для негатива в адрес ПО этого ему будет достаточно.

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

Ещё вот я сейчас работаю в двух системах, винда очень капризна А уж её обновления...

Цитата Qraizer @ 03.05.21, 15:52

Документации никогда не бывает много, даже когда её много.

Если документации требуется много, то это кривое API, а не хорошая документация.

Цитата Qraizer @ 03.05.21, 15:52

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

Это показывает лишь требования в вашей отрасли, а не во всех. Во многих других отраслях такая подробная документация в большинстве случаев — признак плохого кода/плохой архитектуры.

Цитата Qraizer @ 03.05.21, 16:21

Ой, пропустил.

Цитата D_KEY @ 02.05.21, 09:38

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Нет. В 2001-ом в std ещё ничего для этого не было

Это понятно. Но я так понял, что вы продолжаете это использовать и для нового кода. Вот тут я бы задумался и на твоем месте пожалел бы своих коллег.

Цитата Qraizer @ 03.05.21, 15:52

Но намекну: тебе нужны события с автосбросом, которые не бинарные, а со счётчиком.

Так и запишем, что на event'ах нормального решения для классической блокирующей очереди нет. Что я и пытался объяснить.

Цитата Qraizer @ 03.05.21, 15:52

Это семафоры.

На семафорах, действительно, можно. Но это вообще неинтересно и оффтоп. Их реализация в WinApi не так далека от классической и обсуждать тут особо нечего. Только это одни из самых тяжелых ядерных объектов синхронизации.

Цитата Qraizer @ 03.05.21, 15:52

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

Для кольцевого буфера - да, достаточно. Но только для него самого. Есть определенные проблемы с расширением этого самого буфера при нехватке места, они решаемы, хотя и делает реализацию на порядок сложнее. Но такая реализация не решает проблему с усыплением читателя, если ему нечего делать. На фьютесах - это довольно красиво реализуется, а "родными" средствами winapi громоздко и запутанно (если постоянно не дергать тяжелые объекты синхронизации, которые поставят под сомнение вообще любой профит от atomic).
Qraizer, ты в это споре занимаешься классической демагогией:
1. явно не отвечаешь на заданные вопросы, некоторые просто игнорируешь;
2. уводишь обсуждение в другую сторону;
3. когда твой оппонент начинает возражать, ты начинаешь ссылаться на то, что имел ввиду вообще другое.
И да, из этого спора я не узнал ничего нового. Ну разве что про внутреннее устройство io_uring почитаю. Все перечисленные объекты синхронизации, включая семафоры, я знаю "изнутри". Более того, я их реализовывал, пусть и не оптимально (оптимальная реализация того же семафора потянет на целую научную работу). Я давно планировал выложить все на гитхаб и чуть позже сделаю это, чтобы не выглядеть балаболом (осдев у меня это чисто хобби). Тема с эффективной блокирующей очередью меня интересовала длительное время т.к. это ключевой аспект для реализации асинхронного io в ядре. В итоге я потратил на изучение готовых решений не мало времени. И я был рад увидеть тут какие-то интересные решения того, чего я не знаю / в чем заблуждаюсь. Но в итоге ты занял позицию, что твой оппонент просто нуб. Прости если тебя не понял, Александр. Но по мне это выглядит именно так.

Сообщение отредактировано: shm - 03.05.21, 18:39

Интересный контракт

Цитата

Заказчик
ФЕДЕРАЛЬНАЯ СЛУЖБА ПО ТЕХНИЧЕСКОМУ И ЭКСПОРТНОМУ КОНТРОЛЮ

Цитата

Выполнение работ по созданию технологического центра исследования безопасности операционных систем, созданных на базе ядра Linux, включая разработку проектной (технической) документации и создание программно-аппаратного комплекса центра исследования безопасности операционных систем

Добавлено 03.05.21, 18:38

Цитата shm @ 03.05.21, 18:29

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

Цитата

Ну разве что про внутреннее устройство io_uring почитаю.

Если доберешься, то напиши своё мнение, интересно.

Я не вчитывался в ваш спор, но если он про асинхронный ввод/вывод, то в windows же iocp используется, в основном? И не такая уж плохая штука, разве нет?

Цитата D_KEY @ 03.05.21, 18:32

то в windows же iocp используется, в основном?

В основном - да. Все остальное использует ПО где нет нагрузки, а также всякие древние разработки (еще с win9x) или просто "топорные" порты с linux'а (вроде nginx под винду так и не имеет поддержки iocp). Но есть подозрение, что дебрях винды остался только iocp, а все остальное (всякие извращения с результатом io операции в оконном событии) реализуются уже поверх него.

Цитата D_KEY @ 03.05.21, 18:32

И не такая уж плохая штука, разве нет?

Штука неплохая. Если сравнивать с epoll, то более высокоуровневая. Поэтому на epoll реализовать iocp тривиально (что и делает wine), а в обратную сторону - фиг там. Что лучше - не знаю, скорее вопрос вкусовщины. Но явных архитектурных косяков как с теми же событиями в iocp я не знаю.

Сообщение отредактировано: shm - 03.05.21, 18:48

Цитата shm @ 03.05.21, 18:44

Если сравнивать с epoll, то более высокоуровневая. Поэтому на epoll реализовать iocp тривиально (что и делает wine)

А с обычными файлами как быть? epoll же с ним не работает (io_uring решает эту проблему, кстати).

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

Сообщение отредактировано: shm - 03.05.21, 19:58

Цитата D_KEY @ 02.05.21, 08:34

Если самолёты управляются софтом на windows, то мне страшно.

Не знаю как в самолетах, а вот блоки управления для автомобилей зачастую работают под embedded виндой. Во всяком случае, на прошлой работе мы делали инсталлер для некоторых блоков управления.

Цитата

Microsoft -Windows Embedded Automotive 7 is the OS for In Vehicle Infotainment (IVI) systems such as Ford Sync, Kia Uvo and Nissan Leaf. Most widely used car OS today.

Так что машины на винде есть А надежность софта там нужна не меньше, чем на самолете.

Цитата Fester @ 03.05.21, 20:17

Не знаю как в самолетах, а вот блоки управления для автомобилей зачастую работают под embedded виндой. Во всяком случае, на прошлой работе мы делали инсталлер для некоторых блоков управления.

Ты в какой-то неправильной Германии живёшь.
https://www.phoronix.com/scan.php?page=news...=BMW-Linux-2019
https://jobs.daimler.com/job/275774/infotai...d-engineer.html

korvin, я где-то говорил, что все блоки управления работают под embedded виндой?

Цитата D_KEY @ 02.05.21, 18:26

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Я думаю надежность Windows того же порядка, что и Linux.

Цитата shm @ 03.05.21, 10:07

Игрушек почти нет, это да, жирный минус для большинства.

Уже не актуально, спасибо Габену с его Valve.

Сообщение отредактировано: applegame - 04.05.21, 16:05

Цитата applegame @ 04.05.21, 16:05

Я думаю надежность Windows того же порядка, что и Linux.

Сложно поверить. Но нужно понять, как сравнить и где взять данные для этого сравнения.

Цитата D_KEY @ 03.05.21, 16:24

Во-первых, она меняет. Во-вторых, все преимущества лежат не в технической сфере

Меняет что? Отношение к сообществу открытого кода? Так это давно началось, ещё при Биллюшке. Мы же о другой политике – политике продвижения своих технологий.
И эта... может ты имел в виду "не все преимущества лежат в технической сфере"? Иначе я тебя не понял.

Цитата D_KEY @ 03.05.21, 16:24

Во-вторых, давай какой-то конкретный пример рассмотрим.

Бесполезно ж. Конкретный пример всегда конкретно взятый. Я ж говорил за статистику, это много примеров.

Цитата D_KEY @ 03.05.21, 16:24

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

Ну хорошо, пусть пример конкретный. Вот нашли уязвимость. Надо исправлять. У открытого кода ...э-э-э, код открыт, исправить может любой компетентный. Прилетает фикс от Васи Пупкина. И? Неужто его похлопают по плечу и вмержат? Танунафик, его скорее всего не заметят, а в лучшем случае будут ревьюить и скорее всего ревью фикс завалит, на что будет куча причин, от несоответствия стандартам кодирования до неуниверсальности. Чтобы всё прошло без сучка без задоринки, фикс должен быть от The Vasya pup King, но всё равно через ревью. И чем это отличается от уязвимости в закрытом коде? Там код открыт конкретным людям, все они The и почти наверняка компетентны.

Добавлено 05.05.21, 13:47

Цитата korvin @ 03.05.21, 16:42

Это показывает лишь требования в вашей отрасли, а не во всех. Во многих других отраслях такая подробная документация в большинстве случаев — признак плохого кода/плохой архитектуры.

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

Добавлено 05.05.21, 13:56

Цитата D_KEY @ 03.05.21, 16:45

Но я так понял, что вы продолжаете это использовать и для нового кода. Вот тут я бы задумался и на твоем месте пожалел бы своих коллег.

Если б ты был внимательнее, то заметил бы в моём посту слово "рефакторинг". Коду, который нынче в эксплуатации, точнее, некоторым его базовым подсистемам, исполнилось 18 лет. Они не меняются. Рефактор ради рефактора мне никто не оплатит, и это справедливо.
А вот новый в куда более интересной позе. Хочешь примера, я его дам.

Добавлено 05.05.21, 13:52

Цитата shm @ 03.05.21, 18:29

Только это одни из самых тяжелых ядерных объектов синхронизации.

Это да. Недаром нынче в WipAPI, по сравнению с оригинальным его релизом в начале 90-ых, надобавляли более лёгких,но и более ограниченных в возможностях объектов. Зато те, которые тяжелы, не ограничены рамками одного процесса и даже рамками одной пользовательской сессии, при этом защищены security API, чего без бубнов на POSIX не добиться.

Цитата shm @ 03.05.21, 18:29

Прости если тебя не понял, Александр. Но по мне это выглядит именно так.

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

Цитата shm @ 03.05.21, 18:29

Тема с эффективной блокирующей очередью меня интересовала длительное время т.к. это ключевой аспект для реализации асинхронного io в ядре.

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

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

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

на что ты получил более чем ожидаемую реакцию как на подтасовку файктов и подмену входных условий задачи.

Добавлено 05.05.21, 14:11

Цитата Fester @ 03.05.21, 20:17

Так что машины на винде есть А надежность софта там нужна не меньше, чем на самолете.

А ещё в банкоматах. А ещё на почте ...плохой пример... на кассах. А ещё фиг знает в каких отраслях. Подозреваю, что и в банковском сегменте её навалом, и на биржах, но это неточно.

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

Цитата Qraizer @ 05.05.21, 13:47

Зато те, которые тяжелы, не ограничены рамками одного процесса

Эти возможности я использовал всего несколько раз за всю жизнь. В большинстве случаев для запрета повторного запуска, пару раз для межпроцессного взаимодействия. К слову, и то и другое без проблем реализуется в Линухе.

Цитата Qraizer @ 05.05.21, 13:47

при этом защищены security API

Использовал ровно 0 раз.

Цитата Qraizer @ 05.05.21, 13:47

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

Да фиг с ним. Меня больше интересует как бы ты реализовал очередь, пусть и на lock-free ring bufffer, а именно:
1. Как бы обрабатывал переполнения? Или просто выделил бы буфер большого размера и забил? Очевидно, что возможность динамического расширения кольцевого буфера не лучшим образом скажется на производительности.
2. Как бы "усыплял" читателей, когда им делать нечего?

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

Цитата Qraizer @ 05.05.21, 13:47

Цитата D_KEY @ 03.05.21, 16:24

Во-первых, она меняет. Во-вторых, все преимущества лежат не в технической сфере

Меняет что? Отношение к сообществу открытого кода? Так это давно началось, ещё при Биллюшке. Мы же о другой политике – политике продвижения своих технологий.
И эта... может ты имел в виду "не все преимущества лежат в технической сфере"? Иначе я тебя не понял.

Меняет отношение к технологиям и подходам. WSL тому пример. Как и winget какой-нибудь. Т.е. я думаю, что MS просто впишется в общую движуху с технической точки зрения, для того, чтобы остаться успешной с точки зрения коммерческой.

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

Могу ошибаться, так что если накидаешь примеры успешных технических решений от ms, можно будет обсудить.

Я несколько предвзят, потому что на моем опыте решения от Ms удачными не были и всегда мне несколько портили жизнь Начиная от компиляторов C++ до каких-то глючных продуктов.

Добавлено 05.05.21, 19:48

Цитата Qraizer @ 05.05.21, 13:47

Цитата D_KEY @ 03.05.21, 16:24

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

Ну хорошо, пусть пример конкретный. Вот нашли уязвимость. Надо исправлять. У открытого кода ...э-э-э, код открыт, исправить может любой компетентный. Прилетает фикс от Васи Пупкина. И? Неужто его похлопают по плечу и вмержат? Танунафик, его скорее всего не заметят, а в лучшем случае будут ревьюить и скорее всего ревью фикс завалит, на что будет куча причин, от несоответствия стандартам кодирования до неуниверсальности. Чтобы всё прошло без сучка без задоринки, фикс должен быть от The Vasya pup King, но всё равно через ревью. И чем это отличается от уязвимости в закрытом коде? Там код открыт конкретным людям, все они The и почти наверняка компетентны.

Это не конкретный пример, а выдуманная тобой история, при чем я подозреваю, что ты не являешься человеком, который занимается этими вопросами

Прежде чем исправлять уязвимость, её сначала нужно обнаружить. У меня нет каких-либо данных об этом, но по-моему очевидно, что у столь массово используемой системы, да еще и с открытым кодом, вероятность обнаружения проблем выше.

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

Цитата Qraizer @ 05.05.21, 13:47

Если б ты был внимательнее, то заметил бы в моём посту слово "рефакторинг". Коду, который нынче в эксплуатации, точнее, некоторым его базовым подсистемам, исполнилось 18 лет. Они не меняются. Рефактор ради рефактора мне никто не оплатит, и это справедливо.

Программисты сегодня в основном и занимаются рефактором ради рефактора. Проводят скрамы, налаживают непрерывную поставку отрефакторенных программ, ходят на курсы по девопсу. Писать то уже нечего: все программы написаны. И пока бизнес за это платит.

Цитата Qraizer @ 05.05.21, 13:47

Если б ты был внимательнее, то заметил бы в моём посту слово "рефакторинг". Коду, который нынче в эксплуатации, точнее, некоторым его базовым подсистемам, исполнилось 18 лет. Они не меняются. Рефактор ради рефактора мне никто не оплатит, и это справедливо.

Если код не меняется, то тогда понятно. Я просто подустал сейчас от велосипедов в тех системах, с которыми приходится работать, поэтому стриггернуло меня.

Цитата

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

Ну можно, наверное

Цитата Qraizer @ 05.05.21, 13:47

А ещё в банкоматах. А ещё на почте ...плохой пример... на кассах. А ещё фиг знает в каких отраслях. Подозреваю, что и в банковском сегменте её навалом, и на биржах, но это неточно.

В банкоматах Линуксы как и на бирже, это инфа 100%
Сервера в банках вообще MF с юниксами, новые ставят лину с кластером ,
или берут в облаке на сьем, не видел чтобы кто-то брал винду,

Добавлено 06.05.21, 04:45

Цитата Qraizer @ 05.05.21, 13:47

Меняет что? Отношение к сообществу открытого кода? Так это давно началось, ещё при Биллюшке.

Открытый код это зло, и пишут его школьники у которых которых есть куча времени,
А фирмы за их счет набивают монитин и бабло, ввиде книг или курсов за 1000$ в день,
и конференций, Зачем тем держать тебя или меня и платить 300баксов в день в Сан-Франциско
если не больше , когда можно бесплатно получить индусов там румын или русских на бесплатно
и держать парочку ревьюеров, потом на открытый код ответсвенности нет, а за платный
если что, могут и штрафануть не слабо, другое дело что открытый код часто пишут фанаты
и потому он бывает очень даже не плохой, ну и главное QA бесплатный,

Я счас работаю с один таким открытым кодом, полное нарушение всех парадигм и принципов,
но маркетологи свое дело знают.

Добавлено 06.05.21, 05:11

Цитата Qraizer @ 05.05.21, 13:47

Вот нашли уязвимость. Надо исправлять. У открытого кода ...э-э-э, код открыт, исправить может любой компетентный.

Компетентных 25% от общей массы ну, У любого компетентного растет дочь которой надо платиь за учебу кормить, ну и вероятность что его
код примут, не говоря уже про заплатят весьма туманна,
Или Я что-то не понимаю?

Сообщение отредактировано: sergioK - 06.05.21, 05:11

Цитата sergioK @ 06.05.21, 04:36

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

Открытый не значит бесплатный
Это разные плоскости. Сейчас многие компании выкладывают свои разработки в open source, а так же платят своим сотрудникам за участие в разработке каких-либо open source проектов.

POSIX был разработан в 70-тых годах с тех пор не менялся. Проклятая совместимость.
WinAPI родился в 80 тых. И это была 4 работа над ошибками.
В POSIX куча лишних параметров при этом жестко прибитых гваздями.
WinAPI более гибкий. Правда за эту гибкость приходится платить кучей кода для опроса перед инициализацией.

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

В коммерческом ПО есть хоть какая то гарантия, что оно рабочее. Найдя баг, есть к кому обратиться.

Цитата scrambrella @ 06.05.21, 12:39

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

В коммерческом ПО есть хоть какая то гарантия, что оно рабочее. Найдя баг, есть к кому обратиться.

Ну что вы это же так удобно говорить про безопасность. Securety. Your's code is regularly inspected by community.
Если что Qraizer подтвердит что они регулярно проверяют Линукс на безопасность.

Цитата Pavia @ 06.05.21, 11:07

POSIX был разработан в 70-тых годах с тех пор не менялся.

Первый стандарт POSIX был в конце 80х, если не ошибаюсь.
И дальше он менялся и расширялся.

И ещё раз повторю свой тезис о том, что некорректно сравнивать API одного семейства ОС со стандартом, который охватывает широкое множество ОС.

Возьмите API линукса и сравнивайте.

Добавлено 06.05.21, 18:17

Цитата Pavia @ 06.05.21, 11:07

В POSIX куча лишних параметров при этом жестко прибитых гваздями.
WinAPI более гибкий.

Не хватает примеров

Добавлено 06.05.21, 18:19

Цитата scrambrella @ 06.05.21, 12:39

В коммерческом ПО есть хоть какая то гарантия, что оно рабочее. Найдя баг, есть к кому обратиться.

Коммерческий код может быть открытым. А некоммерческий - закрытым

Цитата D_KEY @ 06.05.21, 07:34

Открытый не значит бесплатный
Это разные плоскости. Сейчас многие компании выкладывают свои разработки в open source, а так же платят своим сотрудникам за участие в разработке каких-либо open source проектов.

Это как ? Чтоб на него посмотреть надо сначала заплатить ?
Не встечал такого,

Цитата sergioK @ 06.05.21, 20:40

Это как ? Чтоб на него посмотреть надо сначала заплатить ?
Не встечал такого,

Это так: покупаешь программу и получаешь в дополнение к исполняемому файлу исходники, например.

Open Source != бесплатный
Free Software != бесплатный

"Free" in "Free software" is like "free" in "freedome", not "free beer". https://www.gnu.org/philosophy/free-sw.en.h...e%20is%20gratis.

Добавлено 07.05.21, 01:28

Цитата Qraizer @ 05.05.21, 13:47

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

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

Один чел, не помню имени, написал mail-сервер на Си и формально (математически) доказал корректность его работы (или отсутствие багов, не помню точно). Кто им пользуется? Никто.

На хабре была байка про двух программистов (не могу найти): один усердно проектировал, а другой методом херак-херак-и-в-продакшн наладил успешный бизнес, пока первый, пардон, надрачивал на архитектуру и т.п.

Не понимаю, почему ты не считаешь целесообразность значимым критерием.

Сообщение отредактировано: korvin - 07.05.21, 01:29

Цитата scrambrella @ 06.05.21, 12:39

В коммерческом ПО есть хоть какая то гарантия, что оно рабочее. Найдя баг, есть к кому обратиться.

Что-то баги в Cyberpunk 2077 до сих пор не исправлены...

Добавлено 07.05.21, 01:56

Цитата Pavia @ 06.05.21, 11:07

POSIX был разработан в 70-тых годах с тех пор не менялся.

Что за чушь? https://en.wikipedia.org/wiki/POSIX#Versions

Цитата korvin @ 07.05.21, 00:55

Цитата sergioK @ 06.05.21, 20:40

Это как ? Чтоб на него посмотреть надо сначала заплатить ?
Не встечал такого,

Это так: покупаешь программу и получаешь в дополнение к исполняемому файлу исходники, например.

Open Source != бесплатный
Free Software != бесплатный

Open Source кторым я пользовался последнии лет 15 на 90% бесплатный,
вот вчера два часа угробил на баг за который никто не отвечает, и такое
сплошь и рядом а что значит Free Software ?

Цитата sergioK @ 07.05.21, 05:54

Open Source кторым я пользовался последнии лет 15 на 90% бесплатный,

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

Осторожно, бомба

eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)

Прочитав соглашение по ссылке выше, можете встроить её в свой софт

Цитата sergioK @ 06.05.21, 20:40

Это как ? Чтоб на него посмотреть надо сначала заплатить ?
Не встечал такого,

Продают-то не текст, а работающий софт, а то и какие-то варианты подписки. Система монетизации может быть совершенно разной. Ну и про лицензии выше писали.

Ещё интересный момент. Сейчас большинство реализаций языков программирования являются open source. Даже для C++ две лучшие реализации компилятора (gcc и clang) - open source.

Сообщение отредактировано: D_KEY - 07.05.21, 09:14

Цитата D_KEY @ 07.05.21, 09:09

Даже для C++ две лучшие реализации компилятора (gcc и clang) - open source.

gcc оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world

Цитата sergioK @ 07.05.21, 05:54

Open Source кторым я пользовался последнии лет 15 на 90% бесплатный

И что?

Цитата sergioK @ 07.05.21, 05:54

а что значит Free Software ?

https://www.fsf.org

Цитата korvin @ 07.05.21, 01:54

Цитата scrambrella @ 06.05.21, 12:39

В коммерческом ПО есть хоть какая то гарантия, что оно рабочее. Найдя баг, есть к кому обратиться.

Что-то баги в Cyberpunk 2077 до сих пор не исправлены...

В играх не баги, а фичи.

Цитата Wound @ 07.05.21, 09:49

Цитата D_KEY @ 07.05.21, 09:09

Даже для C++ две лучшие реализации компилятора (gcc и clang) - open source.

gcc оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world

Да не, отличный компилятор. Clang мне чуть больше нравится, но я бы не сказал, что такое уж большое преимущество. С какими проблемами ты столкнулся? Поделись.

Цитата kopilov @ 07.05.21, 08:47

Осторожно, бомба

eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)

Прочитав соглашение по ссылке выше, можете встроить её в свой софт

Прикол для школьников-задротов. Не сидите под рутом.

Цитата Wound @ 07.05.21, 09:49

gcc оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world

Ядро Линуха?

Цитата Fester @ 07.05.21, 07:39

Цитата sergioK @ 07.05.21, 05:54

Open Source кторым я пользовался последнии лет 15 на 90% бесплатный,

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

Я то как раз читаю, а вот начальство не всегда, ну им и отвечать если что.

Цитата sergioK @ 08.05.21, 10:22

Я то как раз читаю, а вот начальство не всегда, ну им и отвечать если что.

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

Цитата D_KEY @ 07.05.21, 09:09

Ещё интересный момент. Сейчас большинство реализаций языков программирования являются open source. Даже для C++ две лучшие реализации компилятора (gcc и clang) - open source.

И бесплатными, или кто платил то есть никто за ущерб не отвечает,
В внутри IDE баг в рализации гита, merge стирает мои файлы, потерял три дня,
кто за такое отвечаеть должен ?

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

Ну и открытый код, нужен только если что-то очень узкое надо,
Зачем мне смотреть в код например My SQL? Что оно мне даст ? В Яву раньше лазал, счас перестал, слишком много,
и пользы чуть выше нуля,

Сообщение отредактировано: sergioK - 08.05.21, 10:40

Цитата sergioK @ 08.05.21, 10:34

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

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

Цитата

в начеле 2000 когда покупали VS и было четкая докуметация

Тебе и сейчас никто не мешает покупать. У нас вон покупают
Под винду собираемся студийным компилятором плюс многие предпочитают студию в качестве IDE, поэтому покупают.

Но я не очень понимаю, что тебе не хватает в документации по gcc, например?

Цитата

да и какого черта ради документации Я должен идти в интернет? кторый
и тормозить может

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

Цитата

мне как по попался фрейворк с chm файлами, так работать одно удовольствие.

По-моему это как раз неудобно. Ну сделай сам себе chm на основе документации из интернета. Для тебя это проблема?

Сообщение отредактировано: D_KEY - 08.05.21, 15:13

Цитата D_KEY @ 07.05.21, 11:34

Да не, отличный компилятор. Clang мне чуть больше нравится, но я бы не сказал, что такое уж большое преимущество. С какими проблемами ты столкнулся? Поделись.

Да с примитивными, даже в специализацию не умеет. Одни баги.

Цитата Wound @ 08.05.21, 16:04

Да с примитивными, даже в специализацию не умеет. Одни баги.

Что-то я давно ни с чем таким не сталкивался. Сможешь показать? Я не ради спора спрашиваю, если что.

Добавлено 08.05.21, 17:13
Шаблоны использую, если что.

Если не трудно, можешь, например, на godbolt закинуть.

Цитата D_KEY @ 08.05.21, 17:10

Что-то я давно ни с чем таким не сталкивался. Сможешь показать? Я не ради спора спрашиваю, если что.

https://github.com/cpp-ru/ideas/issues/322

Добавлено 08.05.21, 17:29
Конкретно у меня было подобное. Искать или набирать примеры - мне лень. При этом компилировалось шлангом, msvs, gcc - ни в какую не хотел компилировать, причем на тот момент последний. В итоге наткнулся на баг что в ссылке.

Добавлено 08.05.21, 17:30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282

Это не баг. Студийный компилятор просто клал на это изначально, а gcc проверял, чтобы более точно соответствовать стандарту. В С++ 17 разрешили и в gcc скоро исправят, не сомневайся.
ЗЫ: проблем с реализацией стандарта в msvc намного больше.

Цитата shm @ 08.05.21, 18:36

Это не баг. Студийный компилятор просто клал на это изначально, а gcc проверял, чтобы более точно соответствовать стандарту. В С++ 17 разрешили и в gcc скоро исправят, не сомневайся.
ЗЫ: проблем с реализацией стандарта в msvc намного больше.

Это баг. Код со специализацией без проблем компилируется clang, msvs, gcc - выдает ошибку. И кто там на что изначально клал, я тебя не понял?

Сообщение отредактировано: Wound - 08.05.21, 19:32

Цитата shm @ 08.05.21, 18:36

Это не баг

Таки баг, поскольку даже с ключем -std=c++20 последними версиями не компилируется. Хотя надо будет глянуть в стандарте, как должно быть.

Добавлено 08.05.21, 20:06
clang компилируется аж с 6 версии (сейчас 12).

Цитата D_KEY @ 08.05.21, 20:04

clang компилируется аж с 6 версии (сейчас 12).

Да. Причем так получилось, что приложение писал на QT, под виндой, но ориентировано оно было на AstraLinux + Windows. С виндой проблем не было, а на астре по умолчанию стоит gcc, я помню тестил на последнем gcc на отдельном сайте, и код падал с ошибкой. MSVS компилил его нормально. Я подумал что в MSVS баг, специально проверил на шланге, так как где то читал мол де - это единственный компилятор, максимально полно поддерживает текущий стандарт. И clang мой код тоже нормально компилировал. Я начал глубже разбираться в проблеме и наткнулся на те ссылки что запостил выше. Т.е. это баг именно в GCC, из за этого, пришлось на AstraLinux отдельно ставить clang 9, вместо использования компилятора по умолчанию - что наложило свой негативный отпечаток на gcc. Если б вы в телеге сидели в беседке форума, то возможно бы как раз участвовали в обсуждении того кода, который у меня тогда валился. А так я просто не вспомню его на вскидку, а лезть на рабочую машину и искать сейчас этот код - очень лениво. Но думаю понятно о чем речь идет из примеров по ссылке.

Добавлено 08.05.21, 21:20
Ну и к слову в изначальном моем примере - никаких вложенных классов не было вообще, просто ЕМНИП использовалась частичная и/или полная специализация класса/методов(не помню точно)

Сообщение отредактировано: Wound - 08.05.21, 21:20

Цитата Wound @ 08.05.21, 21:07

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

Да, спасибо

Я тебя понимаю, в принципе. Только мне обычно студийный компилятор всегда жизнь портил, а вот с gcc давно не сталкивался с проблемами.
Мы компилируемся студийным под винду, под линукс на сборочных собираемся и clang и gcc. У себя локально я clang использую в линуксе.

Цитата D_KEY @ 08.05.21, 21:38

Мы компилируемся студийным под винду

А почему не clang-ом?

Цитата D_KEY @ 08.05.21, 20:04

Таки баг, поскольку даже с ключем -std=c++20 последними версиями не компилируется. Хотя надо будет глянуть в стандарте, как должно быть.

С таким успехом можно назвать багом все фичи из с++20, которые не реализованы в том же msvc.

Добавлено 09.05.21, 06:46
Ну ок, пусть будет баг. Не увидели разработчики gcc один пункт в новом стандарте, исправят. Msvc тут как бы плохой пример, т.к. они изначально на этот самый стандарт клали, поэтому такой код, емнимп, компилился до C++17, хотя не должен был.

Сообщение отредактировано: shm - 09.05.21, 06:48

Цитата shm @ 09.05.21, 06:35

С таким успехом можно назвать багом все фичи из с++20, которые не реализованы в том же msvc.

Ты на календарь то глянь. речь идет о 17 стандарте, gcc его еще не поддерживает? Тогда тем более в топку это багнутое говно.

Добавлено 09.05.21, 10:56

Цитата shm @ 09.05.21, 06:35

Не увидели разработчики gcc один пункт в новом стандарте, исправят.

Это такой же новый стандарт как и c++11, C++14. Я понимаю что время летит быстро, но не на столько же, чтоб стандарт 5 летней давности называть новым. Уже 23 во всю пилят, а те еще 17 не могут поддержать.

Цитата Wound @ 09.05.21, 10:55

Ты на календарь то глянь. речь идет о 17 стандарте, gcc его еще не поддерживает? Тогда тем более в топку это багнутое говно.

В msvc багов больше на порядок и они страшнее. Я даже сам рапортовал https://developercommunity.visualstudio.com...ystem-time.html. Мне просто лень перечислять все баги с которыми только я столкнулся (их много и все уже не вспомню). На абсолютно кривую реализацию стандарта я даже не обращаю внимание. Ты присосался только к одной проблеме gcc и почитал его бажным компилятором. Ну что ж, твое право.

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

Цитата shm @ 09.05.21, 11:56

В msvc багов больше на порядок и они страшнее. Я даже сам рапортовал https://developercommunity.visualstudio.com...ystem-time.html. Мне просто лень перечислять все баги с которыми только я столкнулся (их много и все уже не вспомню). На абсолютно кривую реализацию стандарта я даже не обращаю внимание. Ты присосался только к одной проблеме gcc и почитал его бажным компилятором. Ну что ж, твое право.

В msvs если и есть баги, их вполне оперативно устраняют(это видно даже по тому багрепорту, ссылку на который ты указал), хотя я сам лично не сильно сталкивался, плюс ты можешь в IDE указать другой компилятор типа clang, ЕМНИП. А в gcc - эти баги висят годами и они нах никому не упали фиксить их.

Сообщение отредактировано: Wound - 09.05.21, 12:04

Цитата Wound @ 09.05.21, 12:01

это видно даже по тому багрепорту, ссылку на который ты указал

А если внимательно почитать обсуждение?

Добавлено 09.05.21, 12:16

Цитата Wound @ 09.05.21, 12:01

А в gcc - эти баги висят годами и они нах никому не упали фиксить их.

Зависит от приоритета.

Добавлено 09.05.21, 12:20

Цитата

Hi folks!

Sorry for the confusion here. This might be somewhat misleadingly marked "fixed pending release." The problem is that this issue is caused by the DLL interface exposed by msvcp140.dll. It passes struct xtime instances back and forth, which are effectively UNIX timestamps against the system clock. Changing that interface is unfortunately an ABI breaking change. VS2017 and 2019 have been ABI compatible releases with VS2015, so we haven't been able to fix this paritcular bug there. (I think this_thread::sleep_for might be fixable with some hacks and a new msvcp140_3.dll, but condition_variable::sleep_for, probably not)

The reason this got marked as fixed pending release is that we already have changes staged in our ABI breaking branch that completely rewrite all the concurrency support in the standard library to fix this and *many* other bugs. So we have a branch with this fixed, and as soon as we can ship an ABI break it will be fixed, but unfortunately people really like the ABI compat guarantees.

As a result we don't really know exactly which release will contain the fix. We (the standard library team) have done the work; we are only waiting to ship it till the number of customers angry about ABI breaking bugs remaining unfixed exceeds the number of customers happy that lack of ABI break means they don't need to recompile the world.

Have a great day!

Billy O'Neal

Visual C++ Libraries
Mar 27, 2019

Добавлено 09.05.21, 12:24
Перевожу: да, у нас куча багов в рантайме, но фиксить пока не будем, т. к. бинарная совместимость для нас важнее.

Цитата Wound @ 07.05.21, 09:49

не может комплировать что то более сложное, чем Hello world

Может, компилирует, работает. Но сдает позиции, устаревает потихоньку.

А так ща в стиле Кили заявлю чушню:
clang оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world. Посмотрите сколько багов:
https://bugs.llvm.org/buglist.cgi?component...s&product=clang
И висят годами!!!

Сообщение отредактировано: applegame - 09.05.21, 13:52

Цитата korvin @ 07.05.21, 00:55

Не понимаю, почему ты не считаешь целесообразность значимым критерием.

Хм. Как раз его-то я и озвучил. Не заметил?
Но в целом если, когда ты используешь некий слой API и не знаешь, в какие ресурсы это выльется твоему коду, это не есть хорошо, это лишь может не заботить тебя в конкретной ситуации. Если создатель этого API ориентируется на широкий рынок потребителей, он должен учитывать, что никакая дополнительная информация не будет лишней хотя бы кому-то хотя бы изредка. Как эту инфу преподносить, это уже вопрос реализации стратегии распространения этого API.

Цитата Wound @ 07.05.21, 09:49

gcc оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world

Не одобряю нарушение 3-го морального принципа Холивара в Правилах его раздела. Но не откажу в удовольствии заметить, что GCC имеет по меньшей мере два противоречия со Стандартом C во всех своих инкарнациях. Любой версии и под любую платформу. Один связан с отношением к кастам из void*, об этом я даже тему когда-то создавал, второй я выявил недавно, и связан с тем, что он считает любые emum-ы без отрицательных значений его идентификаторов беззнаковым типом данных (точнее, при неявном касте к integral сводит к unsigned), что идёт в прямое противоречие с требованиями Стандарта. Чего не скажешь о clang, Microsoft Compiler, Intel Compiler и Borland, Freescale – всех, до которых я смог дотянуться. Как первый баг вылился в приличную копеечку нашим тогдашним заказчикам, в той теме я подробно расписал, как и во что второй вылился нашим нынешним, ещё не знаю, они только недавно были уведомлены. Вот и пользуй неквалифицированные инструменты в высококритичном ПО. Хорошо, что наши процессы тестирования и верификации... э-э-э, скажу политкорректно, имеют надлежащее финансирование.

Добавлено 09.05.21, 16:57

Цитата Pavia @ 06.05.21, 13:13

Если что Qraizer подтвердит что они регулярно проверяют Линукс на безопасность.

Не, ну не вот так прям. Если это потребуется по контракту, то да, но это не будет Линукс в полном смысле этого слова, это будет некий конкретный фрагмент кода, который... скажем так, летает. И проверятся он будет не на сферически определённые свойства, а конкретно и чётко заявленные формальные критерии. Это не та деятельность, которая обычно подразумевается под "проверкой на" в обиходе.

Добавлено 09.05.21, 16:58

Цитата D_KEY @ 05.05.21, 22:36

Если код не меняется, то тогда понятно.

Ну а зачем? Он работает. Когда перестанет, тогда им и займутся, не факт, что я.

Добавлено 09.05.21, 17:01

Цитата D_KEY @ 05.05.21, 19:40

Это не конкретный пример, а выдуманная тобой история, при чем я подозреваю, что ты не являешься человеком, который занимается этими вопросами

Ойфсё. Ну серьёзно, не надо рассказывать, что в OpenSource нет процедур ревью и что любой может всё. Даже никогда не сталкивавшемуся с тамошними процедурами кодеру-вчерашнему школьнику будет ясно, что так оно работать не может.

Добавлено 09.05.21, 17:05

Цитата D_KEY @ 05.05.21, 22:36

Ну можно, наверное

Попробую. Прикинул счас, написать много придётся. Иначе завалят, мол, архитектура говно, надо было иначе всё делать.

Сообщение отредактировано: Qraizer - 09.05.21, 17:05

Есть большая железяка. Точнее, две, полнократное дублирование, как бы. Она большая не по размерам, внутри она состоит из 8-ми пар различных вычислителей, занимающихся каждый своей частью задачи. Для неё был создан испытательный стенд на базе ПК под виндой. Он обвешан железом с проприетарными дровами, через которые ПК "командует" этой железкой и принимает от неё результаты. Задействованы все мыслимые каналы передачи, от банального UART до отраслевого ARINC. ПК по сети связан с другим ПК, где крутится модель. Модель с точностью двух сигм имитирует поведение борта, по сути в реальном времени интегрирует несколько десятков диффур. От неё по сети приходят данные для железки и в неё же отправляются результаты от железки. В обмене информацией задействованы в общей сложности не одна тысяча сигналов. В итоге железка пребывает в полной уверенности, что она на борту, а борт в режиме эксплуатации.
Есть тестовое окружения на базе среды RTRT. Модульные тесты покрывают весь функционал железки, их нынче несколько тысяч и это ещё не конец. Моя задача (увы, далеко не единственная, и не всегда самая приоритетная) с осени и по сей день заключается в том, чтобы обеспечить возможность на этом тестовом окружении в условиях отсутствия модели имитировать её, чтобы закрыть пункт интеграционного тестирования железки. Точности не требуется от слова вообще, она должна лишь прикинуться моделью, чтобы тесты могли подавать тестовые воздействия согласно требованиям и оценивать их итоги согласно требованиям же. Тестовое окружение универсально и тоже полагается на сетевое взаимодействие. Только это совершенно другие протоколы. И к тому же работающие совсем в другой сети, в другом городе с доступом к стенду по VPN. У нас нет лицензий на их проприетарные железяки с дровами, у них есть. У них нет лицензий на RTRT, у нас есть. В общем, всё сложно.
Их сетевой протокол простой: обмен датаграммами по UDP максимально часто. Наш сетевой протокол сложнее: простой динамический аналог DNS без привязки адресов и маршрутизация между узлами сети пакетов данных, а уже на пакетах можно реализовать любой протокол. Т.е. фактически можно использовать среду RTRT как транспорт. Формально это просто маршрутизация трафика с адресацией по имени узла. Ну и да, там TCP. Формально, такие маршрутизаторы могут регистрироваться друг у друга и тоже выступать как потребители услуг транспортного протокола, т.с. строя сложные топологии, включая даже работу через разные физические среды приёма/передачи, но пока этого не требовалось.
В итоге математика примерно такая. В нашей сети есть ПК, на котором поднят VPN и работает сервер транспорта. Наш инженер где-то в нашей сети запускает тест на исполнение. Стартует виртуальный тестер, ищет сервер транспорта, регистрируется у него и т.о. получает возможность взаимодействовать с любым другим зарегистрировавшимся узлом. Одним из таковых является транслятор протоколов, который запущен на той стороне VPN и тоже зарегистрировавшийся как некий виртуальный тестер. Тест упаковывает (точнее это делают комона, у тестов простой и удобный API для этого) протокол взаимодействия с железкой в пакеты и посредством транспорта отправляет транслятору протоколов. Тот посредством маршрутизации через сервер проходит через VPN и принимается транслятором уже в той сети. Транслятор его... внезапно... транслирует из нашего протокола в протокол модели со стендом, ну, UDP который, и т.с. осуществляет воздействие на стенд. Как оно там дальше, нам уже не интересно, однозначно лишь, что результаты от железки проходят весь этот путь в обратном порядке до теста. Все лицензии по порядке, реал-тайм где надо выдержан, никто под несвоё ничего не адаптирует, все счастливы.

Сообщение отредактировано: Qraizer - 09.05.21, 18:00

Цитата D_KEY @ 08.05.21, 15:12

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

Для документации интернет не нужен, если документациия нормальная, счас таких почти не осталось.
Ты в черных ящиках работал или банках ? там его нет, и это не проблема, без трепа на форуме можно и обойтись,
или зайти мобилы если сильно хочеться. Или пойти на другой комп где интернет есть,

Добавлено 09.05.21, 18:51

Цитата D_KEY @ 08.05.21, 15:12

Цитата sergioK @ 08.05.21, 10:34

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

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

Я тоже пушу, тут днем понадобилось,
пруф простой в Intelij есть опция Rebase, и он сделал мне 4 мерджа, решив что раз их в головной ветке
нет, то у меня стоит удалить, сделал половину работы и завис, пришлось из терминала абортить,
это как нормально? Из терминала все работает без проблем, а как тебе баг в орен сорсе , там строиться SQL
так вот стоиться он наполовину, в купленном софте такое не возможно, а в орен без проблем,
А ведь в продакшене случись , ну рак бы не обнаружили вовремя, подумашь мелочь, и никто не отвечает,

Добавлено 09.05.21, 18:53

Цитата D_KEY @ 08.05.21, 15:12

По-моему это как раз неудобно. Ну сделай сам себе chm на основе документации из интернета. Для тебя это проблема?

Да сделал уже давно, только многие не могут, или не знают,

Вопрос как раз в этом самом трансляторе. В идле он просто ожидает какого-либо события. Это может быть:

• входящий запрос от виртуального тестера из нашей сети;
• входящий запрос от стенда из своей сети;
• консольный запрос от оператора тестового окружения.

Ну да, простая консолька у него тоже есть, надо ж как-то отлаживать тесты и просто изучать поведение железки. Как-никак в ней 20 процессоров и у всех свои законы поведения. Одной только математики в PDF на три мега, и это не считая всей железно-протокольной обвязки. Из-за асинхронности всех событий он обвешан нитками, которые к тому же ещё и взаимодействуют друг с другом: консоль с UDP, UDP с консолью, TCP с UDP, UDP с TCP, консоль с ТCP и UDP. Нужно уметь опрашивать сокеты и очередь событий. Нужно отвечать на события с сохранением инвариантов протокола, чтоб не путать, кому что. И это непросто, учитывая общую асинхронность системы стенд/тестер. Нужно элементарно уметь завершать работу по запросу и уметь реагировать на сетевые сбои. Код новый? Новый. Применим std? Почему бы и нет. Да и внезапный ( ) перекос политик кампаний в сторону открытых архитектур никто не отменял. Применил.
Сокеты умеют таймауты только на select(), а без таймаутов беда, ибо пока, скажем, виртуальный тестер не отзовётся, обслужить запрос от UDP-нитки будет невозможно. Есть условные переменные, которым в довесок подавай мютексы и лямбды, да ещё и соизволь сам нотифить ими в нужные моменты. Хочешь завершить работу, дождись джойнов от всех ниток, иначе хрен тебе в журналах аудита от эксепшнов. В итоге код управления потоками представляет собой жуткий винегрет. На каждую переменную по мьютексу и паре лямбд опроса и установки. Всё это надо захватывать из контекста или передавать параметрами, иначе оно должно валяться прямо в глобальном скопе и закардорджено. И не забывать после смены состояния переменой нотифи кидать, за тебя тебе этого никто не напомнит. Рабочий цикл каждой нитки состоит из отдельных опросов "своего" сокета и каждой из переменных с конкретными лямбдами. При ошибках эксептишь себе в catch, чтобы корректно завершиться, где опять же не забудь изменить состояние и отнотифицироваться, а если таковое случится во время обслуживания запроса от другой нитки, а не стенда или виртуального тестера, то там тоже нужно предусмотреть код корректной реакции на сие.
Все эти активити вполне формальны и моим вторым желанием (после первого – забить) было оформить всё красиво. В кулуарах я сделал класс над переменными и все кишки упрятал туда. Стало лучше, если не глядеть во внутрь класса. Чего не удалось, так это упрятать формализм опроса/установки/сброса, там что от лямбд избавиться не получилось, но стало хотя бы приемлемо пользовать. И тут вдруг меня осенило полиморфизмом. На скорую руку я сварганил стратегии а-ля Александреску, и внезапно на этом метаклассе я понял, что условных переменных снаружи не осталось. Так я лишний раз убедился, что условные переменные в этой задаче в общем-то и не нужны, а их наличие является лишь следствием того, что std непродуман и слишком сырой. Ибо всё вот это вот, если делать по-хорошему, а не с кишками наружу, всё равно придётся делать из раза в раз по одной и той же схеме.
Единственное, чего ещё не хватало для полного счастья, это возможности создавать композиции таких объектов. Мне оно было не надо, но за пару перекуров я набросал в голове, как бы это сделал. И вот совсем уж внезапно вдруг неожиданно для себя прям вот снег на голову (шутки шутками, но реально, я чуть не поперхнулся дымом, когда осознал) у меня получилось ...WinAPI. Не, конечно реализовано там всё по-другому, но внешне архитектура точь в точь. Морали не будет. Пусть каждый делает выводы сам. Я свои озвучил выше.

Цитата D_KEY @ 08.05.21, 15:12

Но я не очень понимаю, что тебе не хватает в документации по gcc, например?

Внятных примеров и разьяснений, Я не большой спец в С/С++
Вот таже студия мелкосовта в 2000 все разьясняла, счас хуже,
ибо модель другая, по выкакиванию денег, Остан Бендер нервно курит в сторонке,

Цитата sergioK @ 09.05.21, 18:58

Цитата D_KEY @ 08.05.21, 15:12

Но я не очень понимаю, что тебе не хватает в документации по gcc, например?

Внятных примеров и разьяснений, Я не большой спец в С/С++

cppreference
isocpp

Цитата

Вот таже студия мелкосовта в 2000 все разьясняла

Студия - это IDE, gcc - компилятор

Добавлено 09.05.21, 19:39
Qraizer, спасибо за столь подробный пример. Позже прочту и вникну, возможно даже не завтра

Сообщение отредактировано: D_KEY - 09.05.21, 19:39

Qraizer, спасибо за столь объемное изложение, в общем как будет время, внимательно перечитаю и отвечу.
ЗЫ: мой вопрос про очередь ты проигнорировал сознательно или не заметил?

Навскидку кажется, что стоит подумать над идей, что конкурентность и параллельность не одно и то же. Плюс еще для асинхронности нужны не потоки, а средства асинхронности или её имитации. В винде в сторону iocp посмотреть, в линухе epoll и вот новый io_uring. Ну а в нормальных условиях asio. Плюс еще возможно сопрограммы помогут.

Если я сейчас херню пишу не в тему, то не ругайся, я совсем бегло прочел

Добавлено 09.05.21, 19:51

Цитата sergioK @ 09.05.21, 18:29

пруф простой в Intelij есть опция Rebase, и он сделал мне 4 мерджа, решив что раз их в головной ветке
нет, то у меня стоит удалить, сделал половину работы и завис, пришлось из терминала абортить,
это как нормально?

Не очень тебя понял. Но разве это не баг в купленной intelij?

Цитата Qraizer @ 05.05.21, 13:47

Вот нашли уязвимость. Надо исправлять. У открытого кода ...э-э-э, код открыт, исправить может любой компетентный. Прилетает фикс от Васи Пупкина. И? Неужто его похлопают по плечу и вмержат? Танунафик, его скорее всего не заметят, а в лучшем случае будут ревьюить и скорее всего ревью фикс завалит, на что будет куча причин, от несоответствия стандартам кодирования до неуниверсальности. Чтобы всё прошло без сучка без задоринки, фикс должен быть от The Vasya pup King, но всё равно через ревью. И чем это отличается от уязвимости в закрытом коде? Там код открыт конкретным людям, все они The и почти наверняка компетентны.

Откуда такое представление об открытом коде?
Окей, не Васи Пупкина, а Дмитрия Барышкова взяли да приняли. Особо не спорили
Разница открытого кода не в том, что им занимаются компетентные люди из разных контор (при условии, что проект важный, конечно). Ври например если посмотреть на список уязвимостей того же линукса (ссылка) - фиксы то IBM, Oracle, RedHat и того же Дмитрия. И да, в таких проектах высокие стандарты качества, которые к тому же находятся под строгим присмотром сотен других компетеных людей: просто так закостылить будет тяжело: либо морально, либо физически - но тяжело. И при таком сообществе шансы таки получить фикс в максимально короткий срок значительно выше.

У меня личный пример был относительно недавно: в Firefox - я пришел в чатик (кстати в неправильный) с вопросом мол хочу сделать вот такую штуку. И вот как-то, никто никуда меня не послал и развернуть не пытались: указали нужный чат, в чате навели на правильных людей, те вникли в суть подсказали как правильнее сделать (притом, что область оказалась новой для всех), и как вписать это в исходники, как подойти к вопросу ревью. Вот ни на одном этапе не чувствовалось, что пытаюстся "завалить". Это кстати, всё было как-раз во время новости про большие сокращения в Mozilla, но всё-равно сообщество было максимально дружелюбно.

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

Сообщение отредактировано: negram - 09.05.21, 20:03

Цитата shm @ 09.05.21, 12:16

Перевожу: да, у нас куча багов в рантайме, но фиксить пока не будем, т. к. бинарная совместимость для нас важнее.

Я весь тред не читал, мне это не интересно, я просто смотрю статус - Fixed, в отличии от GCC.

Сообщение отредактировано: Wound - 09.05.21, 20:44

Нет у компилей багов, если нормально проги писать. Не используйте экзотические конструкции. Сами в них запутаетесь.

Добавлено 09.05.21, 23:29

Цитата Qraizer @ 09.05.21, 17:53

В итоге железка пребывает в полной уверенности, что она на борту, а борт в режиме эксплуатации.

Матрица, блин.

Цитата D_KEY @ 09.05.21, 19:45

Не очень тебя понял. Но разве это не баг в купленной intelij?

Баг, и за него никто не отвечает, а отвечать должны, это то что Я пытаюсь сказал,
и не только в Идее,

Добавлено 10.05.21, 03:55

Цитата D_KEY @ 09.05.21, 19:24

Цитата sergioK @ 09.05.21, 18:58

Цитата D_KEY @ 08.05.21, 15:12

Но я не очень понимаю, что тебе не хватает в документации по gcc, например?

Внятных примеров и разьяснений, Я не большой спец в С/С++

cppreference
isocpp

Дак в гугле Я сам искать умею, ты не вьезжаешь в то о чем я говорю

Добавлено 10.05.21, 03:57

Цитата D_KEY @ 09.05.21, 19:24

Цитата

Вот таже студия мелкосовта в 2000 все разьясняла

Студия - это IDE, gcc - компилятор

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

Сообщение отредактировано: sergioK - 10.05.21, 04:04

Цитата sergioK @ 10.05.21, 03:52

Цитата D_KEY @ 09.05.21, 19:45

Не очень тебя понял. Но разве это не баг в купленной intelij?

Баг, и за него никто не отвечает, а отвечать должны, это то что Я пытаюсь сказал,
и не только в Идее

Так при чем тут open source? Ты меня запутал. Ты же (компания твоя) купил идею? Почему jet brains не отвечает?
Ты зарепортил баг-то?

Добавлено 10.05.21, 08:13

Цитата sergioK @ 10.05.21, 03:52

бесплатная жава дает вообще пародию на документацию, это цена бесплатности.

Я не вижу никакой логики в твоих словах. Просто сейчас вся документация в онлайн уехала

Добавлено 10.05.21, 08:15

Цитата sergioK @ 10.05.21, 03:52

ты не вьезжаешь в то о чем я говорю

Есть такое. Я не понимаю, чем тебя не устраивает онлайн документация в 2021 году. И не понимаю, при чем тут бесплатность.

Сообщение отредактировано: D_KEY - 10.05.21, 08:15

Цитата sergioK @ 10.05.21, 03:52

Баг, и за него никто не отвечает, а отвечать должны, это то что Я пытаюсь сказал

Я не понимаю, почему кто-то должен отвечать за баг в IDE? Ты, когда покупал, читал вообще, что именно ты покупаешь?
ТЫ понимаешь, что для того, чтобы кто-то тебе отвечал за баг, надо 1) доказать, что баг привел к потерям и 2) надо купить именно тот сервис, который привел к потерям.

Грубо говоря, если ты продаешь некий сервис и оговариваешь, что максимальный down time не привышает суммарно час в сутки, то это твои обязательства и если твой сервис в один из дней лежит 61 минуту, то ты получишь предъяву и должен будешь компенсировать эту минуту.

Цитата Wound @ 09.05.21, 20:38

Я весь тред не читал, мне это не интересно, я просто смотрю статус - Fixed, в отличии от GCC.

Прикольно. Тикет "закрыли", и следующие 3 года в комменах "эй ребят, нифига ж не пофикшено"

Цитата negram @ 10.05.21, 10:48

Прикольно. Тикет "закрыли", и следующие 3 года в комменах "эй ребят, нифига ж не пофикшено"

Там в последнем посте вроде все предельно ясно написано.

Цитата

Hi folks!

Sorry for the confusion here. This might be somewhat misleadingly marked "fixed pending release." The problem is that this issue is caused by the DLL interface exposed by msvcp140.dll. It passes struct xtime instances back and forth, which are effectively UNIX timestamps against the system clock. Changing that interface is unfortunately an ABI breaking change. VS2017 and 2019 have been ABI compatible releases with VS2015, so we haven't been able to fix this paritcular bug there. (I think this_thread::sleep_for might be fixable with some hacks and a new msvcp140_3.dll, but condition_variable::sleep_for, probably not)

The reason this got marked as fixed pending release is that we already have changes staged in our ABI breaking branch that completely rewrite all the concurrency support in the standard library to fix this and *many* other bugs. So we have a branch with this fixed, and as soon as we can ship an ABI break it will be fixed, but unfortunately people really like the ABI compat guarantees.

As a result we don't really know exactly which release will contain the fix. We (the standard library team) have done the work; we are only waiting to ship it till the number of customers angry about ABI breaking bugs remaining unfixed exceeds the number of customers happy that lack of ABI break means they don't need to recompile the world.

Have a great day!

Billy O'Neal

Visual C++ Libraries

Цитата Wound @ 10.05.21, 11:16

Там в последнем посте вроде все предельно ясно написано.

Тебе ж не интересно

Цитата negram @ 10.05.21, 11:24

Тебе ж не интересно

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

Цитата Fester @ 10.05.21, 08:40

Грубо говоря, если ты продаешь некий сервис и оговариваешь, что максимальный down time не привышает суммарно час в сутки, то это твои обязательства и если твой сервис в один из дней лежит 61 минуту, то ты получишь предъяву и должен будешь компенсировать эту минуту.

Это как отднельный пример , таких тонна будет,
Ты ботинки купил они првались , тот кто продал за это отвечает,
За баги нет, механизм тут по сложнее будет, но пусть он будет хоть какой,
разрабы оперсорсов этим пользуються и часто гонят на рынок туфту, пользуясь
масовой неграмотностью быдло кодеров( их разы больше чем нас ) и промыв мозги менагерам,
которые не разбираються в технический аспектах, тебя такой положение устраивает?
Меня нет, помниться в 2002 году была проблема с Oracle не тривиальная, позвонил в саппорт , проверили что
фирма с лицензией с дали ответ, за все про все меньше суток, тоже самое делал Sun и Borland.
купил продукт получаешь поддержку, чем плохо ?

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

Цитата sergioK @ 10.05.21, 18:41

Ты ботинки купил они првались , тот кто продал за это отвечает

На ботинки есть гарантия и дает ее не продавец, а производитель. Продавец - всего лишь посредник.

Цитата sergioK @ 10.05.21, 18:41

За баги нет, механизм тут по сложнее будет, но пусть он будет хоть какой

Механизм точно такой же. Есть некая услуга, которая может быть качественной или нет. На эту услугу есть метрики, по которым можно оценить качество услуги. И если контракт, в котором описаны метрики и штрафы за нарушение метрик.

Цитата sergioK @ 10.05.21, 18:41

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

Глупости, есть большое количество качественных опен-сорс проектов и есть огромное количество говеного платного софта

Цитата sergioK @ 10.05.21, 18:41

Меня нет, помниться в 2002 году была проблема с Oracle не тривиальная, позвонил в саппорт , проверили что
фирма с лицензией с дали ответ, за все про все меньше суток, тоже самое делал Sun и Borland.
купил продукт получаешь поддержку, чем плохо ?

Всем хорошо. Вот у нас клиенты купили софт, словили баг 03.05.2021 и только сегодня (10.05.2021) баг попал ко мне на выяснение причин. И хрен его знает, когда клиент получит фикс.
Или я помню купили мы поддержку MS, а у них ограниченное количество обращений в год. При этом что-то поядка 3-5 обращений было. И столкнулись мы с проблемой, если не ошибаюсь c Analysis Services). Проблему чуть ли не хозяина фирмы эскалировали чтобы решить имеет ли смысл обращаться в саппорт MS или у нас еще больше полгода впереди и могут возникнуть реальные проблемы. Ну и у меня уже бывали переписки с саппортом с нулевым выхлопом. Так что наличие саппорта ничего еще не гарантирует.

Цитата D_KEY @ 10.05.21, 20:39

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

Компания купила не я, а недоволен я не сколько багом , а кто бывает багом доволен?
А тем что изобрели велосипед, есть команда git вот и имплементируй ее в среде, а если решаешь сделать
по своему то будь любезен об этом сообщить, и нефиг называть также,

Вопрос не в том что Я доволен или или нет а в том что кто это делал просто пофиг, и рычагов повлиять
на это нету ни у кого, take it or live it тут плохой принцип.

Добавлено 11.05.21, 03:36

Цитата Fester @ 10.05.21, 21:01

Так что наличие саппорта ничего еще не гарантирует.

Наличие гарантии на ботинки тоже не гарантирует ничего, но есть рычаги повлиять,
когда что-то зашкаливает, и рычаги не обязательно судебные, а опер сорсов нет никакой
ответсвеннности,

Добавлено 11.05.21, 03:40

Цитата Fester @ 10.05.21, 21:01

Глупости, есть большое количество качественных опен-сорс проектов и есть огромное количество говеного платного софта

Да есть конечно, а вот платного дерьма я не встречал, везло наверное, зато встречал
менеджеров,которые не понимают что покупают, и для чего, им эго не позволяет слушать,
что програмист говорит, sales persons этим неплохо пользуються.

Цитата Wound @ 09.05.21, 20:38

Цитата shm @ 09.05.21, 12:16

Перевожу: да, у нас куча багов в рантайме, но фиксить пока не будем, т. к. бинарная совместимость для нас важнее.

Я весь тред не читал, мне это не интересно, я просто смотрю статус - Fixed, в отличии от GCC.

Ну раз не читал. Повторю еще раз:

clang оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world. Посмотрите сколько багов:
https://bugs.llvm.org/buglist.cgi?component...s&product=clang
И висят годами!!!

Цитата applegame @ 11.05.21, 05:28

clang оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world. Посмотрите сколько багов:
https://bugs.llvm.org/buglist.cgi?component...s&product=clang
И висят годами!!!

Как то не особо я сталкивался с багами clang. Поэтому ничего не могу сказать по этому поводу. Сталкивался с багами msvs 6.0, вот эта версия студии - редкостный оцтой. Более поздние версии - вполне себе нормально работают. А при юзаньи gcc не раз натыкался на то, что он не может собрать исходники, которые без проблем собираются другими компиляторами.
Еще сталкивался с багами xlC/C++ Compilers for AIX, тоже говно еще то. Тот же буст - некоторые модули он не смог осилить откомпилировать. Но на тот момент - его юзали почти не по своей воле, еще и паходу его дорабатывали по ходу дела.

Цитата Wound @ 11.05.21, 08:10

которые без проблем собираются другими компиляторами.

Другие - это msvc?

Цитата Wound @ 11.05.21, 08:10

Цитата applegame @ 11.05.21, 05:28

clang оцтой полный, багнутое говно, которое не может комплировать что то более сложное, чем Hello world. Посмотрите сколько багов:
https://bugs.llvm.org/buglist.cgi?component...s&product=clang
И висят годами!!!

Как то не особо я сталкивался с багами clang. Поэтому ничего не могу сказать по этому поводу. Сталкивался с багами msvs 6.0, вот эта версия студии - редкостный оцтой. Более поздние версии - вполне себе нормально работают. А при юзаньи gcc не раз натыкался на то, что он не может собрать исходники, которые без проблем собираются другими компиляторами.
Еще сталкивался с багами xlC/C++ Compilers for AIX, тоже говно еще то. Тот же буст - некоторые модули он не смог осилить откомпилировать. Но на тот момент - его юзали почти не по своей воле, еще и паходу его дорабатывали по ходу дела.

Баги у Вас в голове.

Буст отстой. Шаблоны головного мозга.

Цитата shm @ 11.05.21, 08:35

Другие - это msvc?

clang/msvc

Цитата Wound @ 11.05.21, 13:01

clang/msvc

Ммм. А вывод сделан только по одной проблеме?

Сообщение отредактировано: shm - 11.05.21, 21:52

Цитата Qraizer @ 09.05.21, 18:56

Из-за асинхронности всех событий он обвешан нитками, которые к тому же ещё и взаимодействуют друг с другом: консоль с UDP, UDP с консолью, TCP с UDP, UDP с TCP, консоль с ТCP и UDP. Нужно уметь опрашивать сокеты и очередь событий. Нужно отвечать на события с сохранением инвариантов протокола, чтоб не путать, кому что. И это непросто, учитывая общую асинхронность системы стенд/тестер. Нужно элементарно уметь завершать работу по запросу и уметь реагировать на сетевые сбои.

Вот тут я не очень понимаю. По-моему ты смешиваешь логику с техническим аспектом исполнения. Асинхронный код может чудесно работать вообще на одном треде, делая все перечисленные тобой задачи. Вроде у тебя тут нет вычислений в данном случае, которые заблокируют обработку запросов.
Я бы отделил логику от вопроса сколько там тредов будет под капотом это все выполнять (в тредпул бы вынес или ещё как - вопрос отдельный).

Так что не очень понял, при чем там потоки и std/WinAPI.

Добавлено 12.05.21, 19:45

Цитата Qraizer @ 09.05.21, 18:56

Сокеты умеют таймауты только на select()

Зачем select? Если уж работаешь на низком уровне и именно на винде, то используй iocp. А asio нет возможности юзнуть?

Добавлено 12.05.21, 19:50

Цитата Qraizer @ 09.05.21, 18:56

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

Так что мешает использовать "классический" асинхронный подход в духе asio (тем более, что насколько мне известно, на основе него будет что-то в новых стандартах) с исполнением на нескольких тредах, без привязки логики к тредам, без выделения "специализированных" тредов?

Добавлено 12.05.21, 19:53
Qraizer, а есть какая-то возможность упростить пример так, чтоб можно было тут с кодом поиграться и разные варианты его обыграть/обсудить?

Сообщение отредактировано: D_KEY - 12.05.21, 19:55

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

Цитата Majestio @ 03.12.24, 14:07

Сорян если я был слишком неточен в выражении своих вопросов

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

Добавлено 03.12.24, 18:40
P.S. Я тем не менее с удовольствием посмотрел бы на транслятор сигналов POSIX в C++EH хотя бы краем глаза. Мог бы и сам заняться, но у меня никсов под рукой нет. Летом вот была убунта недолго, я даже успел одну из своих утилей и одну из библиотек под неё портировать.

Добавлено 03.12.24, 18:45
P.P.S. Хотя лучше этот ваш POSIX никогда не трогать. Вообще. Вот сравни просто одну-единственную функцию-перечислитель сетевых интерфейсов.

Скрытый текст

// Функция перебора активных сетевых интерфейсов. Принимает функциональный объект, который
// вызывается для каждого интерфейса и с параметрами назначенного адреса и маски его подсети.
// Объект может вернуть false, если дальнейший перебор не требуется, и true для продолжения.
template <int = AF_INET> inline void enumInterfaces(std::function<bool(in_addr, in_addr)> fn);
 
template <>
inline void enumInterfaces<AF_INET>(std::function<bool(in_addr, in_addr)> fn)
{
#ifdef WINHOST
  ULONG reqSize = 0;
 
  // получить список адаптеров... а, нет, тут только их количество
  if (ULONG retCode = GetAdaptersInfo(NULL, &reqSize); retCode != ERROR_BUFFER_OVERFLOW)
    throw APIerror("GetAdaptersInfo() fails.", retCode);
 
  // во, количество получили
  std::vector<unsigned char> infoBuffer(reqSize);
  IP_ADAPTER_INFO           &info = reinterpret_cast<IP_ADAPTER_INFO&>(infoBuffer.front());
 
  // получить список адаптеров
  if (ULONG retCode = GetAdaptersInfo(&info, &reqSize); retCode != ERROR_SUCCESS)
    throw APIerror("GetAdaptersInfo() is failed.", retCode);
  // проходим по списку интерфейсов и зовём fn
  for (PIP_ADAPTER_INFO adapter = &info; adapter != NULL; adapter = adapter->Next)
  {
    in_addr curAddr, netMask;
 
    curAddr.S_ADDR = inet_addr(adapter->IpAddressList.IpAddress.String);        // подсеть
    if (curAddr.S_ADDR == 0) continue;                                          // отключён
    netMask.S_ADDR = inet_addr(adapter->IpAddressList.IpMask.String);           // её маска
 
    if (!fn(curAddr, netMask)) break;
  }
#else
  ifconf conf;                                  // здесь будет массив описаний интерфейсов
  int    fd = socket(AF_INET, SOCK_DGRAM, 0);   // для работы с интерфейсами нужен сокет
 
  if (fd < 0) throw Sockets::socket_error("Enum: socket() fails", WSAGetLastError());
          
  constexpr size_t  value_size = sizeof(ifreq);
  std::vector<char> buf;                        // буфер под массив, размер пока неизвестен
 
  try
  {
    // определить этот размер
    do
    {
      // увеличить размер буфера в полтора раза (в единицах размера ifreq)
      buf.resize(value_size * (buf.size()/value_size * 3/2 + 1));
      // запросить информацию
      conf.ifc_len = buf.size();
      conf.ifc_buf =&buf.front();
      if (ioctl(fd, SIOCGIFCONF, &conf) != 0)
        throw Sockets::socket_error("Enum: ioctl(SIOCGIFCONF) fails", WSAGetLastError());
      // пока возвращённый размер совпадает с запрошенным, предполагаем, что буфер недостаточен
    } while (conf.ifc_len == buf.size());
 
    // теперь массив гарантировано может быть получен полностью
    const ifreq *req = reinterpret_cast<ifreq*>(conf.ifc_req);
 
    // перебираем все интерфейсы
    for (int i = 0; i < conf.ifc_len; i += value_size, ++req)
    {
      std::string host(16, ' ');        // для адресов IPv4 этого хватит
      ifreq       curReq;
      in_addr     curAddr, netMask;
 
      // получаем адрес интерфейса (sockaddr)
      std::copy_n(std::begin(req->ifr_name),
                  std::min(std::string_view(req->ifr_name).length() + 1, host.size()),
                  std::begin(curReq.ifr_name));
      if (ioctl(fd, SIOCGIFADDR, &curReq) != 0) continue;       // интерфейсы с ошибками не интересуют
      if (curReq.ifr_addr.sa_family != AF_INET) continue;       // интересуют только AF_INET
      // получаем адрес хоста в виде имени
      // (единственный независимый от конкретизации sockaddr вариант)
      if (getnameinfo(&curReq.ifr_addr, sizeof curReq.ifr_addr,
                      &host.front(), host.size(), 0, 0, NI_NUMERICHOST) != 0)
        throw Sockets::socket_error("getnameinfo() fails", WSAGetLastError());
      // переводим адрес в in_addr
      curAddr.s_addr = inet_addr(host.c_str());
      // получаем маску подсети интерфейса
      if (ioctl(fd, SIOCGIFNETMASK, &curReq) != 0)
        throw Sockets::socket_error("Enum: ioctl(SIOCGIFNETMASK) fails", WSAGetLastError());
      netMask = ((sockaddr_in*)&curReq.ifr_netmask)->sin_addr;
      if (!fn(curAddr, netMask)) break;
    }
  }
  catch(...)
  {
    close(fd);
    throw;
  }
  close(fd);
#endif
}
 
} // Sockets
 
#endif

Жесть и тихий ужос по сравнению с WinAPI

Добавлено 03.12.24, 18:51
P.P.P.S. Кто в коде заметит махонький ай-яй-яй, тому плюсик в карму

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 03.12.24, 18:36

P.P.P.S. Кто в коде заметит махонький ай-яй-яй, тому плюсик в карму

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

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Ну это не считается. При копировании зацепился страж включения – это же фрагмент заголовка, самый конец – и namespace.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 03.12.24, 22:48

Ай-яй не увидел

Но мне не понравился алгоритм выделения буфера под интерфейсы. Я бы написал согласно доке на ioctl так:

        // определить этот размер
        // запросить информацию
        conf.ifc_len = 0;
        conf.ifc_req = NULL;
        if (ioctl(fd, SIOCGIFCONF, &conf) != 0)
            throw Sockets::socket_error("Enum: ioctl(SIOCGIFCONF) fails", WSAGetLastError());
 
        std::vector<char> buf(conf.ifc_len);
        conf.ifc_len = buf.size();
        conf.ifc_buf = &buf.front();
        if (ioctl(fd, SIOCGIFCONF, &conf) != 0)
            throw Sockets::socket_error("Enum: ioctl(SIOCGIFCONF) fails", WSAGetLastError());
 
        // теперь массив гарантировано может быть получен полностью
        const ifreq* req = reinterpret_cast<ifreq*>(conf.ifc_req);

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: sharky72 - 09.12.24, 14:16

sharky72, я бы с удовольствием, было б примерно как в WinAPI, та вот только POSIX он такой POSIX... Ты пишешь по linux mans, а как быть с openmans? Вот описание:

Цитата

SIOCGIFCONF
Возвращает список адресов интерфейса (транспортный уровень). Для поддержки совместимости в данный момент возвращаются только адреса семейства AF_INET (IPv4). Пользователь передает в качестве аргумента вызова ioctl структуру ifconf. Она содержит в поле ifc_req указатель на массив структур ifreq, а в поле ifc_len - его длину. Ядро заполняет структуры ifreq всеми текущими адресами третьего уровня (L3), связанными с интерфейсом и являющимися активными: ifr_name содержит имя интерфейса (eth0:1 и т.п.), ifr_addr содержит адрес. Ядра устанавливают длину массива равной ifc_len. Если ifc_len равно начальной длине, то пользователь должен предположить, что буфер переполнен, и попробовать еще раз проделать то же самое с буфером большего размера, чтобы в него поместились все адреса. Если ошибок не было, то ioctl возвращает 0, в противном случае -1. Переполнение не является ошибкой.

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

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Majestio @ 05.12.24, 12:34

Ну можно замутить отдельную тему для общего участия. Но я бы принял участие только при одном условии - использование Шаблонов проектирования банды четырех

Вот в перехвате и получении диагностики ничего такого
смастерить не получается.
И не нужно придумывать что-то специально.
А вот в выводе полученной диагностики - да.
Само получилось, без натягивания совы на глобус.
---
Объект получился с характерными признаками декоратора
и наблюдателя одновременно. Реальная жизнь
интереснее голых схем.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 05.12.24, 16:02

Мда... И эти люди еще хаят WinAPI

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата ЫукпШ @ 05.12.24, 16:03

И не нужно придумывать что-то специально.

По сути, если я не ошибаюсь, следующий Си-подобный костыль, который маскируется под С++, нужно было бы как-то оформить ...

Цитата sharky72 @ 05.12.24, 11:39

if (ioctl(fd, SIOCGIFCONF, &conf) != 0)
            throw Sockets::socket_error("Enum: ioctl(SIOCGIFCONF) fails", WSAGetLastError());

Допустим вынести все ioctl вызовы в класс ClassIoctl, который будет выступать либо "адаптером", либо "фасадом"? Не?

Для *никсов что-то типа (упрощённо):

#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdexcept>
 
class ClassIoctl {
private:
    int fd; // Дескриптор файла
 
public:
    ClassIoctl(const char* device) {
        fd = open(device, O_RDWR);
        if (fd < 0) {
            throw std::runtime_error("Не удалось открыть устройство");
        }
    }
 
    ~ClassIoctl() {
        close(fd);
    }
 
    template<typename T>
    void executeIoctl(unsigned long request, T& arg) {
        if (ioctl(fd, request, &arg) < 0) {
            throw std::runtime_error("Ошибка выполнения ioctl");
        }
    }
};

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

И не говори, sharky72.
Majestio, ну и нахрена мне сдалось городить огород вокруг ...э-э-э, стандартного (? серьёзно? оно теперь так называется?) API? В WinAPI любые последующие ревизии никогда не изменяют и тем более отменяют предыдущие без того, чтобы завести новые и объявить что-то там deprecated, и впоследствии, дав время на порт, начать возвращать на старое GetLastError(). Мне же одних только этих берклиевых сокетов по горло хватило. С их 100500 несовместимых между собой вариантов. Куда не ткни, куча ноутов и фичей для всякоразных "единых" POSIX-реализаций. Танунафик этот nix, пусть себе и дальше форкает свои ядра наздоровье.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: Qraizer - 09.12.24, 14:16

Цитата Qraizer @ 05.12.24, 18:22

Majestio, ну и нахрена мне сдалось городить огород вокруг ...э-э-э, стандартного (? серьёзно? оно теперь так называется?) API? В WinAPI любые последующие ревизии никогда не изменяют и тем более отменяют предыдущие без того, чтобы завести новые и объявить что-то там deprecated, и впоследствии, дав время на порт, начать возвращать на старое GetLastError(). Мне же одних только этих берклиевых сокетов по горло хватило. С их 100500 несовместимых между собой вариантов. Куда не ткни, куча ноутов и фичей для всякоразных "единых" POSIX-реализаций. Танунафик этот nix, пусть себе и дальше форкает свои ядра наздоровье.

ну на нет и суда нет (и туда нет)

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 05.12.24, 18:22

И не говори, sharky72.
Majestio, ну и нахрена мне сдалось городить огород вокруг ...э-э-э, стандартного (? серьёзно? оно теперь так называется?) API? В WinAPI любые последующие ревизии никогда не изменяют и тем более отменяют предыдущие без того, чтобы завести новые и объявить что-то там deprecated, и впоследствии, дав время на порт, начать возвращать на старое GetLastError(). Мне же одних только этих берклиевых сокетов по горло хватило. С их 100500 несовместимых между собой вариантов. Куда не ткни, куча ноутов и фичей для всякоразных "единых" POSIX-реализаций. Танунафик этот nix, пусть себе и дальше форкает свои ядра наздоровье.

Сравниваешь разные контексты. POSIX про разные ОС (не разные версии одной, а именно разные ОС), WinAPI - про одну.
Конкретно под linux или конкретно под FreeBSD, или конкретно под macOS ты сможешь найти более стабильные и удачные решения (наверное, или они забили и сделали только POSIX). И так же для ecos, QNX и пр. и пр.
Можно сколько угодно ругать POSIX, как "стандарт", но лучшего пока нет. И я не знаю, нужен ли. Но winapi это просто API конкретной ОС, а не стандарт.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: D_KEY - 09.12.24, 14:16

D_KEY, и от этого должно сразу стать легче, что ль? Я пишу под Windows, и у меня WinAPI. Я пишу под nix, и у меня зоопарк. Мне глубоко фиолетово, что это разные ОС, ибо Windы тоже разные, но есть стандарт. POSIX не стандарт, так что этот хвалёный опенсоурс пусть идёт лесом, платный саппорт мне его не окупит. А вот бесплатный проприетарный мне ничего не будет стоить. Чисто экономически стоимость владения проприетарной ОСью для разработчиков в разы выгоднее.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 07.12.24, 21:08

Я пишу под nix, и у меня зоопарк.

А ты выбери конкретный *nix и зоопарка не будет.

Добавлено 07.12.24, 21:22

Цитата Qraizer @ 07.12.24, 21:08

ибо Windы тоже разные, но есть стандарт.

Винды разные версии, но ОС одна.

Цитата

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

Все в одну кучу у тебя что-то. Опенсорс, проприетарность и nix. Это все разные вещи. macOS тоже nix, например.

Но это уже оффтопик.

Добавлено 07.12.24, 21:24
P.S. Когда я писал на winapi - это был самый ужасный период моей жизни, как разраба

Сорри за оффтоп

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

D_KEY, ну не прикидывайся, что не понимаешь разницы между "разные ОС" и "разные API".

Добавлено 08.12.24, 08:29

Цитата D_KEY @ 07.12.24, 21:20

Сорри за оффтоп

Та вот думаю, где тему резануть и в Холивары хвост скинуть...

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Qraizer @ 08.12.24, 08:29

D_KEY, ну не прикидывайся, что не понимаешь разницы между "разные ОС" и "разные API".

POSIX - это попытка описать API, который бы подходил для очень разных ОС. И на практике так и есть. Но иногда это действительно проблема.
WinAPI - это только для одного семейства и разработанный конкретной компанией. Совершенно разные задачи.
И то, что твоя ОС соответствует POSIX, не запрещает тебе делать другое API. Смотри ту же macos, например. У них очень много своего API. Т.о. если ты работаешь с конкретным семейством ОС, то у тебя есть и дополнительные фичи и стабильность и пр.

Т.е. сравнивать winapi и posix напрямую несколько странно. Цели разные.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата D_KEY @ 08.12.24, 12:07

POSIX - это попытка описать API, который бы подходил для очень разных ОС. И на практике так и есть. Но иногда это действительно проблема.

В чем проблема описывать что-то вроде библиотеки с приведенными под общий знаменатель вызовами на каждой из платформ и скрывающей различия этих платформ вроде HAL. Но на деле POSIX это просто какая-то солянка. Как хочу так и ворочу. За столько времени уже можно было сделать что-то вроде POSIX2 где переработать все и привести в порядок. Тем более, что кардинально нового ничего по сути не появляется уже давно.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата macomics @ 08.12.24, 17:04

За столько времени уже можно было сделать что-то вроде POSIX2 где переработать все и привести в порядок.

И переписать потом весь код, который написан за это время

В этом же основная проблема.

Плюс новая версия не уверен, что кому-то нужна. Напрямую на posix вряд ли кто-то пишет сейчас. Только в некоторых случаях.

Но вообще, кто мешает-то? Напишите новую версию POSIX, убедите всех создателей ОС ее использовать. Делов-то

Добавлено 09.12.24, 00:29
Т.е. даже если вынести за скобки то, что сейчас в подавляющем большинстве случаев люди будут использовать разные кроссплатформенные библиотеки, даже если вы решите сами работать на системном уровне, то вряд ли кто-то станет юзать, например, posix'овые select/poll. Потому что в зависимости от ОС, у вас будут более эффективные средства. Такие как epoll в линукс и kqueue в freebsd. А сейчас в линуксе есть и относительно новая штука - io_uring (которая уже относительно близка к iocp виндовой, хотя и получше).
И вот только если вам нужны именно другие ОС, вы можете сделать и posix версию. И в этом сила posix - минимум, который будет работать (условно) "везде".

Кстати, если залезть в потроха какого-нибудь asio, вы примерно это и увидите - специальные версии для разных ОС(linux, bsd, win) и posix "на сдачу".

А "обычному" программисту вообще достаточно использовать библиотеки.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: D_KEY - 09.12.24, 14:11

Цитата D_KEY @ 08.12.24, 23:55

И переписать потом весь код, который написан за это время

Я только за. Избавиться от кучи нагромождений и совместимостей. Создать новую ОС по уже известным характеристикам с начала. На первое время можно просто сделать порт POSIX->POSIX2, а вот как основной API в ней оставить именно POSIX2.

Можно же иногда взять и переделать с самого начала и получить лучший результат (не набивать шишки заново в творческом процессе).

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Qraizer,

Цитата Qraizer @ 03.12.24, 18:36

.P.S. Хотя лучше этот ваш POSIX никогда не трогать. Вообще. Вот сравни просто одну-единственную функцию-перечислитель сетевых интерфейсов.

Вот тут предлагаю "разрезать" тему, а хвост перенести в Холивары, допустим, с названием "POSIX vs WinAPI".
А то мы пошли куда-то в другую степь. В этой теме должны остаться вопросы проектирования обработки программных ошибок и/или ситуаций на С++.

M

Ну, не так всё просто, ещё б посты если можно было пополам порезать... И тем не менее некий вот такой Done.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: Qraizer - 09.12.24, 14:14

Цитата macomics @ 09.12.24, 02:11

Цитата D_KEY @ 08.12.24, 23:55

И переписать потом весь код, который написан за это время

Я только за. Избавиться от кучи нагромождений и совместимостей. Создать новую ОС по уже известным характеристикам с начала. На первое время можно просто сделать порт POSIX->POSIX2, а вот как основной API в ней оставить именно POSIX2.

Можно же иногда взять и переделать с самого начала и получить лучший результат (не набивать шишки заново в творческом процессе).

Вы то может и за, но кто это все будет делать? И зачем? Будут ли за компании, которые создают ОС? Будут ли за свободные разработчики, которые контрибьютят в тот же линукс и другие открытые ОС? Вы себе представляете объем работы? А объем согласований между всеми этими агентами?
По-моему это абсолютно утопичная идея

Добавлено 09.12.24, 09:09
То, что у нас есть хотя бы такой posix, какой есть, - это уже почти чудо.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата D_KEY @ 09.12.24, 09:08

Будут ли за компании, которые создают ОС?

Их еще забыли спросить.

Цитата D_KEY @ 09.12.24, 09:08

И зачем?

Тут об этом написано

Цитата D_KEY @ 09.12.24, 09:08

Вы себе представляете объем работы? А объем согласований между всеми этими агентами?

Это дело не для одиночки. Если будет заинтересована компания, тогда возможно. Но там уже будет жесткая иерархия и ваши вопросы будут лишними.

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Сообщение отредактировано: Qraizer - 09.12.24, 14:38

Цитата macomics @ 09.12.24, 10:13

Цитата D_KEY @ 09.12.24, 09:08

Будут ли за компании, которые создают ОС?

Их еще забыли спросить.

А кто будет реализовывать новый стандарт?

Добавлено 09.12.24, 11:46

Цитата macomics @ 09.12.24, 10:13

Это дело не для одиночки. Если будет заинтересована компания, тогда возможно. Но там уже будет жесткая иерархия и ваши вопросы будут лишними.

Какая компания? Ещё раз, posix про стандарт между компаниями (и сообществами) и между разными ОС.

Добавлено 09.12.24, 11:47

Цитата macomics @ 09.12.24, 10:13

Если будет заинтересована компания, тогда возможно. Но там уже будет жесткая иерархия и ваши вопросы будут лишними.

Ну вы получите "ещё одни стандарт", который будет использоваться скорее всего только этой компанией (а значит реальным стандартом для отрасли не будет).

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Прикреплённая картинка

Добавлено 09.12.24, 11:54
А posix реально работающий стандарт. Поэтому, ИМХО, развитие возможно только эволюционное и постепенное. В 2024 году вроде вышла новая версия, кстати. Я не смотрел еще (нет необходимости сейчас).

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата macomics @ 09.12.24, 10:13

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

Ох уж эти "если" Всё новое - это надёжно забытое старое. Но я позволю себе напомнить... Была когда-то суперская и казалось-бы топ-перспективная система для десктопов и серверов OS/2. Я на ней просидел (если уже не ошибаюсь) с 1994 по 1997 год. Что тогда прямо лилось елеем на душу - так это реализация многозадачности! На то время эта ось исполняла нативные задачи Windows 3.1 лучше самой виндовс! Прикинь стек задач: идет архивация толстенного набора каталогов, параллельно на стриммер (это писец-писец-писец капризное устройство!!!) пишется предыдущий архив, а я сидю и кодю! И все плавно, и все без задержек, без залипаний, и без зависаний! И каков итог?!!! "Заинтересованная" компания IBM разосралась с тогдашним партнёром Microsoft Co., и как итог - проект издох. И потом получилось то, что сейчас радует Qraizer'а. Второй пример. Операционная система QNX. Кстати, когда-то считавшаяся наиболее POSIX-совместимой (её релиз 1982 год, я тогда вообще в школе учился). Казалось бы - на, первопроходец, держи флаг. Но нет! В 1991 году выходит это ваш Люникс. Почему выходит спустя 9 лет от начала выпуска оч-оч-оч неплохой *nix системы QNX? Ответ на поверхности - злобная жадность создателей сраных кровавых буржуев QNX. Ну и где они щас? Спрятались в банкоматах, умных домах, возможно в каких-то еще незаметных встраиваемых хреновинах, типа умных космических писуаров.

И к чему мой спич?! Любая "заинтересованная компания" имеет свою "заинтересованность" в чистой прибыли, и ни как иначе! Вообще, и ни как, и не иначе!. Поэтому, macomics, твои радужные перспективы - не что иное, как мечты IT-отрока протуберантного периода развития. И в своих рассуждениях, D_KEY'я я тут считаю более правым. Хотя его политические взгляды ... ух блин... Лан, это другой вопрос.

Скрытый текст

Но только без обид! Только без них самих!!! Если где-то я стебанулся чуть за гранью, прошу меня извинить

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата Majestio @ 09.12.24, 12:15

И к чему мой спич?! Любая "заинтересованная компания" имеет свою "заинтересованность" в чистой прибыли, и ни как иначе!

Никаких обид. Просто может же быть гос.компания, которая прибыль будет получать с этого. Сейчас бы уже пора. Даже линукс уже поплыл санкциями баловаться. Российских маинтейнеров ядра решил выбрасывать. Как итог, я считаю, взяться за свою реализацию, а не тупо собирать дистры на базе *nix. В целом взгляд может и идеалистичный, но вполне сейчас востребованный (должен быть).

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата macomics @ 09.12.24, 13:39

Просто может же быть гос.компания, которая прибыль будет получать с этого. Сейчас бы уже пора. Даже линукс уже поплыл санкциями баловаться. Российских маинтейнеров ядра решил выбрасывать. Как итог, я считаю, взяться за свою реализацию, а не тупо собирать дистры на базе *nix. В целом взгляд может и идеалистичный, но вполне сейчас востребованный (должен быть).

На уровне распила госбюджета может быть всё - даже невозможное! Но следует делать поправку на менталитет - время "Стахановых" давно ушло в прошлое. Как ни обидно, но сейчас большее беспокойство вызывает не какие-то "отставания" от Запада, а мерзопакастное воровство государственных чиновников. До блевотины. Особенно читаешь, когда ловяят очередного борцуна по порьбе с коррупцией ... на коррупции. Сюрр ппц.

macomics, да, если бы была "воля государства" - это возможно бы было. Но куча многих "но". Два из которых "целесообразность" и "ценность" (да, они где-то как-то пересекаются). У государства еще куча проблем - чем латать мешки алигархов, которые лопаются от злата. Куча жилых посёлков, в которых туалеты на улице в виде обычных срачей из двух досок. А ты про POSIX2 на уровне госфинансирования? Отсыпь мне тоже немного!

Это сообщение было перенесено сюда или объединено из темы ""обработка исключений" vs "обработка кодов возврата""

Цитата D_KEY @ 08.12.24, 12:07

POSIX - это попытка описать API, который бы подходил для очень разных ОС. И на практике так и есть. Но иногда это действительно проблема.

Та нет же. Это не проблема, что API ОСей отличаются. Вон, есть же Стандарт языка и есть агромадная куча несовместимых друг с другом его реализаций. Проблема-то в том, что несовместимые реализации Стандарта языка совместимы однако с самим Стандартом, тогда как реализации POSIX делают вид, что они совместимы с POSIX, а по факту нет. Мне чтобы написать полностью переносимое POSIX-приложение придётся опуститься до уровня его API образца эдак 199x-ых и лишиться всего его 30 летнего последующего развития. А чтобы воспользоваться этим развитием, оно же вкусное как-никак, я обязан буду сосредотачиваться на его частных реализациях и с головой окунуться в ад портабельности и саппорта. Да-да, есть библиотеки, которые вроде бы должны это брать на себя. Вот только это самое «бы». Ад просто сменил место дислокации и теперь не в POSIX, а в этих библиотеках, потом что у них точно такая же трабля.

Добавлено 09.12.24, 14:45

Цитата Majestio @ 09.12.24, 12:15

"Заинтересованная" компания IBM разосралась с тогдашним партнёром Microsoft Co., и как итог - проект издох. И потом получилось то, что сейчас радует Qraizer'а.

Ну, "разосралась" тут неуместно. У них кончился 10-летний контракт, и не стали перезаключать. Если там и были тёрки, послужившие причиной, то вряд ли их можно описать таким эпитетом. Что до Win32 API, так он и разрабатывался по заказу самой IBM для использования в её OS/2, которая по итогу должна была выйти как OS/2 NT или как-то так. Просто посмотрев на маркетинговые успехи MS и сравнив их со своими, IBM решила воспользоваться услугами профессионалов для продвижения своей ОСи. В частности снабдив MS своими консультантами по созданию качественных 32-битных ОСей. Ну и т.к. контракт истёк до финала, разработку MS бросать в мусорник не хотела, то просто выкупила права и переобозвала как Windows NT.

Цитата Qraizer @ 09.12.24, 14:36

Это не проблема, что API ОСей отличаются.

Дружище - тут ты в корне не прав! Это ОСНОВНАЯ и "КОРНЕВАЯ" ПРОБЛЕММА. Разные оси "проповедуют" разное. А что разное? Разное много: определение процессов и потоков на уровне ядра, определение понятия ресурсов и его захватов, определение "железа" и его отображения во внутренние сущности, да много чего из. Это большая проблема! Многие ОСи не просто "разговаривают" на разных языках, они часто разговаривают "разными способами". В этом плане я как-то где-то даже поддерживаю macomics в его презентации HAL, как способа унификации. Но, увы, тут HAL+1 будет на порядок-два сложнее. Не аргументирую, чисто чуйка. Но это, думаю, лучший варик компромиссов кросс-разработок. Но туман тут, к гадалке не ходи!

Majestio, было бы желание, это решаемо, и весьма недорого. Но ведь желания-то как раз и нет. Та ёлки ж:

Цитата dup(2) — Linux manual page

The error returned by dup2() is different from that returned by fcntl(..., F_DUPFD, ...) when newfd is out of range. On some systems, dup2() also sometimes returns EINVAL like F_DUPFD.

Их за ногу — серьёзно??! Вот это вот Стандарт на API? В котором функция может вести себя по-разному по желанию левой пятки очередного форкера? Когда две функции, выполняющие априори одинаковое действие, работают по-разному?!
Не надо защищать очевидное фуфло. И пожалуйста, не называйте POSIX экосистемой. Зоопарк экосистем – согласен.

Сообщение отредактировано: Qraizer - 09.12.24, 15:00

Цитата Qraizer @ 09.12.24, 14:36

Что до Win32 API, так он и разрабатывался по заказу самой IBM для использования в её OS/2, которая по итогу должна была выйти как OS/2 NT или как-то так.

Нет. Ну я "со свечкой не стоял". Но там был разрыв ни "до" и не "после". А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ Впереди маячило лютое бабло.

Опять же, я рядом не стоял. Но ты сам прикинь - IBM с кучей баблищя, рядом толковые недооцененные Мелкомягкие. Они щито, по-твоему, могли чисто по-братски разойтись краями?

Цитата Qraizer @ 03.12.24, 18:36

P.S. Я тем не менее с удовольствием посмотрел бы на транслятор сигналов POSIX в C++EH хотя бы краем глаза.

Разные реализации JVM делают подобное для java. Можно там поглядеть.

Я как-то делал костыли тоже сто лет назад, но код не найду уже

Qraizer, сорян, туплю!
Ты вообще о чем? Приведи плс примеры, которые мы вместе с тобой сперва будем гнобить, а потом попробуем порешать. А пока это только твой взрыв негодований.
Давай по полкам? В плане действий - ты делаешь "я сделал всё по доке посикса, а оно-говно не работает". Мы вместе все смотрим. Oke?

Цитата Qraizer @ 09.12.24, 14:36

тогда как реализации POSIX делают вид, что они совместимы с POSIX, а по факту нет

Ну так они и не сертифицированы linux официально не posix (не сертифицирован), хотя по факту большинство важные вещей использовать можно.

Добавлено 09.12.24, 15:15

Цитата Qraizer @ 09.12.24, 14:36

Мне чтобы написать полностью переносимое POSIX-приложение придётся опуститься до уровня его API образца эдак 199x-ых и лишиться всего его 30 летнего последующего развития.

Верно. Но никакой альтернативы не существует. С чем ты сравниваешь? winapi-то вообще не переносимо

Цитата Qraizer @ 09.12.24, 14:36

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

Да. Я сам описал выше кейс с epoll/io_uring/kqueue/etc. vs select/poll.
Но вопрос тот же. С чем ты сравниваешь?

Цитата Qraizer @ 09.12.24, 14:36

Да-да, есть библиотеки, которые вроде бы должны это брать на себя. Вот только это самое «бы». Ад просто сменил место дислокации и теперь не в POSIX, а в этих библиотеках, потом что у них точно такая же трабля.

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

Сообщение отредактировано: D_KEY - 09.12.24, 15:16

Qraizer, конечно шютка но у тебя есть возможность стать POSIX-совместимым модератором исходников. Просто пройди тест сертификации!

Ну я не буду Джордано Бруно, и не открою вам секреты мироздания, но кернель спейс и юзер спейс - это всего лишь абстракции. У каждной оси есть свои, скажем так, "области ответственности" для кернеля и юзерспейса. И не для никого не секрет, что если в юзерспейсе что-то запрещено, то мы пишем дрова, и оно, волшебным образом становится/может становиться разрешено. Вывод - везде можно сделать всё!

Но как говорили многие ораторы в этой теме - важно "договориться". Для кросс-платформеров вопрос возможностей уже. Для видовс-фагов он почти 100% в своей области. Но нет ничего абсолютно нерешаемого. Цитирую DKE_Y:

Цитата D_KEY @ 09.12.24, 15:11

Ну так библиотеки (хорошие) ты просто используешь, не задумываясь об ОС. Тот же asio тому пример.

Или, например, libevent.

Другой вопрос кросс-соместимости по всем 100% возможностей разных осей А кто сказал, что вы в сказку попали?

В общем, winapi можно сравнивать с конкретным API конкретной ОС. Например, macos (которая тож posix, если что). Сравнивать же непосредственно с posix можно будет тогда, когда winapi будет использоваться разными ОС от разных производителей.

D_KEY, а чем тебе Windы не разные ОСи? Притом, что родной API для NT линейки вообще ни разу не Win32, а т.н. Native API. Сравни возможности Win32s, упомянутый Majestio костыль для 16-битных Win3xx, Win32c сиречь отменённое обозначение Win32 для Win9x, настоящее Win32 для исходно 32-битных NT до WinXP включительно и нынешнее Win32 под современные Win7/8/10/11, включая редакции для 64-битных ОСей. (Одно время MS хотела, впрочем, отказаться от процедурного API в Win8, заставив всех перейти на объектный API из .NET, но слава богу передумала пересаживать разработчиков исключительно в универсальные приложения, так что классические до сих пор в ходу и ещё долго будут в ходу.) Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Добавлено 09.12.24, 19:47

Цитата Majestio @ 09.12.24, 15:04

А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ

Та не. Win32s (s означает subset, кажется) не планировалась, но в итоге была выпущена для облегчения миграции разработчиков под ...хм, правильные 32-битные ОСи. И это неплохо получилось, я на Win3.1 + Win32s сидел аж до 98-го года, пока не вышла Win98SE, и у меня всё мне нужное работало. Игры под DirectX не работали, да, но тогда это не имело значения, аппаратный рендер был ещё в диковинку. Имеет ли это какое-то отношение к разрыву сотрудничества, ну... честно не знаю, но сомневаюсь.

Добавлено 09.12.24, 19:56
P.S. Решил погуглить и нашёл вот такую статью. Похожа на объективную. Краткое резюме: IBM захотела занять нишу системного ПО для своих же ПК, вытеснив т.с. с рынка Microsoft, последняя решила побороться и выиграла.

Добавлено 09.12.24, 19:59

Цитата Majestio @ 09.12.24, 15:17

Просто пройди тест сертификации!

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

Цитата Qraizer @ 09.12.24, 19:39

D_KEY, а чем тебе Windы не разные ОСи?

Тем, что это версии одной ОС и производства одной компании. Не смотря на разные технологии и их развитие. Это суть не меняет. У них коммерческая задача - сохранить совместимость.

Добавлено 09.12.24, 20:34

Цитата Qraizer @ 09.12.24, 19:39

Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Так это одна компания, конечно, она будет бороться за совместимость. Кто будет обновлять ОС, если старые программы перестанут работать?

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

Я тебя не понимаю, честно.
Вот живет одна компания, которая одна делает свою ОС. Конечно, она обеспечивает совместимость. Конечно, у нее будет более заточенное под ее применимость API.

Тут скорее нужно удивляться, почему winapi такое уродливое. Вон macos современный вообще вполне себе хорошо живет еще и с новым нормальным языком (swift), при этом сохраняя совместимость с их старым objective-С (который, кстати, совместим с Си). И там как-то симпатичнее все выглядит.
И сравни с winapi, на котором никто сейчас писать программу не станет, возьмет либы.

Сообщение отредактировано: D_KEY - 09.12.24, 21:02

Ну раз мы уже в холиварах, то наброшу.
WinAPI не способна даже определиться с тем, что является кривым HANDLE: INVALID_HANDLE_VALUE или NULL (или -1 для 16битных версий, впрочем об этом уже можно забыть). А это ведь базовая вещь, о чем тут вообще можно говорить?

Сообщение отредактировано: D_KEY - 09.12.24, 21:02

struct unique_fd
{
    explicit unique_fd(int fd = -1) noexcept
        : fd_(fd)
    {
    }
 
    unique_fd(const unique_fd &) = delete;
    unique_fd& operator=(const unique_fd &) = delete;
 
    unique_fd(unique_fd && other) noexcept
        : fd_(other.release())
    {
    }
 
    unique_ptr& operator=(unique_ptr&& other) noexcept
    {
        reset(other.release());
 
        return *this;
    }
 
    ~unique_fd()
    {
        reset(-1);
    }
 
    void reset(int fd) noexcept
    {
        if (fd_ != -1)
            ::close(fd_);
        fd_ = fd;
    }
    
    [[nodiscard]] int release() noexcept
    {
        int res = fd_;
        fd_ = -1;
        return res;
    }
 
    int get() noexcept
    {
        return fd_;
    }
 
private:
    int fd_;
};

Вот еще упражнение, написать для winapi с той же степенью применимости для объектов разного рода (файлов, сокетов, pipe, ...).

P.S. код не проверял, сильно не пинайте. Идея, надеюсь, понятна.

Сообщение отредактировано: D_KEY - 09.12.24, 21:51

D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.
...
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects

Те в натуре серьёзно думаешь, что однотипное API для разнородных объектов является преимуществом? Ну, даже если натянуть сову и предположить, что это преимущество... POSIX вон не может стравиться даже с гарантиями безотказности атомарной операции для одного типа объектов. Давай уже не надо, правда. Если ты считаешь WinAPI уродским, то интересно почему. Я вот припоминаю, как ругался на то или иное, но поразмыслив всегда приходил к выводу, что это сделано намерено по вполне объективным причинам. Один из таких примеров – как раз отделение INVALID_HANDLE_VALUE от NULL в ряде применений ради обеспечения отсутствия утечек ресурсов и гарантий атомарности сложных операций во многозадачных средах. Я вот считаю POSIX спроектированным каким-то индусом без школьной информатики за плечами, и пояснил, почему. Я даже не могу элементарный контейнер из сокетов создать, потому что по факту сокеты полиморфны, а в API они тупо int. Нафик эту однотипность.

Добавлено 10.12.24, 13:47

Цитата D_KEY @ 09.12.24, 20:27

У них коммерческая задача - сохранить совместимость.

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

Добавлено 10.12.24, 13:49

Цитата D_KEY @ 09.12.24, 20:27

По поводу отсутствия читов и недокументированных особеностей почитай что пишут разработчики wine.

Скажем так: это не проблема API. Я в своём тесте чего-то там могу сломать любой его функционал, но это не значит, что функционал плохо спроектирован.

Сообщение отредактировано: Qraizer - 10.12.24, 13:55

Qraizer, я позволю себе поддержать ДиКея
Ты просто пойми, что линупсы и их апдейты растут как грибы - и гораздо чаще твоей сраной венды апдейтяться! И самое главное, а ни не просто растут - а выставляют стабильные и LTS ветки. Когда твоя венда делала раз в пятилетку (максимум). Я понимаю твою "любовь" в виндам, но мир меняется. И не меняться с ним себе дороже.

Цитата Qraizer @ 10.12.24, 13:36

D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.
...
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects

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

А отложенная запись нужна для оптимизаций и в реальном софте хорошо себя показывает. Для случаев, когда нужно флашить на диск, ты можешь это специально делать.
За многопоточкой тоже сам следишь, это тож во многом позволяет не накручивать лишней синхронизации со стороны ОС на ровном месте.

Так будет код-то? Или просто на словах признаешь, что придется писать одинотипные обертки для каждого случая?

Цитата Qraizer @ 10.12.24, 13:36

Те в натуре серьёзно думаешь, что однотипное API для разнородных объектов является преимуществом?

Они не разнородны в достаточном смысле для использующего их программиста

Цитата Qraizer @ 10.12.24, 13:36

Если ты считаешь WinAPI уродским, то интересно почему.

Зоопарк разнородных подходов (пример привел выше с handle), функции с миллионом параметров, монструозные структуры данных и т.д. и т.п.

Для одной компании и одной ОС - странно.

Цитата Qraizer @ 10.12.24, 13:36

Один из таких примеров – как раз отделение INVALID_HANDLE_VALUE от NULL в ряде применений ради обеспечения отсутствия утечек ресурсов и гарантий атомарности сложных операций во многозадачных средах.

Можешь подробнее рассказать? Это может быть интересным.

Цитата Qraizer @ 10.12.24, 13:36

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

По-моему, не пояснил. Плюс продолжаешь игнорировать, что он для огромного числа совершенно разных ОС.

Цитата Qraizer @ 10.12.24, 13:36

Я даже не могу элементарный контейнер из сокетов создать, потому что по факту сокеты полиморфны, а в API они тупо int.

Поясни, пожалуйста. Не понял.

Цитата Qraizer @ 10.12.24, 13:36

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

При чем тут вообще opensource? Есть и закрытые posix ОС

Цитата Qraizer @ 10.12.24, 13:36

Скажем так: это не проблема API.

Это проблема наличия только одной "настоящей" реализации API.
Впрочем, это вообще не проблема.

Никто на winapi уже почти и не пишет.

Сообщение отредактировано: D_KEY - 10.12.24, 16:32

Зато чет захотелось прям понастольгировать и какую-нибудь кроссплатформенную шляпу запилить. Может что-то на тему iocp, io_uring и пр. (ну и kqueue тож сделать и потом на сдачу posixовый select/poll), но, в отличие от asio, например, накрутить там реактивные стримы или еще чего другого придумать, чтобы оправдать существование поделки

Цитата Majestio @ 10.12.24, 14:47

Ты просто пойми, что линупсы и их апдейты растут как грибы - и гораздо чаще твоей сраной венды апдейтяться! И самое главное, а ни не просто растут - а выставляют стабильные и LTS ветки.

Ну так я и назвал это зоопарком. Ты пытаешься этим оправдать для себя несовместимость их API? Ну так вспомни, что я вот буквально только что писал про стандартизацию Языка. Оказывается, так можно.
А венда обновляется чаше, чем тебе кажется. Дважды в год. LTS на этом фоне выглядят как-то скромненько.

Добавлено 10.12.24, 19:56

Цитата D_KEY @ 10.12.24, 16:27

Что я, как разработчик софта, тут изменю в своем коде выше?

Ничего. Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки. Знаешь, если атомарная операция не гарантирует атомарности... ну это ж POSIX же, чё. В WinAPI никогда новый HANDLE не будет выдан, если он полностью не вышел из использования. А вот в POSIX мультипотоковое ПО, оказывается, должно само об этом заботиться. Ну весело же.

Цитата D_KEY @ 10.12.24, 16:27

Так будет код-то?

А тебе мало было, что ли? Чай не первый холивар-то.

Цитата D_KEY @ 10.12.24, 16:27

Зоопарк разнородных подходов (пример привел выше с handle), функции с миллионом параметров, монструозные структуры данных и т.д. и т.п.

Пример с INVALIDE_HANDLE_VALUE чётко следует (внезапно) POSIXовой же традиции при ошибках возвращать -1, потому что бинарно с ним совместим, а бинарно совместимый с нулём NULL является вполне себе корректным stdin. В совокупности это нивелирует проблемы совместимости с криво писаным легаси, которые в 90-ых были весьма значимы. Нынче это не проблема, однако совместимость документированных интерфейсов ОСей требует. Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.
Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора. Параметр ты не пропустишь, инициализацию поля же легко. Особо важные параметры, которые если поменять местами, могут поломать поведение кода из-за незамеченной ядром ошибки их порядка в аргументах, не пройдут компиляцию из-за несовместимых типов. Это вам не int на все случаи жизни. А за монструозные структуры вообще странно в контексте негатива в адрес миллиона параметров. Я вот счас ещё вспомню про версии API, которые в WinAPI определяются элементарно sizeof() в первом поле, а в POSIX как (c_legacy_cast)какой_то_поинтер_на_мамой_клянусь_правильную_структуру. Ой, вспомнил.

Сообщение отредактировано: Qraizer - 10.12.24, 19:59

Цитата Qraizer @ 10.12.24, 19:39

Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки.

Писал в течение некольких лет, все было в порядке. Явно надежнее сервисов под windows, кстати. Хотя там сама ОС чудила чаще

Добавлено 10.12.24, 20:26

Цитата Qraizer @ 10.12.24, 19:39

Ну весело же.

Нормально
Поверь мне, это будет последнее из-за чего упадет твой сервис

Цитата Qraizer @ 10.12.24, 19:39

Пример с INVALIDE_HANDLE_VALUE чётко следует (внезапно) POSIXовой же традиции при ошибках возвращать -1, потому что бинарно с ним совместим, а бинарно совместимый с нулём NULL является вполне себе корректным stdin.

При чем тут это? У тебя один и тот же тип объектов, возвращенный разными функциями, при ошибке то будет равен одному значению, то другому, в зависимости от конкретной функции. Постоянно нужно сверятся с документацией конкретной функции. Это просто странно.

Цитата Qraizer @ 10.12.24, 19:39

Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.

У POSIX всегда будет -1. А для указателей всегда будет NULL (если одна единственная функция, которая действует не так из-за легаси, но ее очень редко используют - sbrk).

Цитата Qraizer @ 10.12.24, 19:39

Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора.

Не согласен. С объектами гораздо легче работать, чем с параметрами функций. Их удобо отдельно валидировать, сохранять, модифицировать и т.д.
Писать обертки для C++ так же удобнее.

Цитата Qraizer @ 10.12.24, 19:39

Параметр ты не пропустишь, инициализацию поля же легко.

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

Ну и вообще функции с миллионом параметров в принципе означают плохой дизайн. Классика же, "If you have a procedure with 10 parameters, you probably missed some"

Добавлено 10.12.24, 20:35
А вообще, еще раз, странно сравнивать. Оба API уродливы, каждый по своему (мне posix нравится больше winapi, но он все равно кривой). При этом POSIX касается большого числа совершенно разных ОС, от совершенно разных производителей и для разных задач. Соответственно, кривость хоть как-то можно оправдать. В случае winapi, который является поделкой одной единственной компании, наличие косяков выглядит более странным.

Добавлено 10.12.24, 20:40
Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.
Не было такого, что сначала кто-то придумал стандарт, а остальные начали его реализовывать, делая с нуля свои ОС.

Сообщение отредактировано: D_KEY - 10.12.24, 20:40

Цитата D_KEY @ 10.12.24, 20:16

Явно надежнее сервисов под windows, кстати.

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года, с момента их переезда с нашего этажа. Четыре штуки. Они от инета отключены, поэтому обновлений на них не прилетает, ребутать нет причин. Свет вырубался, но они под UPSами и хибернетом. Да, мои апликухи там тоже есть. Не оформлены сервисами, но по факту они самые. (Одну из них ты даже должен помнить, архитектуру я малёхо описывал в теме про объекты синхронизации.) С аптаймом поменьше, потому как они изредка апдейтятся под меняющиеся ТЗ на них.
Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY. Я легко могу поверить и пруфов не потребую, что у тебя там всё хорошо. Потому что вот конкретно твоё окружение не имеет проблем. Вот только когда речь заходит за высококритичное ПО, во главу угла ставится документация, а не испытания. И коли там сказано, что вот так оно могёт быть, твоё ПО не пройдёт аудит, если ты не предусмотришь у себя обработку сего. И пофик, что структурное покрытие его никогда не покроет. Будет написан модульный тест, имитирующий оговоренный отказ. Готовить своё приложение для такого случая придётся. Каждое приложение для каждого подобного случая. Можешь сам зайти на маны, почитать и посчитать ноуты под каждой функцией и прикинуть объём "никому не нужной" работы.
P.S. Библиотеки не спасут вообще ни разу. Только хуже сделают, т.к. для них тоже будет аудит. Я как-то уже упоминал, что флай-код в авионике отключает стандартные библиотеки и в лучшем случае пилит их аналоги, обычно сильно упрощённые. Так их хоть как-то можно сертифицировать за разумные деньги. А уж за third party и говорить нечего.

Цитата D_KEY @ 10.12.24, 20:16

Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.

Возможно. Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

Сообщение отредактировано: Qraizer - 11.12.24, 14:34

Цитата Qraizer @ 11.12.24, 14:31

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года

Ну стендовая это не считается
На моем опыте аптайм на линуксах был всегда очень хороший на реальных серваках. И был всегда такой себе на windows. Но может там админы плохие были у нас, не знаю

Добавлено 11.12.24, 14:49

Цитата Qraizer @ 11.12.24, 14:31

Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY.

В моей команде или в компании всегда были специалисты сильнее меня в этих вопросах. Вообще у нас были сервисы и с 99.9999% надежностью. И большая часть с 99.999%. Да и багов было немного.
Впрочем, это зависило от компании. Сейчас у меня другая история немного.

Добавлено 11.12.24, 14:53

Цитата Qraizer @ 11.12.24, 14:31

Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу

Сообщение отредактировано: D_KEY - 11.12.24, 14:57

Цитата D_KEY @ 11.12.24, 14:46

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу

Наброшу и плюсую Законный вопрос: а есть какойта более другой способ стандартизации и унификации программных вызовов в сериях независимых осей, кроме как POSIX?

Цитата D_KEY @ 11.12.24, 14:46

Ну стендовая это не считается
На моем опыте аптайм на линуксах был всегда очень хороший на реальных серваках. И был всегда такой себе на windows. Но может там админы плохие были у нас, не знаю

Почему это не считается? Там полноценная ОСь, без отключений чего-либо и кастраций, даже Защитник работает. Файрволл, правда, отключён. Или ты имеешь в виду рабочие нагрузки? Ты ж их даже не спросил.
У меня такое впечатление, что ты неправильно употребляешь термин "сервис". Стандартные сервисы из ОСи вполне себе надёжны, аптайм как бы вот он. Самописные... ну по реализации они не сервисы, но по факту они самые, т.к. работают те же 24/7. Может быть у вас там с виндой не всё гладко просто потому, что спецы по сервисам не такие уж и спецы? Это не наезд ни в коем случае, создание сервисов не вполне то же самое, что обычных приложений. Я вот по демонам никакой, не приходилось за ненадобностью.
А так-то в целом... не думаю, что открою большой секрет: все процессы разработки и верификации флай-кода ориентированы на винду. POSIX встречается крайне, реально крайне, вот прям очень крайне редко. Как исполнительная платформа для эмбеддед – бывает, но там обычно форкают, кастрируют скорее даже режут по живому, оставляя только потенциально требуемый минимум функционала. Мы как-то занимались верификацией RTEMS для одного из заказчиков, отправленное количество Сообщений о Проблемах я не припомню, но на каждый модуль (архитектурный) десяток в среднем набирался. Где-то больше, где-то меньше. Та ёлки, там баги даже в системных заголовках были, явно расходились с даташитами к PPC. И это притом, что RTEMS на MPC5200 вполне себе официально портирована и довольно давно.

Добавлено 13.12.24, 16:30
Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

Сообщение отредактировано: Qraizer - 13.12.24, 16:33

Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

Цитата Qraizer @ 13.12.24, 16:26

Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения. Но, тут соглашусь, не слышал - но варик достойный! Ибо решает вопросы не все, но в своей теме. Тут уважуха!

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас. Причём это вполне себе полноценная ОСь, в ней даже слой OpenGL есть. Но и стоят такие ОСи баснословно. Гораздо чаще выходит дешевле написать свою realtime ОСь на коленке, полностью её оттестировать модульными (а как иначе, если это тупо набор .o собранных в набор либ) со 100% покрытием, предоставить отчёты по WCET и WCSU, разработать и предоставить наборы сценариев для квалификационных её испытаний в составе будущего прикладного ПО под неё и сертифицировать в таком виде.

Добавлено 13.12.24, 17:21
macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

Сообщение отредактировано: Qraizer - 13.12.24, 17:21

Цитата Qraizer @ 13.12.24, 17:16

macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

Цитата Qraizer @ 13.12.24, 16:26

Почему это не считается?

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Впрочем, ты прав, возможно что у вас супер стенды со всем вышеперечисленным и имитацией реальных запросов с реальными данными, реальной частотой и пр.

Добавлено 13.12.24, 23:50

Цитата Qraizer @ 13.12.24, 16:26

У меня такое впечатление, что ты неправильно употребляешь термин "сервис". Стандартные сервисы из ОСи вполне себе надёжны, аптайм как бы вот он. Самописные... ну по реализации они не сервисы, но по факту они самые, т.к. работают те же 24/7.

Ну термины нельзя использовать правильно или неправильно. О терминах договариваются.

Но я действительно неточно выразился. Имел в виду аптайм именно самих серверов, сервисы оставались доступны вовне за счёт масштабирования, а если ты имеешь в виду сервисы/демоны на конкретной машине, то случались баги, конечно, но я тебе про то, что у нас сами машины перезагружали или ещё что-то с ними делали - хз. Я это видел только в zabbix, в основном.

Добавлено 13.12.24, 23:52

Цитата Qraizer @ 13.12.24, 16:26

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

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%. А у топовых компаний процент ещё выше.

Добавлено 14.12.24, 00:04

Цитата macomics @ 13.12.24, 16:37

Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

И что ты предлагаешь? Писать софт на asm x86 из-за этого?
И в чем костыльность std:: expected?

Добавлено 14.12.24, 00:06

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас.

А разве это не linux?

Добавлено 14.12.24, 00:07

Цитата macomics @ 13.12.24, 18:13

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

Пишешь под DOS?

Сообщение отредактировано: D_KEY - 14.12.24, 00:38

Цитата D_KEY @ 13.12.24, 23:42

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас.

А разве это не linux?

Или ты имеешь в виду VxWorks? А она разве POSIX не поддерживает?

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

Но гугление немного прояснило суть последних тем. POSIX - это считают стандартом, а ARINC-653 - это спецификация, стандартизующая определенный интерфейс(ы). Таким образом, POSIX - предназначен для обеспечения переносимости и повторного использования кода. Тогда как ARINC-653 предназначена для обеспечения пространственной и временной разделяемости в критически важных авионических системах реального времени. И не только в авионических, в любых RTOS системах, где безопасность и надежность являются критически важными. Сюда можно отнести и космонавтику, и военные системы. Таким образом наблюдается "перпендикулярность" Ибо они решают совсем разные проблемы проектирования.

Цитата D_KEY @ 13.12.24, 23:42

Пишешь под DOS?

Освежите у себя в памяти DOS API. Там было простое и элегантное решение по определению ошибок. Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

Цитата Majestio @ 14.12.24, 09:58

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

А WinAPI?

Добавлено 14.12.24, 10:56

Цитата macomics @ 14.12.24, 10:51

Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

Чем это лучше-то?

Цитата D_KEY @ 14.12.24, 10:55

А WinAPI?

Ну все тогда, холивар считаем закрытым

Цитата D_KEY @ 13.12.24, 23:42

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Ну это вы у себя никогда RFS не проводили, оно у нас занимает ~месяца со 100% нагрузкой всех подключённых исполнительных устройств. И ещё WCET, который увеличивает нагрузку раз в 10. Но так-то да, в обычном режиме нагрузка невелика. Если не считать, что в это время стенд обслуживает "кривые поделки", ещё не отлаженные.

Цитата D_KEY @ 13.12.24, 23:42

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%.

Потому что им не требуется сертифицировать процессы жизненных циклов. WinAPI создаёт вокруг них предсказуемое операционное окружение со свойствами, оцениваемое и измеряемое количественно, а без метрик отраслевые стандарты жить не могут, сразу фтопку. Но ключевое слово всё ж – предсказуемое.

Цитата D_KEY @ 13.12.24, 23:42

А разве это не linux?

Вопрос Majestio был за API, а не ОС. И я сразу предупредил, что это не совсем то.

Цитата D_KEY @ 14.12.24, 10:55

Чем это лучше-то?

Два результата сразу: bool и int, причём смысл последнего разный в зависимости от bool. Удобно

Добавлено 15.12.24, 15:13

Цитата D_KEY @ 14.12.24, 10:55

А WinAPI?

Наш лучший в 0-ых импортный партнёр Honeywell, чьим подрядчиком был наш основной московский заказчик, и который сам был одним из подрядчиков Boeing, вовсю использовал свою DEOS. Она использовалась на куче всякоразного коммерческого летающего, от Агусты и Цесны до Эмбрайров и Хоризонов. DEOS построена на WinAPI.
И кстати, процессы у Honeywell были бесподобные. Мы в своё время многое из них почерпнули как образец для подражания. (Я даже с их подсистемы групп, основанных на скриптовании тестовых воздействий и исполнении их прямо на исполнительных устройствах, слизал архитектуру реал-тайм чеков для внедрения в функциональных тестовых окружениях. И улучшил, конечно .) Наши нынешние отечественные заказчики и близко по их качеству не валялись. Ну вот Labs разве что похожа, но пока рано судить, мы с ними только начали.

Сообщение отредактировано: Qraizer - 15.12.24, 15:24

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Ну это вы у себя никогда RFS не проводили, оно у нас занимает ~месяца со 100% нагрузкой всех подключённых исполнительных устройств. И ещё WCET, который увеличивает нагрузку раз в 10.

Ну нагрузочное проходит регулярно. И все равно продакшн - это продакшн

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%.

Потому что им не требуется сертифицировать процессы жизненных циклов. WinAPI создаёт вокруг них предсказуемое операционное окружение со свойствами, оцениваемое и измеряемое количественно, а без метрик отраслевые стандарты жить не могут, сразу фтопку. Но ключевое слово всё ж – предсказуемое.

А что-то сертифицируется на WinAPI? Я пока так и не увидел примеров от тебя.

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

А разве это не linux?

Вопрос Majestio был за API, а не ОС. И я сразу предупредил, что это не совсем то.

Ну т.е. там POSIX поддержан хотя бы отчасти, а winapi - нет. Верно?

Цитата Qraizer @ 15.12.24, 15:07

Наш лучший в 0-ых импортный партнёр Honeywell, чьим подрядчиком был наш основной московский заказчик, и который сам был одним из подрядчиков Boeing, вовсю использовал свою DEOS. Она использовалась на куче всякоразного коммерческого летающего, от Агусты и Цесны до Эмбрайров и Хоризонов.

Гуглится довольно плохо. И вроде как там тоже POSIX (но не уверен). А с HeartOS не работал? Она точно POSIX, как я понял.

Цитата Qraizer @ 15.12.24, 15:07

DEOS построена на WinAPI.

А можно подробнее? Гуглится плохо, вместе с winapi вообще ничего не нашел. Есть упоминание POSIX, но как-то невнятно.

Без обид, но ты как-то очень сильно зациклен на довольно узкую нишу, в которой работаешь

Сообщение отредактировано: D_KEY - 15.12.24, 16:53

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 14.12.24, 10:55

Чем это лучше-то?

Два результата сразу: bool и int, причём смысл последнего разный в зависимости от bool. Удобно

Чем это лучше std::expected того же? Я уже не говорю про безопасный код и пр.

Цитата Qraizer @ 15.12.24, 15:07

DEOS построена на WinAPI.

Гугыль молчит. А чят-гпт крутит пальцем у виска. Но последнему доверие так себе - научился врать ппц.

Вот офсайт вроде: DEOS

Про WinAPI ни слова.

Есть немного про POSIX:

Цитата

Deos™, DDC-I’s safety-critical time and space partitioned real-time operating system (RTOS) that has been verified to the guidance of DO-178C/ED-12C Design Assurance Level A (DAL A) for Avionics Applications, supports ARINC 653 APEX, Rate Monotonic Scheduling (RMS), and is targeted at the Future Airborne Capability Environment (FACE™) Safety Extended and Safety Base Profiles. Deos is the first RTOS to receive OSS Conformance Certification for the FACE Technical Standard, Edition 3.1. The Safety Extended Profile, which adds support for TCP/IP communications, multi-process support, and expanded POSIX capability (80 extra functions), is a superset of the functionality required by the Safety Base and Security Profiles

Добавлено 15.12.24, 19:45
И от них же вроде есть HeartOS, которая POSIX.

Цитата D_KEY @ 15.12.24, 19:42

Про WinAPI ни слова.

Возможно Qraizer где-то немного попутал Там действительно есть упоминания про Венду. Но это в плане окружения для разработки, но не исполнения. Скриню:

Прикреплённая картинка

Хе-хе ... немножко про WinAPI

В моем "личном зачёте" для WinAPI я бы поставил оценку "удовлетворительно". Нельзя сказать что сей стандарт полное удобрение. Кстати, я пишу с Венды. Нет, в нем есть очень и очень здравые моменты проектирования. Меня больше всего радует объектно-событийный подход к проектированию. Мое скромное ИМХО, это - та бомба, которую до сих пор не изобрели и не унифицировали в POSIX. Да, как писали выше, уже есть костыли в виде epool/kqueue. Но тут, положа честную руку на моё самое доброе сердце - венда тут на этаж впереди.

Но есть и тяжелое наследие

Я имею ввиду Си-наследие. Когда зарплаты платились по 1.5 индийских рупий за килограмм кода. Нужно было добывать, майнить строки и объёмы. Посмотрите на количество аргументов функций, а-ля CreateProcess, NtCreateUserProcess, CreateProcessAsUser, RegCreateKeyEx, NtCreateSection. Это же не хухры-мухры, это уже просто мама-дарагая!

Я вот тоже решил немножко закинуть гиперболоид в тему топика. Как вам моя функция в стиле WinAPI Futures?

BOOL OpeningMicrosoftMortgage(
    LPCSTR lpApplicantName,
    LPCSTR lpPropertyAddress,
    LPCSTR lpLoanType,
    double dLoanAmount,
    int nLoanTerm,
    double dInterestRate,
    BOOL bFixedRate,
    LPCSTR lpCreditScore,
    LPCSTR lpEmploymentStatus,
    LPCSTR lpIncomeVerification,
    BOOL bCoApplicant,
    LPCSTR lpCoApplicantName,
    LPCSTR lpCoApplicantCreditScore,
    LPCSTR lpDownPaymentSource,
    double dDownPaymentAmount,
    LPCSTR lpPropertyType,
    BOOL bFirstTimeHomeBuyer,
    LPCSTR lpLoanOfficerName,
    LPCSTR lpApplicationID,
    BOOL bPreApproval,
    LPCSTR lpReferralSource,
    LPCSTR lpContactMethod,
    BOOL bEmailUpdates,
    LPCSTR lpPreferredClosingDate,
    LPCSTR lpInsuranceProvider,
    LPCSTR lpPropertyInspectionStatus,
    LPCSTR lpAppraisalValue,
    BOOL bEscrowAccount,
    LPCSTR lpMonthlyPaymentEstimate,
    LPCSTR lpLoanDisclosureDocuments,
    LPCSTR lpAdditionalNotes,
    BOOL bSubmitApplication
);

Ради прикола, ну и кому не лениво, посмотрите, пожалуйста, как красиво и изящно это обыгрывается в языке программирования Dart. Сорян, ссылаюсь на свой же сайт - но это во благо Поищите там подраздел "Именованные аргументы". Там очень-очень красиво - ящетаю!

Да, я уже упоминал про количество аргументов. У меня язык не повернется назвать это безумие хорошим дизайном.

Добавлено 15.12.24, 21:42

Цитата Majestio @ 15.12.24, 21:08

Да, как писали выше, уже есть костыли в виде epool/kqueue. Но тут, положа честную руку на моё самое доброе сердце - венда тут на этаж впереди.

Я еще раз напомню, что сранивать некорректно. Захотели MS ввести какой-нибудь IOCP и все, в следующей версии ждите. Одна компания, одно семейство ОС. А теперь для POSIX. Когда-то унифицировали select/poll. Потом времена поменялись, стало недостаточно, разные *nix системы пошли чуть разными путями, придумали epoll(linux), kqueue(*bsd), а сейчас в linux все больше обороты набирает io_uring. И это круто, что в разных ОС продолжают эксперементировать. Это развитие. Но что вы хотите от POSIX? Чтобы он побежал описывать разные эксперементальные штуки и обязал тем самым кучу разных компаний и ОС это все реализовывать? Это же требует согласований. И сертификации.

Еще раз, winapi корректно сравнивать с API какой-то конкретной ОС. А не с POSIX.

Добавлено 15.12.24, 21:51

Цитата Majestio @ 15.12.24, 21:08

красиво и изящно это обыгрывается в языке программирования Dart

Dart не изучал, мне нравится, как в Swift сделано

Сообщение отредактировано: D_KEY - 15.12.24, 21:51

Цитата D_KEY @ 15.12.24, 21:37

Dart не изучал

Ну я сцылку дал - не поленись, посмотри

Добавлено 15.12.24, 21:55

Цитата D_KEY @ 15.12.24, 21:37

как в Swift сделано

Бегло глянул - мне кажется почти один-в-один

Цитата D_KEY @ 15.12.24, 21:37

Еще раз, winapi корректно сравнивать с API какой-то конкретной ОС. А не с POSIX.

Не - ну ту без вопросов! WinAPI - это местячковая корпоративная спецификация. А вот POSIX - хош-не-хош, а это уже стандарт.

Цитата D_KEY @ 15.12.24, 16:52

А что-то сертифицируется на WinAPI? Я пока так и не увидел примеров от тебя.

Какие тебе примеры? Falcon, Boeing, Embraer — недостаточно? Могу ещё с десяток наименований накидать. Вся авионика, с которой я сталкивался, разрабатывается и сертифицируется под виндой. У нас как-то был один проект на LynxOS, договора благополучно подохли (потому что французы; и это не первый раз с ними, никогда с французами не работайте) в 18-м, наклюнулся было ещё один, на этот раз отечественный, сдулся из-за недостатка финансирования.

Цитата D_KEY @ 15.12.24, 19:42

Вот офсайт вроде: DEOS

Это не та DEOS, то была собственная. Нафик им вовне выкладывать собственные IP. Хошь кусочек заголовков?

#ifndef DEOS_H
#define DEOS_H
 
#include <windows.h>
 
#define semaphoreHandle HANDLE
#define semaphoreStatus int
#define timeoutSpecifier unsigned int
#define waitIndefinitely 0xFFFFFFFF
#define semaphoreSuccess 0
#define process_handle_t HANDLE
 
int waitSemaphore( HANDLE handle, unsigned int timeout );
int signalSemaphore( HANDLE handle );
void waitUntilNextPeriod( );
 
...

#ifndef EVENTAPI_H
#define EVENTAPI_H
 
/*
 ** HHdr-beg ****************************************************************
 **
 ** Copyright Honeywell Inc 03/01/96
 ** All Rights Reserved
 **
 ** Honeywell Proprietary
 **
 ** Include File name: EVENTAPI.H
 **
 ** Purpose:
 **   Everything needed to call event related DEOS API functions.
 **   Note:  This header file MUST be compatible with a "C" compiler.
 **
 **
 ** HPrj-beg ****************************************************************
 **
 ** HPrj-end ****************************************************************
 ** HHdr-end ****************************************************************
 */
 
...
 
#ifdef __cplusplus
extern "C" {
#endif
 
DEOSBASEAPI eventStatus DEOSKERNAPI createEvent(const char * name, eventHandle *createdEvent);
 
DEOSBASEAPI eventStatus DEOSKERNAPI getEventHandle(
              const char * name, process_handle_t procHand, eventHandle *createdEvent);
 
DEOSBASEAPI eventStatus DEOSKERNAPI waitForEvent(eventHandle theEventHandle, timeoutSpecifier timeout, DWORD currentCount);
 
DEOSBASEAPI eventStatus DEOSKERNAPI pulseEvent( eventHandle theEventHandle );
 
DEOSBASEAPI DWORD DEOSKERNAPI eventPulseCount( eventHandle theEventHandle );
 
DEOSBASEAPI eventStatus DEOSKERNAPI deleteEvent( eventHandle theEventHandle );
 
DEOSBASEAPI eventStatus DEOSKERNAPI grantEventAccess( eventHandle theEventHandle, process_handle_t processHandle, eventAccessRightsType access, bool grantToAllProcesses );
 
#ifdef __cplusplus
}
#endif
 
...

Думаю, хватит. Вроде ничего из конфиденциального не слил, но плз, не распространяйте. Этому коду 15 лет от последнего использования нами. Контракты кончились в кризис 08-09 годов, как у них там нынче, беспонятия.

Цитата Majestio @ 15.12.24, 21:08

Посмотрите на количество аргументов функций, а-ля CreateProcess, NtCreateUserProcess, CreateProcessAsUser, RegCreateKeyEx, NtCreateSection. Это же не хухры-мухры, это уже просто мама-дарагая!

И что с ними не так? Регистров не хватает, компилеру приходится стек юзать? Ай-яй-яй.

Добавлено 17.12.24, 10:20

Цитата Majestio @ 15.12.24, 21:08

Ради прикола, ну и кому не лениво, посмотрите, пожалуйста, как красиво и изящно это обыгрывается в языке программирования Dart

Ну так VB.NET. И ещё VBA. А ещё так можно в IDispatch. Только какое отношение это имеет в API?

Цитата Qraizer @ 17.12.24, 10:18

И что с ними не так? Регистров не хватает, компилеру приходится стек юзать? Ай-яй-яй.

С ними не хватает ... Нормального подхода. Просто подход - полное говно! Очень часто туча параметров задаётся по умолчанию. И их всех нужно явно указывать. Но если мы более внимательно, чем менее, зададимся вопросом "а как бы лучше сделать", то сразу обратим свое внимание на паттерн проектирования "Строитель". Иными словами, сперва просто создаем объект/сущность. А потом из его 32-х параметров задаём там три нам очень нужные путём вызова сеттеров. И замечу, это не обязательно С++, такое и в Си можно и нужно было бы сделать, в рамках WinAPI.

Добавлено 17.12.24, 19:12
В языках программирования нового поколения (Dart, и как оказалось, и Swift) ввели понятие "именованных параметров". Там это решается проще - просто при инициализации указываем те параметры, которые явно нужно определить (по именам параметров), остальные инициализируются по умолчанию. В этом случае можно обойтись и без "строителя", но и вызов будет гораздо компактнее.

Добавлено 17.12.24, 19:14

Цитата Qraizer @ 17.12.24, 10:18

Ну так VB.NET. И ещё VBA. А ещё так можно в IDispatch. Только какое отношение это имеет в API?

Такое не говори! У меня от такого бабки в подъезде крестятся!

Цитата Qraizer @ 17.12.24, 10:18

Какие тебе примеры? Falcon, Boeing, Embraer — недостаточно? Могу ещё с десяток наименований накидать.

Тут проблема в том, что в публичной информации нет никакого упоминания про windows, есть информация про разные rtos и они основаны не на винде, а или на чем-то своем или на линуксах. И даже когда на своем, то есть как минимум частичная реализация posix. Про WinAPI ни слова.

Добавлено 18.12.24, 08:21

Цитата Qraizer @ 17.12.24, 10:18

Вся авионика, с которой я сталкивался, разрабатывается и сертифицируется под виндой.

Ты сам пишешь про rtos, но винда к ним не относится (были какие-то древние rtos виндовоподобные, но мы холиварим сейчас).

Добавлено 18.12.24, 08:23

Цитата Qraizer @ 17.12.24, 10:18

Цитата D_KEY @ 15.12.24, 19:42

Вот офсайт вроде: DEOS

Это не та DEOS, то была собственная.

Так DEOS они и делают вроде
Может раньше была какая-то старая и другая, а сейчас перешли на что-то новое? Почему не гуглится ничего?

Ты только правильно пойми, я тебе верю больше, чем себе, но для холивара нужно что-то более существенное

Добавлено 18.12.24, 08:27

Цитата Qraizer @ 17.12.24, 10:18

Хошь кусочек заголовков?

Извини за нубские вопросы. Ты хочешь сказать, что в их "RTOS" под капотом была винда?

Сообщение отредактировано: D_KEY - 18.12.24, 08:27

Цитата Majestio @ 17.12.24, 19:01

В языках программирования нового поколения (Dart, и как оказалось, и Swift) ввели понятие "именованных параметров". Там это решается проще - просто при инициализации указываем те параметры, которые явно нужно определить (по именам параметров), остальные инициализируются по умолчанию.

Что тебе мешает то же самое напрограммить на Плюсах? Пишешь один раз шаблон, при конкретизации инстанцируешь набором параметров, при использовании зовёшь метод шаблона, который переводит сие в процедурный вызов. Не скажу, что это легко и быстро, но один раз же. Только потом не огорчайся, когда народ будет реагировать на это как ты на ту хабровую статью про эрроры. Оно надо будет буквально паре человеков.
Я в общем-то могу повторить про чемлучшемульёнполей буквально:

Скрытый текст

struct
{
    LPCSTR lpApplicantName,
    LPCSTR lpPropertyAddress,
    LPCSTR lpLoanType,
    double dLoanAmount,
    int nLoanTerm,
    double dInterestRate,
    BOOL bFixedRate,
    LPCSTR lpCreditScore,
    LPCSTR lpEmploymentStatus,
    LPCSTR lpIncomeVerification,
    BOOL bCoApplicant,
    LPCSTR lpCoApplicantName,
    LPCSTR lpCoApplicantCreditScore,
    LPCSTR lpDownPaymentSource,
    double dDownPaymentAmount,
    LPCSTR lpPropertyType,
    BOOL bFirstTimeHomeBuyer,
    LPCSTR lpLoanOfficerName,
    LPCSTR lpApplicationID,
    BOOL bPreApproval,
    LPCSTR lpReferralSource,
    LPCSTR lpContactMethod,
    BOOL bEmailUpdates,
    LPCSTR lpPreferredClosingDate,
    LPCSTR lpInsuranceProvider,
    LPCSTR lpPropertyInspectionStatus,
    LPCSTR lpAppraisalValue,
    BOOL bEscrowAccount,
    LPCSTR lpMonthlyPaymentEstimate,
    LPCSTR lpLoanDisclosureDocuments,
    LPCSTR lpAdditionalNotes,
    BOOL bSubmitApplication
) SuperCoolStruct_VS_DeepShitParams, *PSuperCoolStruct_VS_DeepShitParams;
 
BOOL OpeningMicrosoftMortgage(PSuperCoolStruct_VS_DeepShitParams cfg);

и напомнить, что memset() (неважно, что подкапотный) не решает траблю, т.к. далеко не всегда нулевая последовательность бит подходит для значения по умолчанию. Я поступлю по другому, а именно спрошу "дорогой Majestio, откуда у тебя выродилась такая гора входов в одну подсистему?", а потом "как система защищена от человеческого фактора? как она реагирует на случайный пропуск инициализации одного поля? а двух? а десятка потому что скопипастил, и поправил со сдвигом в две строки?" Я об этом уже писал выше, третий раз не буду.

Цитата D_KEY @ 18.12.24, 08:17

Ты сам пишешь про rtos, но винда к ним не относится

Ты возможно удивишься, но ядро у винды на порядок более реалтаймое, чем у линукса. Я даже под Win98SE в своё время получал гарантированные микросекунды реакции, тогда как соседний nix-овый отдел оперировал миллисекундами. Под WinXP ситуация не поменялась, а как нынче у того отдела, беспонятия, меня в том КБ уже 20 лет нету. И не надо, что мол ядро и прикладной уровень не сравнимы. Да, не сравнимы, но прикладное ПО с требованиями жёсткого реал-тайма и проектируются соответственно, одного только наличия RTOS недостаточно.

Цитата D_KEY @ 18.12.24, 08:17

Может раньше была какая-то старая и другая, а сейчас перешли на что-то новое?

Скорее просто случайное совпадение аббревиатур. Хотя вариант с развитием ОСи в направлении мультиплатформенности тоже может быть. Тогда действиетльно Honeywell могла взять что-то старое и 20 (?) лет использовать в своих продуктах, а ОСь с тех пор эволюционировала. На тот момент в тестируемых нами шелезяках были P5 и i486.

Цитата D_KEY @ 18.12.24, 08:17

Ты хочешь сказать, что в их "RTOS" под капотом была винда?

Нет. Что её API основан на WinAPI. Реализация ОСи в лучшем случае (не факт, ессно) была лицензирована с Windows CE, которая, как известно, с Windows, кроме API, общего ничего не имеет. Это тем более вероятно, что даже их тестовая среда TATS использовала VBScript под лицензией с некоторыми расширениями языка типа групп, драйверов, мониторов итп. (Это всё не те группы, драйверы и мониторы в известном смысле, это названия подсистем тестирования, управляющие входами и контролирующие выходы.)

Цитата D_KEY @ 18.12.24, 08:17

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

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

Сообщение отредактировано: Qraizer - 18.12.24, 14:20

Цитата Qraizer @ 18.12.24, 14:14

Я говорил не об изделиях, а о средствах их разработки, верификации и сертификации.

А, ну тогда это вообще большого значения не имеет, ИМХО. На чем угодно можно разрабатывать

Добавлено 18.12.24, 15:08

Цитата Qraizer @ 18.12.24, 14:14

Изделия-то зачастую работают вообще на чём-то самописном, где и POSIX даже близко не наблюдается.

Ну судя по тому, что гуглится, вполне себе наблюдается
Сам я довольно мало работал с rtos и давно. Но это был ecos, который posix слой предоставлял.

Ну и мы все упёрлись зачем-то в очень узкую нишу.

Пока считаю свой тезис о том, что POSIX таки является стандартом для ОСей и таки реально реализуется и используется, верным.
Точно так же как тезис о том, что winapi подобным стандартом не является и потому сравнивать это с posix некорректно.

Сообщение отредактировано: D_KEY - 18.12.24, 15:11

Цитата Qraizer @ 18.12.24, 14:14

Что тебе мешает то же самое напрограммить на Плюсах?
...
Только потом не огорчайся, когда народ будет реагировать на это как ты на ту хабровую статью про эрроры. Оно надо будет буквально паре человеков..

Сам же и ответил. И не надо делать вывод, что раз костылями для реализации концепции не пользуются, то и сама концепция не нужна. Я помню, как люди плевались на бустовые лямбды, например. Но как только лямбды появились в языке (стандарте), то почему-то все начали пользоваться.
Потому что проблема в самих костылях, а не концепции.

Добавлено 18.12.24, 15:27

Цитата Qraizer @ 18.12.24, 14:14

Я в общем-то могу повторить про чемлучшемульёнполей буквально.

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

Добавлено 18.12.24, 15:32

Цитата Qraizer @ 18.12.24, 14:14

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

Не знаю, что там в windows. Линукс раньше и не был rtos, были отдельные версии linux для rtos. Сейчас, насколько я знаю, linux умеет работать в real time режиме (вроде в этом году смержили наконец-то патчи, которые жили много лет отдельно). Для windows это не так

Сообщение отредактировано: D_KEY - 18.12.24, 15:35

Цитата Qraizer @ 18.12.24, 14:14

Что тебе мешает то же самое напрограммить на Плюсах? Пишешь один раз шаблон, при конкретизации инстанцируешь набором параметров, при использовании зовёшь метод шаблона, который переводит сие в процедурный вызов. Не скажу, что это легко и быстро, но один раз же. Только потом не огорчайся, когда народ будет реагировать на это как ты на ту хабровую статью про эрроры. Оно надо будет буквально паре человеков.

Не, спасибо. Это мне кажется не одно и тоже. А тем более вплетать для этого метапрограммирование - ваще беда. И, если честно, я не совсем понимаю как у тебя это получится. Можешь продемонстрировать?

Цитата Qraizer @ 18.12.24, 14:14

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

Вот в этом и фишка подхода в Dart - кроме "поименованной" инициализации есть еще возможность объявлять обязательные и необязательные параметры. Случайного пропуска не будет - компилятор не даст. А если пропустили "необязательный", то у него обязана быть инициализация по умолчанию, или он инициализируется null. Т.е. тут большая ответственность лежит на том, кто написал такую функцию, конструктор или метод. У того, кто пользует - все гарантии есть. А про количество аргументов ... более 5-7 (или около того) я считаю извратом. Я о таком уже писал выше. Но всяко же бывает.

Цитата Qraizer @ 18.12.24, 14:14

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

Qraizer, а вот тут, батенька, ты, скорее всего, сам себя заводишь в заблуждение и пацанов туманишь!

Понятие "RTOS" не подразумевает оценку отклика системных вызовов, или качества планировщика многозадачности, или еще чего-то (допустим цвета упаковки коммерческого дистра). Да, если эти параметры на высоте - это супер. Но самое главное отличие обычной оси от RTOS, в том, что RTOS гарантирует и предоставляет прогеру возможности прогать вызовы в строго детерминированных промежутках времени. В Уиндовс такого не было, нет, и пока слабо ожидается! Хотя Гугыль подсказывает - подвижки есть. Пример Windows 10 IoT Enterprise, в котором частично реализовано т.н. "мягкое реальное время". Иными словами, часть возможностей реализована.

Что касается Люникса

Люникс - это не операционная система (это, по сути, просто ядро)! А вот моя любимая Фряха - это полноценная ось. Операционной системой Люникс может быть только в составе дистра(ов). Тогда да.

Что касается RTOS Люникса

Я не слышал по полноценных, 100% перепатченых дистров под реальное время. Да, есть отдельные "флагманы", типа RTLinux, FreeRTOS, Xenomai (но это отдельный догружаемый проект). Таким образом ... пшик Но есть одно "но", ну достаточно продолжительное время начинают выпускаться ядра Люникса, разделённые на "обычные" и "RT". Пример из моего любимого дистра Manjaro (в красных рамках выделены рилтаймовские ядра):

Прикреплённая картинка

И, тем не менее ... Даже если я RT-ядро установлю - от этого моя ось полноценной RTOS не станет! Ядро просто предоставляет для рилтайма низкоуровнёвый интерфейс, ко всем прочим интерфейсам. Как мы определились выше (вернее, я вас определил) - ось это ядро + базовый, коробочный, набор софта. Так вот, если это набор на RT плевать хотел, о какой рилтаймовости может идти речь?

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

Цитата D_KEY @ 18.12.24, 15:05

Ну судя по тому, что гуглится, вполне себе наблюдается

Ты можешь нагуглить в лучшем случае прототипы систем бортового управления (сиречь менеджмента). У них 100пудово категория E, по которой сертификация требует базовый набор документов из двух комплектов, и на этом всё. Только Р4754 или может быть 4761. Развернуть прототип и связать с компонентами не проблема. Потому что DAL-E не влияет на безопасность. Мы же говорим о компонентах класса 3А или 3Б с категориями через одного DAL-A/B и C и только изредка D. По ним из стандартов не вылезешь, комплектов документов потребуется 3 десятка по каждому, и их на борту сотни. Не все из них используют ПО, многие только электронные или даже электрические, а некоторые вообще просто механика. Но это неважно, те, которые используют ПО, ты даже близко не нагуглишь. Их вне каналов взаимодействия между сертифицирующими органами и разработчиками, включая подрядчиков, нигде нет... а, ну ещё в архивах.
Вот конкретно сейчас мы занимаемся системой торможения для МС-21. Там четыре (хоть и все ARM, но все разные) микроконтроллера с FLASH на 512Кб и 128Кб RAM. Ну-ну запихать туда что-нить не самописное. И оно на 80% состоит из взаимодействия с железом и остальные 20% чутка логики для обхода отказов, включая события единичного отказа. Самолёты целиком состоят из вот таких на наш/ваш взгляд примитивных вычислительных модулей. Что-либо более-менее серьёзное, хотя бы уровня P5M или там Qualcomm S1, которые мы всерьёз не воспринимаем уже лет 10-20, ставят на что-нибудь сугубо интерфейсное или в салон мультики пассажирам крутить. Просто потому что они ненадёжны, и утеря ими функциональности некритична. Вот это ты можешь нагуглить тоннами, это бизнес. P.S. Бизнес – не безопасность.

Добавлено 19.12.24, 16:11

Цитата D_KEY @ 18.12.24, 15:24

Я помню, как люди плевались на бустовые лямбды, например.

Хм. Лично я помню, что очень сильно плевался на буст, потому что таскать за собой его было накладно, но не лямбды. За лямбды я сожалел, что они хоть и гораздо удобнее функторов, но всё ж недостаточно и ввиду слабой языковой поддержки их эффективность хуже. Но на C++03 большего и не сделать было. Как концепция лямбды мне очень нравились. В отличие от именованных аргументов, натянуть на каковые объективный смысл весьма затруднительно. Те же пропертя, только горизонтально.

Добавлено 19.12.24, 16:21

Цитата D_KEY @ 18.12.24, 15:24

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

Ну, за копипасту я слегонца слукавил всё ж. Обычно, если нужен однотипный код в нескольких местах, где копипаста помогает, там нет мульёна параметров или полей структур. Скажем так: мне не приходилось запускать процессы пачками. А с другой стороны, там, где тебе нужно запустить процесс, довольно сложно сделать это поэтапно, ибо старт процесса – это фактически его конструктор. Разделение создания объекта и его последующей инициализации давно уж признано не самым лучших аспектом ООП-модели, ибо в промежутке между этими этапами объект как ресурс существует, но отсутствует как сущность. Так что всё настраиваемые параметры нового процесса нужны здесь и сейчас, а не потом когда-нибудь.

Цитата Majestio @ 18.12.24, 18:13

А тем более вплетать для этого метапрограммирование - ваще беда. И, если честно, я не совсем понимаю как у тебя это получится. Можешь продемонстрировать?

Именно метой. А для чего её по-твоему в язык ввели впрочем да, ввели-то ещё в C++98 случайно, но вот развили в C++11 уже намерено.
Продемонстрировать... ишь ты. Ну как концепт, можно.

Цитата Majestio @ 18.12.24, 18:13

Вот в этом и фишка подхода в Dart - кроме "поименованной" инициализации есть еще возможность объявлять обязательные и необязательные параметры.

Ну так я говорю, Dart переизобрёл MSное OLE Automation, которой 100 лет в обед.

Добавлено 19.12.24, 17:31

Цитата Majestio @ 19.12.24, 11:57

Понятие "RTOS" не подразумевает оценку отклика системных вызовов, или качества планировщика многозадачности, ... Но самое главное отличие обычной оси от RTOS, в том, что RTOS гарантирует и предоставляет прогеру возможности прогать вызовы в строго детерминированных промежутках времени. В Уиндовс такого не было, нет, и пока слабо ожидается!

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

Цитата Majestio @ 19.12.24, 11:57

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

Цитата Qraizer @ 19.12.24, 17:26

Вот в этом ты ошибаешься. RTOS гарантирует времена откликов.

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

Цитата Qraizer @ 19.12.24, 17:26

Винда на уровне ядра это гарантирует посредством уровней IRQL.

Для такой гарантии в WinAPI должны присутствовать системные вызовы с явным указанием желаемых тайм-аутов на исполнение. Оно там действительно есть?

Цитата Qraizer @ 19.12.24, 17:26

Ну так я говорю, Dart переизобрёл MSное OLE Automation, которой 100 лет в обед.

Дело не в изобретении, а во включении в стандарт языка. Вон там, к примеру, подымали тему лямбд. Тоже могу сказать, что С++ в 2011 году их не изобрели, но их включили в стандарт языка. Я лямбды в Perl пользовал еще в далеком 1997 году, сразу как изучил и начал пользоваться. А сам, еще тогдашний Perl 4, релизнулся в 1993 году.

Цитата Majestio @ 19.12.24, 11:57

Я не слышал по полноценных, 100% перепатченых дистров под реальное время.

Вроде были. Плюс сейчас в этом году в ядро смержили поддержку реального времени.

Добавлено 20.12.24, 11:51

Цитата Qraizer @ 19.12.24, 16:03

Ты можешь нагуглить в лучшем случае прототипы систем бортового управления (сиречь менеджмента). У них 100пудово категория E, по которой сертификация требует базовый набор документов из двух комплектов, и на этом всё. Только Р4754 или может быть 4761. Развернуть прототип и связать с компонентами не проблема. Потому что DAL-E не влияет на безопасность. Мы же говорим о компонентах класса 3А или 3Б с категориями через одного DAL-A/B и C и только изредка D. По ним из стандартов не вылезешь, комплектов документов потребуется 3 десятка по каждому, и их на борту сотни. Не все из них используют ПО, многие только электронные или даже электрические, а некоторые вообще просто механика. Но это неважно, те, которые используют ПО, ты даже близко не нагуглишь. Их вне каналов взаимодействия между сертифицирующими органами и разработчиками, включая подрядчиков, нигде нет... а, ну ещё в архивах.
Вот конкретно сейчас мы занимаемся системой торможения для МС-21. Там четыре (хоть и все ARM, но все разные) микроконтроллера с FLASH на 512Кб и 128Кб RAM. Ну-ну запихать туда что-нить не самописное. И оно на 80% состоит из взаимодействия с железом и остальные 20% чутка логики для обхода отказов, включая события единичного отказа. Самолёты целиком состоят из вот таких на наш/ваш взгляд примитивных вычислительных модулей. Что-либо более-менее серьёзное, хотя бы уровня P5M или там Qualcomm S1, которые мы всерьёз не воспринимаем уже лет 10-20, ставят на что-нибудь сугубо интерфейсное или в салон мультики пассажирам крутить. Просто потому что они ненадёжны, и утеря ими функциональности некритична. Вот это ты можешь нагуглить тоннами, это бизнес. P.S. Бизнес – не безопасность.

Я с тобой во многом не согласен. Но кажется, что это все не имеет отношения к теме дискуссии
Так что тут можно закончить. Ты в этом веришся, тебе виднее, наверное.
Узкая ниша (плюс ещё и перекос на российскую специфику, а я не уверен, что она отражает мировые тренды). Не вижу смысла обсуждать тут, оно не имеет отношения к winapi vs posix.

Добавлено 20.12.24, 11:53

Цитата Qraizer @ 19.12.24, 16:03

За лямбды я сожалел, что они хоть и гораздо удобнее функторов, но всё ж недостаточно и ввиду слабой языковой поддержки их эффективность хуже. Но на C++03 большего и не сделать было. Как концепция лямбды мне очень нравились.

Ну так я и говорю, что костыльность реализации не означает то, что концепция плоха.

Добавлено 20.12.24, 11:55

Цитата Qraizer @ 19.12.24, 16:03

В отличие от именованных аргументов, натянуть на каковые объективный смысл весьма затруднительно

В некоторых случаях было бы удобно для API. Только плюсы и так перегружены сейчас, наверное, оно того не стоит. Но, опять же, это связано с языком, а не концепциями.

Добавлено 20.12.24, 11:56

Цитата Qraizer @ 19.12.24, 17:26

Винда на уровне ядра это гарантирует посредством уровней IRQL.

А можно какую-то ссылку на документацию?

Сообщение отредактировано: D_KEY - 20.12.24, 11:56

Цитата Majestio @ 20.12.24, 00:40

Для такой гарантии в WinAPI должны присутствовать системные вызовы с явным указанием желаемых тайм-аутов на исполнение. Оно там действительно есть?

В WinAPI нет, но оно и не RT. Ты тоже невнимателен, я говорил за ядро ОСи. В ядре винды RT вполне себе есть.
Но следует учитывать, конечно, что она никогда не позиционировалась как RTOS, поэтому гарантий MS не предоставляет. И тем не менее анализ ядерного API показывает, что чёткое вытеснение на основе приоритетов там присутствует, и практика это подтверждает ну, не опровергает.

Цитата D_KEY @ 20.12.24, 11:48

Узкая ниша (плюс ещё и перекос на российскую специфику, а я не уверен, что она отражает мировые тренды). Не вижу смысла обсуждать тут, оно не имеет отношения к winapi vs posix.

За российскую специфику это ты зря. Как раз российская специфика, особенно с недавних пор, должна бы по идее убить в себе зависимость от проприетарных технологий недружественных стран, ан нет. Не то что не смогли, даже не собирались начинать. Только тс-с-с, не дай бог нас там услышат. Оффтоп, конечно, но напомню, что речь об этом зашла в контексте надёжности и безопасности ПО, а этот контекст появился от меня как практическая демонстрация безопасности APIs. И мне правда жаль, что из соображений конфиденциальности интеллектуальной собственности (в частности не нашей, а заказчиков) не могу предоставить что-нибудь более материальное.

В общем, я тут сварганил на коленке концепцию.

#include <source_location>
#include <iostream>
#include <functional>
#include <type_traits>
#include <cstring>
 
template <typename Param> struct Node
{
  using value_type = Param;
 
  static value_type set(value_type& l, const value_type& r) { return l = r; }
  static value_type get(const value_type& v)                { return v;     }
 
  static inline const value_type default_value = value_type{};
};
 
template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value_Base
{
  static const std::uint_least32_t line   = L;
  static const std::uint_least32_t column = C;
 
  using node_type = Node<T>;
  using value_type= typename node_type::value_type;
 
  value_type value;
 
  Value_Base(): value(node_type::default_value) {}
  Value_Base& operator=(const typename node_type::value_type& v) { value = v; return *this; }
};
template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value;
 
#define Prop_Decl(Type)                                          \
struct Value<typename Type::node_type::value_type, Type::line, Type::column>
 
#define Prop_Impl(Type)                                                                         \
template<>                                                                                      \
struct Value<typename Type::node_type::value_type, Type::line, Type::column>: public Type       \
{                                                                                               \
public:                                                                                         \
  using node_type = typename Type::node_type;                                                   \
  using value_type= typename node_type::value_type;                                             \
  value_type Name;                                                                              \
                                                                                                \
public:                                                                                         \
  explicit Value(const value_type& v = node_type::default_value): Name(v) {}                    \
};
 
#define Prop(Type)                                                                              \
typedef struct Value_Base<Type, std::source_location::current().line(),                         \
                               std::source_location::current().column()>
 
#define MakeProps(CurProp, ...)   Prop_Impl(CurProp) __VA_OPT__(Prop_Impl(__VA_ARGS__))
#define MakeBuilder(Func, CurProp, ...) Builder<Func, Prop_Decl(CurProp) __VA_OPT__(, Prop_Decl(__VA_ARGS__))>
 
template <typename F, typename Param, typename ...NextParams>
struct Builder: public Param, public Builder<F, NextParams...>
{
  template <typename Args>
  void setArgs(Args &&args)
  {
    auto &value= static_cast<Value<typename std::remove_cvref_t<Args>::node_type::value_type,
                                            std::remove_cvref_t<Args>::line,
                                            std::remove_cvref_t<Args>::column>&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    node_type::set(value.Name, args.value);
  }
 
  auto doIt()
  {
    auto &value= static_cast<Value<typename std::remove_cvref_t<Param>::node_type::value_type,
                                            std::remove_cvref_t<Param>::line,
                                            std::remove_cvref_t<Param>::column>&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    return node_type::get(value.Name);
  }
 
  explicit Builder(F f): Builder<F, NextParams...>(f) {}
 
  template <typename Arg, typename ...Args>
  typename std::function<F>::result_type operator()(Arg arg, Args... args)
  {
    setArgs(arg); (setArgs(args), ...);
    return (this->fn)(doIt(), Builder<F, NextParams...>::doIt());
  }
};
 
template <typename F, typename Param>
struct Builder<F, Param>: public Param
{
  template <typename Args>
  void setArgs(Args &&args)
  {
    auto &value= static_cast<Value<typename std::remove_cvref_t<Args>::node_type::value_type,
                                            std::remove_cvref_t<Args>::line,
                                            std::remove_cvref_t<Args>::column>&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    node_type::set(value.Name, args.value);
  }
 
  auto doIt()
  {
    auto &value= static_cast<Value<typename std::remove_cvref_t<Param>::node_type::value_type,
                                            std::remove_cvref_t<Param>::line,
                                            std::remove_cvref_t<Param>::column>&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    return node_type::get(value.Name);
  }
 
  std::function<F> fn;
 
  explicit Builder(F f): fn(f) {}
 
  template <typename Args>
  typename std::function<F>::result_type operator()(Args args)
  {
    setArgs(args);
    return (this->fn)(doIt());
  }
};
 
Prop(const char*) param1;
Prop(const char*) param2;
 
MakeProps(param1, param2);
MakeBuilder(decltype(strcmp), param1, param2) build(strcmp);
 
int main()
{
  std::cout << build(param1() = "abc", param2() = "abc") << std::endl;
  std::cout << build(param1() = "abc", param2() = "abd") << std::endl;
  std::cout << build(param2() = "abd", param1() = "abc") << std::endl;
  std::cout << build(param1() = "abd")                   << std::endl;
  std::cout << build(param2() = "ab" )                   << std::endl;
}

Недостатков уйма. Значения по умолчанию по сути не работают (последние два вызова), т.к. задаются только в начале и когда позже перебиваются явными значениями, такими и остаются. Много избыточного, т.к. это третья по счёту наконец-то заработавшая как надо реализация, и мне лень её вычищать и оптимизировать. В конце концов это концепция, а не либа. И да, давненько я не брал в руки препроцессор ... Кто если заинтересуется, может заглянуть в мои мультиметоды на гитхабе и стащить оттуда нормальные техники реализации этого безобразия, без препроцесора, со списками типов, нормальной рекурсией по параметрам и деревьям акцепторов. Зато тут уже заложен потенциал стратегии для кастомизации обработки специфических типов параметров (на основе template <typename Param> struct Node) и уже реализована неограниченная N-arity с произвольным порядком передачи параметров в вызов. Второй и третий вызовы показывают, что порядок параметров Builder не влияет на порядок параметров strcmp().
Но лучше, думаю, подождать C++26, куда нам обещали крутейшую рефлексию. Не факт, что успеют, правда.

Сообщение отредактировано: Qraizer - 20.12.24, 18:53

Цитата Qraizer @ 20.12.24, 18:42

В общем, я тут сварганил на коленке концепцию.

Как всегда Даже разбираться не буду, мне страшно

Ну я тоже решил сварганить свой подход:

#include <iostream>
#include <any>
#include <map>
 
enum class KeyType {
  One, Two, Three
};
 
using ParamsType = std::map<KeyType, std::any>;
 
void TestFunc(ParamsType param) {
  for(const auto &i: param) {
    std::cout << "param [";
    switch(i.first) {
      case KeyType::One:   std::cout << "One]: "   << std::any_cast<std::string>(i.second); break;
      case KeyType::Two:   std::cout << "Two]: "   << std::any_cast<int>(i.second); break;
      case KeyType::Three: std::cout << "Three]: " << std::any_cast<double>(i.second); break;
      default:             std::cout << "Unknown]";        
    }
    std::cout << std::endl;  
  }
}
 
int main() {
  TestFunc({
    {KeyType::Two, 2},        
    {KeyType::One, std::string{"Один"}},
    // можно пропустить, а можно не пропустить {KeyType::Three, 2.71828}
  });
  return 0;
}

param [One]: Один
param [Two]: 2

Позволяет какбэ реализовать именованные параметры, и позволяет параметрам быть необязательными. Но недостатков тоже масса:

1) Гораздо многословнее чем в Dart
2) Проверку наличия обязательных параметров можно обеспечить только проверками в рантайме в теле функции/конструктора/метода
3) Инициализацию по-умолчанию можно реализовать только в рантайме в теле функции/конструктора/метода
4) Чтобы не ошибиться в передаче и последующей обработке имен параметров пришлось запилить enum class

Цитата Qraizer @ 20.12.24, 18:42

Недостатков уйма.

И еще один недостаток Я не смог твой пример откомпилячить тут - https://www.onlinegdb.com. Свой пример я проверил, для С++17.

Qraizer, норм вроде (позже гляну повнимательнее). Но, сам понимаешь, костыли это все

Есть уже boost.parameter. Но тоже костыли (особенно страшно выглядит объявление функций).

Добавлено 21.12.24, 11:08
Majestio, в твоём варианте оверхед в рантайме, что для синтаксического сахара плохо

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

Цитата D_KEY @ 21.12.24, 11:07

Majestio, в твоём варианте оверхед в рантайме, что для синтаксического сахара плохо

Согласен, вааще не вопрос!

D_KEY, это не костыли, это расширение возможностей языка его же средствами. С тем же успехом можно назвать костылями все эти <type_traits>, <ratio> итп.
Идея в том, что построенное на основе шаблонного вариадика дерево Builder содержит узлы Value для хранения переданных параметров, которые в свою очередь унаследованы от Value_base, хранящие значения по умолчанию. На случай особых типов, чтение и установка параметра вынесено в стратегию Node, которая легко специализируется. (Например, для указателей может захотеться намутить контейнер, владеющий контентом, вместо хранения собственно указателя.) Каждый Value_base уникален, благодаря зависимости от строки/колонки в сырце, и производный от него Value наследует зависимость от строки/колонки, позволяя работать с Value_base уже без этой зависимости. Каждый Value представлен в дереве Builder отдельный узлом, так что static_cast<> легко кастует Builder вниз к нужному Value. В вызове Builder создаются лёгкие rvalue этих Value_base, которые заменяют значения по умолчанию из Node на указанные, и Builder сначала последовательно проходит по всем переданным Value_base (извлекая инфу для зависимого от него Value из своего дерева), переносит значения из них в найденные у себя Value, а затем проходит по своим Value уже в порядке шаблонных параметров и собирает вариадиком значения для передачи в функцию. Конечно, надо бы ещё добавить в Node какие-нибудь set_default/get_default() для управления умолчаниями в ран-тайм и сброс значений Value к хранимым в Node, чтоб совсем шоколадно.
Посмотри, там оверхеда нет вообще:

int main()
{
00007FF6363C96F0  push        rbx  
00007FF6363C96F2  sub         rsp,20h  
  std::cout << build(param1() = "abc", param2() = "abc") << std::endl;
00007FF6363C96F6  mov         rcx,qword ptr [build+58h (07FF6364C3B28h)]  
00007FF6363C96FD  lea         rbx,[string "%p" (07FF63649A6CCh)]  
00007FF6363C9704  mov         qword ptr [build+8h (07FF6364C3AD8h)],rbx  
00007FF6363C970B  mov         qword ptr [build+18h (07FF6364C3AE8h)],rbx  
00007FF6363C9712  mov         qword ptr [rsp+30h],rbx  
00007FF6363C9717  mov         qword ptr [rsp+38h],rbx  
00007FF6363C971C  test        rcx,rcx  
00007FF6363C971F  je          main+1B5h (07FF6363C98A5h)  
00007FF6363C9725  mov         rax,qword ptr [rcx]  
00007FF6363C9728  lea         r8,[rsp+30h]  
00007FF6363C972D  lea         rdx,[rsp+38h]  
00007FF6363C9732  mov         qword ptr [rsp+40h],rdi  
00007FF6363C9737  call        qword ptr [rax+10h]  
00007FF6363C973A  mov         edx,eax  
00007FF6363C973C  lea         rcx,[std::cout (07FF6364C5B70h)]  
00007FF6363C9743  call        std::basic_ostream<char,std::char_traits<char> >::operator<< (07FF6363B1D70h)  
00007FF6363C9748  mov         rcx,rax  
00007FF6363C974B  call        std::endl<char,std::char_traits<char> > (07FF6363B1320h)  
  std::cout << build(param1() = "abc", param2() = "abd") << std::endl;
00007FF6363C9750  mov         rcx,qword ptr [build+58h (07FF6364C3B28h)]

Если включить -O2, конечно. Точнее, он есть, принадлежит std::function<>, но разглядеть его непросто, чекает инкапсулированную функцию на nullptr.

Добавлено 22.12.24, 15:29

Цитата Majestio @ 20.12.24, 20:21

И еще один недостаток Я не смог твой пример откомпилячить тут - https://www.onlinegdb.com.

std::source_location требует C++20. Кроме того, VS тоже ругается, если не указать ключик /Zc:preprocessor, который разрешает variadic macro... Хм, что-то у меня есть подозрение, что с препроцессором я облажался

Добавлено 22.12.24, 15:38
P.S. На всякий случай результат исполнения:

0
-1
-1
0
1

Цитата Qraizer @ 22.12.24, 15:13

D_KEY, это не костыли, это расширение возможностей языка его же средствами.

Костыли. У C++ нет достаточных возможностей для расширения языка и добавления синтаксического сахара в данном случае (а такой способ передачи аргументов это именно синтаксический сахар). Препроцессор тут помог не сильно.
А по поводу идеи, да, кажется норм.

У C++ нет таких возможностей для того, что не может быть разрешено в компайл-тайм и требует линк-тайм. Например, полноценные мультиметоды. Но можно к такому приблизиться очень близко. Если ты имеешь в виду что-то типа рефлексии, то это уже не грамматика. Но её тоже обещают через пару лет, посмотрим

Оказалось, что препроцессор я в руки брал ещё давнее, чем мне казалось. Мне было лень возиться со списками типов, но я вспомнил за вариадик-макросы, и думал, что они мне помогут. Не помогли. Вылетело из головы, что макросы в принципе нерекурсивны, и вариадики этого не изменяют. Так что нужно было бы по старинке, нумеровать 1, 2, 3 итд до нужного количества, которые бы ссылались на предыдущие.
В общем пофик. Нате нормальную версию. Препроцессор остался только в определении параметров, потому что удобно. Но и там можно от него избавиться, если обеспечить уникальность типов свойств как-нибудь иначе.

#include <cstdint>
#include <source_location>
#include <iostream>
#include <functional>
#include <type_traits>
#include <cstring>
 
template <typename Param> struct Node
{
  using value_type = Param;
 
  static value_type set(value_type& l, const value_type& r) { return l = r; }
  static value_type get(const value_type& v)                { return v;     }
 
  static inline const value_type default_value = value_type{};
};
 
template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value_Base
{
  static const std::uint_least32_t line   = L;
  static const std::uint_least32_t column = C;
 
  using node_type = Node<T>;
  using value_type= typename node_type::value_type;
 
  value_type value;
 
  Value_Base(): value(node_type::default_value) {}
  Value_Base& operator=(const typename node_type::value_type& v) { value = v; return *this; }
};
 
template <typename Type>
struct Value: public Type
{
public:
  using node_type = typename Type::node_type;
  using value_type= typename node_type::value_type;
  value_type Name;
 
public:
  explicit Value(const value_type& v = node_type::default_value): Name(v) {}
};
#define Prop(Type)                                                                              \
typedef struct Value_Base<Type, std::source_location::current().line(),                         \
                                std::source_location::current().column()>
 
struct NullType{};
 
template <typename T, typename H>             struct TList;
template <typename T, typename L, typename R> struct TList<T, TList<L, R>>
{
  using Node = T;
  using Tail = TList<L, R>;
};
template <typename T> struct TList<T, NullType>
{
  using Node = T;
  using Tail = NullType;
};
 
template <typename N, typename ...Args> struct MakeList
{
  using type = TList<Value<N>, typename MakeList<Args...>::type>;
};
template <typename N>                   struct MakeList<N>
{
  using type = TList<Value<N>, NullType>;
};
template <typename N, typename ...T>
using MakeTList = typename MakeList<N, T...>::type;
 
template <typename N, typename ...T>
using MakeProps = typename MakeTList<N, T...>::type;
 
template <typename F, typename Param>
struct Builder: public Param::Node, public Builder<F, typename Param::Tail>
{
  template <typename Args>
  void setArgs(Args &&args)
  {
    auto &value     = static_cast<Value<std::remove_reference_t<Args>>&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    node_type::set(value.Name, args.value);
  }
 
  auto getValue()
  {
    auto &value     = static_cast<typename Param::Node&>(*this);
    using node_type = typename std::remove_reference_t<decltype(value)>::node_type;
 
    return node_type::get(value.Name);
  }
 
  explicit Builder(F f): Builder<F, typename Param::Tail>(f) {}
 
  template <typename ...Args>
  typename std::function<F>::result_type call(Args... args)
  {
    return Builder<F, typename Param::Tail>::call(args..., getValue());
  }
 
  template <typename ...Args>
  typename std::function<F>::result_type operator()(Args... args)
  {
    (setArgs(args), ...);
    return call();
  }
};
 
template <typename F>
struct Builder<F, NullType>
{
  std::function<F> fn;
 
  explicit Builder(F f): fn(f) {}
 
  template <typename ...Args>
  typename std::function<F>::result_type call(Args... args)
  {
    return (this->fn)(args...);
  }
};
 
void f(int x, int y, int z)
{
  std::cout << x << '\t' << y << '\t' << z << std::endl;
}
 
Prop(const char*) param1;
Prop(const char*) param2;
 
Builder<decltype(strcmp), MakeTList<param1, param2>> build(strcmp);
 
Prop(int) par1;
Prop(int) par2;
Prop(int) par3;
 
Builder<decltype(f), MakeTList<par1, par2, par3>> f_proxy(f);
 
int main()
{
  std::cout << build(param1() = "abc", param2() = "abc") << std::endl;
  std::cout << build(param1() = "abc", param2() = "abd") << std::endl;
  std::cout << build(param2() = "abd", param1() = "abc") << std::endl;
  std::cout << build(param1() = "abd")                   << std::endl;
  std::cout << build(param2() = "ab" )                   << std::endl;
 
  f_proxy(par2() = 456, par1() = 789);
  f_proxy(par3() = 123);
}

Добавил функцию с тремя параметрами, чисто шоп потестить.

Добавлено 23.12.24, 15:34
Majestio, разобрался с вашим доблестным компилером онлайн. Во-первых, ему нужно явное включение <cstdint>, чтобы были доступны определения типов типа uint_least32_t. Что очень странно, ибо этот тип используется в классе std::source_location, и он должен его включать сам. Ну ок, как бы не обязан, и как-то выкручивается. Во-вторых, ему категорически не травится атрибут noexcept у strcmp(), из-за которого он отказывается конкретизировать параметр std::function<> и идёт по обобщённой ветке, которая не реализована, и это правильно. Правильно, что не реализована для не подходящего типа, но вот то, что noexcept-функция является неподходящей – это ни разу не правильно. И это хороший вопрос к тамошней реализации STL, разбирайся с этой байдой сам, тут я не помощник. Во всяком случае ты можешь заменить std::function<> просто на указатель и везде вместо длинных bla_bla::return_type наставить auto. Должно работать, но это уж точно костыль.

Сообщение отредактировано: Qraizer - 23.12.24, 18:11

Ещё костыльнее оказалось

Добавлено 23.12.24, 15:43
В плане онлайн компиляторов, я лучше godbolt пока не видел.

А что тогда не костыль с твоей точки зрения, D_KEY? Не, лучше не так. Дай определение термина "костыль", плз. Списки типов изобрёл Александреску, и ничего лучше пока не придумали. Да, есть вариадики, но это не эквивалент, т.к. их невозможно надёжно специализировать, постоянно выползают неоднозначности сопоставления, т.к. ... стремится попадать под что угодно. Автоматическую генерацию иерархий классов по спискам тоже он изобрёл, и что-то получше пока только обещают. Рекурсивный обход иерархии, применяя указанную стратегию к каждому узлу, опять же его заслуга. По факту весь шаблонный метапрогамминг от него, мои первые мультиметоды на C++03 зарелизились. Если подзабыл, то это изобретения более чем 20-летней давности, так что если б были намерения заменить на более другое, давно б уже зарелизили в Стандарте.

Добавлено 23.12.24, 18:10

Цитата D_KEY @ 23.12.24, 15:42

В плане онлайн компиляторов, я лучше godbolt пока не видел.

Он не умеет C++20. Внезапно std::source_location ему неведом.

Сообщение отредактировано: Qraizer - 23.12.24, 18:22

Цитата Qraizer @ 23.12.24, 18:01

Цитата D_KEY @ 23.12.24, 15:42

В плане онлайн компиляторов, я лучше godbolt пока не видел.

Он не умеет C++20. Внезапно std::source_location ему неведом.

А ты какой компилятор выбрал? А ключик прописал?

Добавлено 23.12.24, 19:51

Цитата Qraizer @ 23.12.24, 18:01

Дай определение термина "костыль"

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

Вот твой код с msvc и c /std:c++20

Добавлено 24.12.24, 00:43

Цитата Qraizer @ 23.12.24, 15:24

ему категорически не травится атрибут noexcept у strcmp(), из-за которого он отказывается конкретизировать параметр std::function<> и идёт по обобщённой ветке, которая не реализована, и это правильно. Правильно, что не реализована для не подходящего типа, но вот то, что noexcept-функция является неподходящей – это ни разу не правильно. И это хороший вопрос к тамошней реализации STL

С этим интересно было бы разобраться, кстати. И gcc и clang не компилят. А они стандарту обычно следуют лучше msvc. На днях может быть посмотрю. Или если ты глянешь, то напиши.

Сообщение отредактировано: D_KEY - 24.12.24, 01:19

Вообще, все верно, clang и gcc правы. std::function не умеет работать с noexcept функциями (а с C++17 они другой тип). Но твой код будет работать, если взять std::move_only_function из С++23

Сообщение отредактировано: D_KEY - 24.12.24, 05:19

Цитата D_KEY @ 23.12.24, 19:45

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

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

Сообщение отредактировано: Qraizer - 24.12.24, 14:10

Цитата Qraizer @ 24.12.24, 13:58

И они целиком и полностью отвечают Стандарту.

Не вдаваясь в подробности, и нагло влезая в ваш спич ... спешу сообщить - твой аргумент говно До той поры, когда в Стандарте будут явные ссылки на UB (а порой и неопубликованные и обсуждаемые) - это не будет "индульгенцией" для надёжности. Прости - просто логика

Что б далеко не ходить, D_KEY, вот что на гитхабе написано:

Цитата

• header only lib;
• unbounded N-arity (except C++03, but very simply extendable);
• separate linkage type (static or dynamic) for each param;
• static linkage allow any types, any indirection (r-value refs included, excepting C++03 of course) and any cv-qualification (excepting r-value refs, I'm lazy);
• dynamic linkage also allow same, excepting param-by-value of course (but C++03 allow only cv-nonqualified pointers); you can use same or different class hierarchies for different dynamic params;
• simple and intuitive definition of dispatcher (C++03 is more comprehensive);
• you don't must to create full set of overriding combination for dynamic params; dynamic linkage uses rules of Standard overload rules; you will get a compile-time error on ambiguous or undecidability;
• base multimethod and all its overrides are encapsulated within one scope;
• no reinterpret_cast<>, no dynamic_cast<>;
• full params type control for static linkage params on entire path from dispatcher call to getting execution by multimethod; only Standard implicit conversions are allowed; (C++03 has some troubles there); no unneeded copies (but not for return value, sorry);
• great performance; Visitor (both of them) extremely close to native implementation (whether it existed).

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

Добавлено 24.12.24, 15:06
Если UB задокументировано в Стандарте, то её наличие в языке не проблема. Многие реализации доопределяют те или иные аспекты, Стандарт оставляет за ними такое право как раз для непереносимых аспектов исполнительных платформ. Например, разыменование nullptr во многих реализация более чем допустимо, т.к. там лежат таблицы векторов прерываний, например. Программа при этом не будет соответствовать Стандарту, т.к. корректно отработать ей на другой реализации запросто будет невозможным, однако конкретно в этой реализации она будет иметь строго определённое поведение. За эти качества C/C++ и получили свою нишу, которую у них отобрать непросто. Надёжность кода измеряется ...немного другими метриками.

Сообщение отредактировано: Qraizer - 24.12.24, 15:11

Цитата Qraizer @ 24.12.24, 15:00

Если UB задокументировано в Стандарте, то её наличие в языке не проблема. Многие реализации доопределяют те или иные аспекты, Стандарт оставляет за ними такое право как раз для непереносимых аспектов исполнительных платформ. Например, разыменование nullptr во многих реализация более чем допустимо, т.к. там лежат таблицы векторов прерываний, например. Программа при этом не будет соответствовать Стандарту, т.к. корректно отработать ей на другой реализации запросто будет невозм

Не сочти за неуважение Но наличие ссылок на возможные UB уничижает понятие "надёжности" в/на 100500 раз. Не нужно больше слов! Есть недетерминированное поведение в ряде случаев - просто в тут забудь про слово "надёжность" желательно надёжно

Qraizer, ты с godbolt разобрался, увидел ссылку мою? Там можно выбрать разные компиляторы (и архитектуры) и ключи разные прописать. Очень удобно.

Добавлено 24.12.24, 15:45
И про noexcept согласен с комментарием?

Добавлено 24.12.24, 15:50

Цитата Qraizer @ 24.12.24, 13:58

Цитата D_KEY @ 23.12.24, 19:45

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

Ну т.е. ты сейчас обозвал костылями любые библиотеки

Нет, не любые. Иногда это как раз прямой путь со стандартными подходами и надежными инструментами

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