Вот повезло, что я пишу с телефона и мне неудобно цитировать твои же предыдущие ответы. Кратко - ты сам предлагал их использовать две страницы назад для решения задачи на эвентах.
Собственно, эффективную (без пробуждения всех читателей при записи) и простую (сопоставимую по сложности с CV) реализацию писателей-читателей (можно без приоритетов) на евентах я бы тоже хотел увидеть.
Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.
Это была твоя задача, и она не эквивалентна моей: читатели у тебя блокирующие, и нет приоритетов для писателей. Я тебе подсказал её решение. Это не значит, что я свою задачу решил бы так же. Но твоё право хотеть странного.
Ты говорил, что это просто, но решения и даже ссылки до сих пор нет. Расцениваю как слив.
Ну естественно. Как же ещё это было расценить. Но намекну: тебе нужны события с автосбросом, которые не бинарные, а со счётчиком. Это семафоры. ;) Но мой вариант использовал бы кольцевой буфер с тремя служебными полями индексов/указателей, для которых достаточно интерлокед операций. То, что непонимание с твоей стороны этой банальщины я ещё в апреле посчитал сливом, я писать не стал, просто предложил забить, но хозяин барин.
Мне вообще не особо понятно как мы перешли от обсуждения кривости архитектуры и примера с событиями к качеству и рискам. Ещё раз повторюсь, что на кривой архитектуре можно построить надёжное приложение (обычно подперев изрядным количеством костылей). Верно и обратное - на "совершенном" api построить нечто очень глючное. Короче смысла обсуждать этот аспект я вообще не вижу.
Та легко. Я указал объём и качество документации по WinAPI как огромное преимущество, ты с этой точкой зрения не согласился, предпочёв посчитать таковым открытость. Ты посчитал большое количество параметров или полей в структурах кривостью, я это назвал гибкостью. Тут мы, думаю, не договоримся, ибо это вопрос предпочтений, объективизмом и не пахнет. Но я хотя бы аргументировал, чем с моей точки зрения гибкость лучше.
API, у которого документация (да и которое, видимо само) больше чем все другие API вместе взятые — это жирность, а не гибкость. Гибкое API не нуждается в тоннах жира. Plan 9 API — гибкое, а WinAPI — жирное.
Ты ошибаешься. Документации никогда не бывает много, даже когда её много. Хотел бы я, чтобы было иначе, но увы. Типичнейший пример, притча по языцах:
const int *data;
/.../
long *header_ptr = (long*)data;
Почти наверняка без понимания того, что хотел написать программист, ты не сможешь определить, корректен ли этот код. Тут может быть три различных варианта того, что он хотел, но без пояснений выбрать правильный невозможно. Хоть усмотрись в этот код всеми четырьмя глазами, высмотри до дыр, не определишь. Это ставит огромный крест на код-ревью только лишь по коду. Если только не знать всю подноготную архитектуры кода, которая, конечно же, является документацией на проект. К слову, у нас в отрасли всегда есть множество уровней документации — системные требования, требования верхнего уровня, требования нижнего уровней (последние могут уходить вглубь на несколько уровней), описание проекта ПО, описание процесса сборки ПО, описание архитектуры ПО, совместимость с целевым вычислителем, анализ стратегии управления кешем, анализ использования стека, анализ наихудшего времени исполнения — и это только то, что под нашей сферой ответственности со стороны верификации. Конечно, наша отрасль весьма особенная, и отраслевые стандарты очень строги, но как раз это и показывает роль моего тезиса о роли количества и качества документации. При желании документацию можно сделать очень хорошей, было бы желание тратить на это ресурсы. У MS желание было.
