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

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