Форум на Исходниках.RU

WinAPI и POSIX

D_KEY — Tue, 24 Dec 2024 15:44:58 +0000

D_KEY: Qraizer, ты с godbolt разобрался, увидел ссылку мою? Там можно выбрать разные компиляторы (и архитектуры) и ключи разные прописать. Очень удобно.

Добавлено 24.12.24, 15:45
И про noexcept согласен с комментарием?

Добавлено 24.12.24, 15:50

Цитата Qraizer @ 24.12.24, 13:58

Цитата D_KEY @ 23.12.24, 19:45

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

Ну т.е. ты сейчас обозвал костылями любые библиотеки

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

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

WinAPI и POSIX

Majestio — Tue, 24 Dec 2024 15:12:50 +0000

Majestio:

Цитата Qraizer @ 24.12.24, 15:00

Если UB задокументировано в Стандарте, то её наличие в языке не проблема. Многие реализации доопределяют те или иные аспекты, Стандарт оставляет за ними такое право как раз для непереносимых аспектов исполнительных платформ. Например, разыменование nullptr во многих реализация более чем допустимо, т.к. там лежат таблицы векторов прерываний, например. Программа при этом не будет соответствовать Стандарту, т.к. корректно отработать ей на другой реализации запросто будет невозм

Не сочти за неуважение :) Но наличие ссылок на возможные UB уничижает понятие "надёжности" в/на 100500 раз. Не нужно больше слов! Есть недетерминированное поведение в ряде случаев - просто в тут забудь про слово "надёжность" желательно надёжно :lol:

WinAPI и POSIX

Qraizer — Tue, 24 Dec 2024 15:00:22 +0000

Qraizer: Что б далеко не ходить, D_KEY, вот что на гитхабе написано:

Цитата

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

Добавлено 24.12.24, 15:06
Если UB задокументировано в Стандарте, то её наличие в языке не проблема. Многие реализации доопределяют те или иные аспекты, Стандарт оставляет за ними такое право как раз для непереносимых аспектов исполнительных платформ. Например, разыменование nullptr во многих реализация более чем допустимо, т.к. там лежат таблицы векторов прерываний, например. Программа при этом не будет соответствовать Стандарту, т.к. корректно отработать ей на другой реализации запросто будет невозможным, однако конкретно в этой реализации она будет иметь строго определённое поведение. За эти качества C/C++ и получили свою нишу, которую у них отобрать непросто. Надёжность кода измеряется ...немного другими метриками.

WinAPI и POSIX

Majestio — Tue, 24 Dec 2024 14:47:45 +0000

Majestio:

Цитата Qraizer @ 24.12.24, 13:58

И они целиком и полностью отвечают Стандарту.

Не вдаваясь в подробности, и нагло влезая в ваш спич ... спешу сообщить - твой аргумент говно :lool: До той поры, когда в Стандарте будут явные ссылки на UB (а порой и неопубликованные и обсуждаемые) - это не будет "индульгенцией" для надёжности. Прости - просто логика :rolleyes:

WinAPI и POSIX

Qraizer — Tue, 24 Dec 2024 13:58:51 +0000

Qraizer:

Цитата D_KEY @ 23.12.24, 19:45

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

WinAPI и POSIX

D_KEY — Tue, 24 Dec 2024 05:10:27 +0000

D_KEY: Вообще, все верно, clang и gcc правы. std::function не умеет работать с noexcept функциями (а с C++17 они другой тип). Но твой код будет работать, если взять std::move_only_function из С++23 :)

WinAPI и POSIX

D_KEY — Tue, 24 Dec 2024 00:29:30 +0000

D_KEY: Вот твой код с msvc и c /std:c++20

Добавлено 24.12.24, 00:43

Цитата Qraizer @ 23.12.24, 15:24

ему категорически не травится атрибут noexcept у strcmp(), из-за которого он отказывается конкретизировать параметр std::function<> и идёт по обобщённой ветке, которая не реализована, и это правильно. Правильно, что не реализована для не подходящего типа, но вот то, что noexcept-функция является неподходящей – это ни разу не правильно. И это хороший вопрос к тамошней реализации STL

С этим интересно было бы разобраться, кстати. И gcc и clang не компилят. А они стандарту обычно следуют лучше msvc. На днях может быть посмотрю. Или если ты глянешь, то напиши.

WinAPI и POSIX

D_KEY — Mon, 23 Dec 2024 19:45:42 +0000

D_KEY:

Цитата Qraizer @ 23.12.24, 18:01

Цитата D_KEY @ 23.12.24, 15:42

В плане онлайн компиляторов, я лучше godbolt пока не видел.

Он не умеет C++20. Внезапно std::source_location ему неведом.

А ты какой компилятор выбрал? А ключик прописал?

Добавлено 23.12.24, 19:51

Цитата Qraizer @ 23.12.24, 18:01

Дай определение термина "костыль"

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

WinAPI и POSIX

Qraizer — Mon, 23 Dec 2024 18:01:04 +0000

Qraizer: А что тогда не костыль с твоей точки зрения, D_KEY? Не, лучше не так. Дай определение термина "костыль", плз. Списки типов изобрёл Александреску, и ничего лучше пока не придумали. Да, есть вариадики, но это не эквивалент, т.к. их невозможно надёжно специализировать, постоянно выползают неоднозначности сопоставления, т.к. ... стремится попадать под что угодно. Автоматическую генерацию иерархий классов по спискам тоже он изобрёл, и что-то получше пока только обещают. Рекурсивный обход иерархии, применяя указанную стратегию к каждому узлу, опять же его заслуга. По факту весь шаблонный метапрогамминг от него, мои первые мультиметоды на C++03 зарелизились. Если подзабыл, то это изобретения более чем 20-летней давности, так что если б были намерения заменить на более другое, давно б уже зарелизили в Стандарте.

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

Цитата D_KEY @ 23.12.24, 15:42

В плане онлайн компиляторов, я лучше godbolt пока не видел.

Он не умеет C++20. Внезапно std::source_location ему неведом.

WinAPI и POSIX

D_KEY — Mon, 23 Dec 2024 15:42:23 +0000

D_KEY: Ещё костыльнее оказалось :)

Добавлено 23.12.24, 15:43
В плане онлайн компиляторов, я лучше godbolt пока не видел.

WinAPI и POSIX

Qraizer — Mon, 23 Dec 2024 15:24:21 +0000

Qraizer: Оказалось, что препроцессор я в руки брал ещё давнее, чем мне казалось. Мне было лень возиться со списками типов, но я вспомнил за вариадик-макросы, и думал, что они мне помогут. Не помогли. Вылетело из головы, что макросы в принципе нерекурсивны, и вариадики этого не изменяют. Так что нужно было бы по старинке, нумеровать 1, 2, 3 итд до нужного количества, которые бы ссылались на предыдущие.
В общем пофик. Нате нормальную версию. Препроцессор остался только в определении параметров, потому что удобно. Но и там можно от него избавиться, если обеспечить уникальность типов свойств как-нибудь иначе.

#include <cstdint>

#include <source_location>

#include <iostream>

#include <functional>

#include <type_traits>

#include <cstring>

template <typename Param> struct Node

{

using value_type = Param;

static value_type set(value_type& l, const value_type& r) { return l = r; }

static value_type get(const value_type& v) { return v; }

static inline const value_type default_value = value_type{};

};

template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value_Base

{

static const std::uint_least32_t line = L;

static const std::uint_least32_t column = C;

using node_type = Node<T>;

using value_type= typename node_type::value_type;

value_type value;

Value_Base(): value(node_type::default_value) {}

Value_Base& operator=(const typename node_type::value_type& v) { value = v; return *this; }

};

template <typename Type>

struct Value: public Type

{

public:

using node_type = typename Type::node_type;

using value_type= typename node_type::value_type;

value_type Name;

public:

explicit Value(const value_type& v = node_type::default_value): Name(v) {}

};

#define Prop(Type) \

typedef struct Value_Base<Type, std::source_location::current().line(), \

std::source_location::current().column()>

struct NullType{};

template <typename T, typename H> struct TList;

template <typename T, typename L, typename R> struct TList<T, TList<L, R>>

{

using Node = T;

using Tail = TList<L, R>;

};

template <typename T> struct TList<T, NullType>

{

using Node = T;

using Tail = NullType;

};

template <typename N, typename ...Args> struct MakeList

{

using type = TList<Value<N>, typename MakeList<Args...>::type>;

};

template <typename N> struct MakeList<N>

{

using type = TList<Value<N>, NullType>;

};

template <typename N, typename ...T>

using MakeTList = typename MakeList<N, T...>::type;

template <typename N, typename ...T>

using MakeProps = typename MakeTList<N, T...>::type;

template <typename F, typename Param>

struct Builder: public Param::Node, public Builder<F, typename Param::Tail>

{

template <typename Args>

void setArgs(Args &&args)

{

auto &value = static_cast<Value<std::remove_reference_t<Args>>&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

node_type::set(value.Name, args.value);

}

auto getValue()

{

auto &value = static_cast<typename Param::Node&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

return node_type::get(value.Name);

}

explicit Builder(F f): Builder<F, typename Param::Tail>(f) {}

template <typename ...Args>

typename std::function<F>::result_type call(Args... args)

{

return Builder<F, typename Param::Tail>::call(args..., getValue());

}

template <typename ...Args>

typename std::function<F>::result_type operator()(Args... args)

{

(setArgs(args), ...);

return call();

}

};

template <typename F>

struct Builder<F, NullType>

{

std::function<F> fn;

explicit Builder(F f): fn(f) {}

template <typename ...Args>

typename std::function<F>::result_type call(Args... args)

{

return (this->fn)(args...);

}

};

void f(int x, int y, int z)

{

std::cout << x << '\t' << y << '\t' << z << std::endl;

}

Prop(const char*) param1;

Prop(const char*) param2;

Builder<decltype(strcmp), MakeTList<param1, param2>> build(strcmp);

Prop(int) par1;

Prop(int) par2;

Prop(int) par3;

Builder<decltype(f), MakeTList<par1, par2, par3>> f_proxy(f);

int main()

{

std::cout << build(param1() = "abc", param2() = "abc") << std::endl;

std::cout << build(param1() = "abc", param2() = "abd") << std::endl;

std::cout << build(param2() = "abd", param1() = "abc") << std::endl;

std::cout << build(param1() = "abd") << std::endl;

std::cout << build(param2() = "ab" ) << std::endl;

f_proxy(par2() = 456, par1() = 789);

f_proxy(par3() = 123);

}

Добавил функцию с тремя параметрами, чисто шоп потестить.

Добавлено 23.12.24, 15:34
Majestio, разобрался с вашим доблестным компилером онлайн. Во-первых, ему нужно явное включение , чтобы были доступны определения типов типа uint_least32_t. Что очень странно, ибо этот тип используется в классе std::source_location, и он должен его включать сам. Ну ок, как бы не обязан, и как-то выкручивается. Во-вторых, ему категорически не травится атрибут noexcept у strcmp(), из-за которого он отказывается конкретизировать параметр std::function<> и идёт по обобщённой ветке, которая не реализована, и это правильно. Правильно, что не реализована для не подходящего типа, но вот то, что noexcept-функция является неподходящей – это ни разу не правильно. И это хороший вопрос к тамошней реализации STL, разбирайся с этой байдой сам, тут я не помощник. Во всяком случае ты можешь заменить std::function<> просто на указатель и везде вместо длинных bla_bla::return_type наставить auto. Должно работать, но это уж точно костыль.

WinAPI и POSIX

Qraizer — Sun, 22 Dec 2024 18:46:18 +0000

Qraizer: У C++ нет таких возможностей для того, что не может быть разрешено в компайл-тайм и требует линк-тайм. Например, полноценные мультиметоды. Но можно к такому приблизиться очень близко. Если ты имеешь в виду что-то типа рефлексии, то это уже не грамматика. Но её тоже обещают через пару лет, посмотрим

WinAPI и POSIX

D_KEY — Sun, 22 Dec 2024 18:13:22 +0000

D_KEY:

Цитата Qraizer @ 22.12.24, 15:13

D_KEY, это не костыли, это расширение возможностей языка его же средствами.

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

WinAPI и POSIX

Qraizer — Sun, 22 Dec 2024 15:13:20 +0000

Qraizer: D_KEY, это не костыли, это расширение возможностей языка его же средствами. С тем же успехом можно назвать костылями все эти , итп.
Идея в том, что построенное на основе шаблонного вариадика дерево Builder содержит узлы Value для хранения переданных параметров, которые в свою очередь унаследованы от Value_base, хранящие значения по умолчанию. На случай особых типов, чтение и установка параметра вынесено в стратегию Node, которая легко специализируется. (Например, для указателей может захотеться намутить контейнер, владеющий контентом, вместо хранения собственно указателя.) Каждый Value_base уникален, благодаря зависимости от строки/колонки в сырце, и производный от него Value наследует зависимость от строки/колонки, позволяя работать с Value_base уже без этой зависимости. Каждый Value представлен в дереве Builder отдельный узлом, так что static_cast<> легко кастует Builder вниз к нужному Value. В вызове Builder создаются лёгкие rvalue этих Value_base, которые заменяют значения по умолчанию из Node на указанные, и Builder сначала последовательно проходит по всем переданным Value_base (извлекая инфу для зависимого от него Value из своего дерева), переносит значения из них в найденные у себя Value, а затем проходит по своим Value уже в порядке шаблонных параметров и собирает вариадиком значения для передачи в функцию. Конечно, надо бы ещё добавить в Node какие-нибудь set_default/get_default() для управления умолчаниями в ран-тайм и сброс значений Value к хранимым в Node, чтоб совсем шоколадно.
Посмотри, там оверхеда нет вообще:

int main()

{

00007FF6363C96F0 push rbx

00007FF6363C96F2 sub rsp,20h

std::cout << build(param1() = "abc", param2() = "abc") << std::endl;

00007FF6363C96F6 mov rcx,qword ptr [build+58h (07FF6364C3B28h)]

00007FF6363C96FD lea rbx,[string "%p" (07FF63649A6CCh)]

00007FF6363C9704 mov qword ptr [build+8h (07FF6364C3AD8h)],rbx

00007FF6363C970B mov qword ptr [build+18h (07FF6364C3AE8h)],rbx

00007FF6363C9712 mov qword ptr [rsp+30h],rbx

00007FF6363C9717 mov qword ptr [rsp+38h],rbx

00007FF6363C971C test rcx,rcx

00007FF6363C971F je main+1B5h (07FF6363C98A5h)

00007FF6363C9725 mov rax,qword ptr [rcx]

00007FF6363C9728 lea r8,[rsp+30h]

00007FF6363C972D lea rdx,[rsp+38h]

00007FF6363C9732 mov qword ptr [rsp+40h],rdi

00007FF6363C9737 call qword ptr [rax+10h]

00007FF6363C973A mov edx,eax

00007FF6363C973C lea rcx,[std::cout (07FF6364C5B70h)]

00007FF6363C9743 call std::basic_ostream<char,std::char_traits<char> >::operator<< (07FF6363B1D70h)

00007FF6363C9748 mov rcx,rax

00007FF6363C974B call std::endl<char,std::char_traits<char> > (07FF6363B1320h)

std::cout << build(param1() = "abc", param2() = "abd") << std::endl;

00007FF6363C9750 mov rcx,qword ptr [build+58h (07FF6364C3B28h)]

Если включить -O2, конечно. Точнее, он есть, принадлежит std::function<>, но разглядеть его непросто, чекает инкапсулированную функцию на nullptr.

Добавлено 22.12.24, 15:29

Цитата Majestio @ 20.12.24, 20:21

И еще один недостаток Я не смог твой пример откомпилячить тут - https://www.onlinegdb.com.

std::source_location требует C++20. Кроме того, VS тоже ругается, если не указать ключик /Zc:preprocessor, который разрешает variadic macro... Хм, что-то у меня есть подозрение, что с препроцессором я облажался

Добавлено 22.12.24, 15:38
P.S. На всякий случай результат исполнения:

-1

WinAPI и POSIX

Majestio — Sat, 21 Dec 2024 15:38:37 +0000

Majestio:

Цитата D_KEY @ 21.12.24, 11:07

Majestio, в твоём варианте оверхед в рантайме, что для синтаксического сахара плохо

Согласен, вааще не вопрос! :rolleyes:

WinAPI и POSIX

D_KEY — Sat, 21 Dec 2024 11:07:30 +0000

D_KEY: Qraizer, норм вроде (позже гляну повнимательнее). Но, сам понимаешь, костыли это все :D

Есть уже boost.parameter. Но тоже костыли (особенно страшно выглядит объявление функций).

Добавлено 21.12.24, 11:08
Majestio, в твоём варианте оверхед в рантайме, что для синтаксического сахара плохо :)

WinAPI и POSIX

Majestio — Fri, 20 Dec 2024 20:21:36 +0000

Majestio:

Цитата Qraizer @ 20.12.24, 18:42

В общем, я тут сварганил на коленке концепцию.

Как всегда :lol: Даже разбираться не буду, мне страшно :lol:

Ну я тоже решил сварганить свой подход:

#include <iostream>

#include <any>

#include <map>

enum class KeyType {

One, Two, Three

};

using ParamsType = std::map<KeyType, std::any>;

void TestFunc(ParamsType param) {

for(const auto &i: param) {

std::cout << "param [";

switch(i.first) {

case KeyType::One: std::cout << "One]: " << std::any_cast<std::string>(i.second); break;

case KeyType::Two: std::cout << "Two]: " << std::any_cast<int>(i.second); break;

case KeyType::Three: std::cout << "Three]: " << std::any_cast<double>(i.second); break;

default: std::cout << "Unknown]";

}

std::cout << std::endl;

}

int main() {

TestFunc({

{KeyType::Two, 2},

{KeyType::One, std::string{"Один"}},

// можно пропустить, а можно не пропустить {KeyType::Three, 2.71828}

});

return 0;

}

param [One]: Один

param [Two]: 2

Позволяет какбэ реализовать именованные параметры, и позволяет параметрам быть необязательными. Но недостатков тоже масса:

1) Гораздо многословнее чем в Dart
2) Проверку наличия обязательных параметров можно обеспечить только проверками в рантайме в теле функции/конструктора/метода
3) Инициализацию по-умолчанию можно реализовать только в рантайме в теле функции/конструктора/метода
4) Чтобы не ошибиться в передаче и последующей обработке имен параметров пришлось запилить enum class

Цитата Qraizer @ 20.12.24, 18:42

Недостатков уйма.

И еще один недостаток ;) Я не смог твой пример откомпилячить тут - https://www.onlinegdb.com. Свой пример я проверил, для С++17.

WinAPI и POSIX

Qraizer — Fri, 20 Dec 2024 18:42:36 +0000

Qraizer:

Цитата Majestio @ 20.12.24, 00:40

Для такой гарантии в WinAPI должны присутствовать системные вызовы с явным указанием желаемых тайм-аутов на исполнение. Оно там действительно есть?

В WinAPI нет, но оно и не RT. Ты тоже невнимателен, я говорил за ядро ОСи. В ядре винды RT вполне себе есть.
Но следует учитывать, конечно, что она никогда не позиционировалась как RTOS, поэтому гарантий MS не предоставляет. И тем не менее анализ ядерного API показывает, что чёткое вытеснение на основе приоритетов там присутствует, и практика это ~~подтверждает~~ ну, не опровергает.

Цитата D_KEY @ 20.12.24, 11:48

Узкая ниша (плюс ещё и перекос на российскую специфику, а я не уверен, что она отражает мировые тренды). Не вижу смысла обсуждать тут, оно не имеет отношения к winapi vs posix.

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

В общем, я тут сварганил на коленке концепцию.

#include <source_location>

#include <iostream>

#include <functional>

#include <type_traits>

#include <cstring>

template <typename Param> struct Node

{

using value_type = Param;

static value_type set(value_type& l, const value_type& r) { return l = r; }

static value_type get(const value_type& v) { return v; }

static inline const value_type default_value = value_type{};

};

template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value_Base

{

static const std::uint_least32_t line = L;

static const std::uint_least32_t column = C;

using node_type = Node<T>;

using value_type= typename node_type::value_type;

value_type value;

Value_Base(): value(node_type::default_value) {}

Value_Base& operator=(const typename node_type::value_type& v) { value = v; return *this; }

};

template <typename T, std::uint_least32_t L, std::uint_least32_t C> struct Value;

#define Prop_Decl(Type) \

struct Value<typename Type::node_type::value_type, Type::line, Type::column>

#define Prop_Impl(Type) \

template<> \

struct Value<typename Type::node_type::value_type, Type::line, Type::column>: public Type \

{ \

public: \

using node_type = typename Type::node_type; \

using value_type= typename node_type::value_type; \

value_type Name; \

public: \

explicit Value(const value_type& v = node_type::default_value): Name(v) {} \

};

#define Prop(Type) \

typedef struct Value_Base<Type, std::source_location::current().line(), \

std::source_location::current().column()>

#define MakeProps(CurProp, ...) Prop_Impl(CurProp) __VA_OPT__(Prop_Impl(__VA_ARGS__))

#define MakeBuilder(Func, CurProp, ...) Builder<Func, Prop_Decl(CurProp) __VA_OPT__(, Prop_Decl(__VA_ARGS__))>

template <typename F, typename Param, typename ...NextParams>

struct Builder: public Param, public Builder<F, NextParams...>

{

template <typename Args>

void setArgs(Args &&args)

{

auto &value= static_cast<Value<typename std::remove_cvref_t<Args>::node_type::value_type,

std::remove_cvref_t<Args>::line,

std::remove_cvref_t<Args>::column>&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

node_type::set(value.Name, args.value);

}

auto doIt()

{

auto &value= static_cast<Value<typename std::remove_cvref_t<Param>::node_type::value_type,

std::remove_cvref_t<Param>::line,

std::remove_cvref_t<Param>::column>&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

return node_type::get(value.Name);

}

explicit Builder(F f): Builder<F, NextParams...>(f) {}

template <typename Arg, typename ...Args>

typename std::function<F>::result_type operator()(Arg arg, Args... args)

{

setArgs(arg); (setArgs(args), ...);

return (this->fn)(doIt(), Builder<F, NextParams...>::doIt());

}

};

template <typename F, typename Param>

struct Builder<F, Param>: public Param

{

template <typename Args>

void setArgs(Args &&args)

{

auto &value= static_cast<Value<typename std::remove_cvref_t<Args>::node_type::value_type,

std::remove_cvref_t<Args>::line,

std::remove_cvref_t<Args>::column>&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

node_type::set(value.Name, args.value);

}

auto doIt()

{

auto &value= static_cast<Value<typename std::remove_cvref_t<Param>::node_type::value_type,

std::remove_cvref_t<Param>::line,

std::remove_cvref_t<Param>::column>&>(*this);

using node_type = typename std::remove_reference_t<decltype(value)>::node_type;

return node_type::get(value.Name);

}

std::function<F> fn;

explicit Builder(F f): fn(f) {}

template <typename Args>

typename std::function<F>::result_type operator()(Args args)

{

setArgs(args);

return (this->fn)(doIt());

}

};

Prop(const char*) param1;

Prop(const char*) param2;

MakeProps(param1, param2);

MakeBuilder(decltype(strcmp), param1, param2) build(strcmp);

int main()

{

std::cout << build(param1() = "abc", param2() = "abc") << std::endl;

std::cout << build(param1() = "abc", param2() = "abd") << std::endl;

std::cout << build(param2() = "abd", param1() = "abc") << std::endl;

std::cout << build(param1() = "abd") << std::endl;

std::cout << build(param2() = "ab" ) << std::endl;

}

Недостатков уйма. Значения по умолчанию по сути не работают (последние два вызова), т.к. задаются только в начале и когда позже перебиваются явными значениями, такими и остаются. Много избыточного, т.к. это третья по счёту наконец-то заработавшая как надо реализация, и мне лень её вычищать и оптимизировать. В конце концов это концепция, а не либа. И да, давненько я не брал в руки препроцессор :D ... Кто если заинтересуется, может заглянуть в мои мультиметоды на гитхабе и стащить оттуда нормальные техники реализации этого безобразия, без препроцесора, со списками типов, нормальной рекурсией по параметрам и деревьям акцепторов. Зато тут уже заложен потенциал стратегии для кастомизации обработки специфических типов параметров (на основе template struct Node) и уже реализована неограниченная N-arity с произвольным порядком передачи параметров в вызов. Второй и третий вызовы показывают, что порядок параметров Builder не влияет на порядок параметров strcmp().
Но лучше, думаю, подождать C++26, куда нам обещали крутейшую рефлексию. Не факт, что успеют, правда.

WinAPI и POSIX

D_KEY — Fri, 20 Dec 2024 11:48:37 +0000

D_KEY:

Цитата Majestio @ 19.12.24, 11:57

Я не слышал по полноценных, 100% перепатченых дистров под реальное время.

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

Добавлено 20.12.24, 11:51

Цитата Qraizer @ 19.12.24, 16:03

Ты можешь нагуглить в лучшем случае прототипы систем бортового управления (сиречь менеджмента). У них 100пудово категория E, по которой сертификация требует базовый набор документов из двух комплектов, и на этом всё. Только Р4754 или может быть 4761. Развернуть прототип и связать с компонентами не проблема. Потому что DAL-E не влияет на безопасность. Мы же говорим о компонентах класса 3А или 3Б с категориями через одного DAL-A/B и C и только изредка D. По ним из стандартов не вылезешь, комплектов документов потребуется 3 десятка по каждому, и их на борту сотни. Не все из них используют ПО, многие только электронные или даже электрические, а некоторые вообще просто механика. Но это неважно, те, которые используют ПО, ты даже близко не нагуглишь. Их вне каналов взаимодействия между сертифицирующими органами и разработчиками, включая подрядчиков, нигде нет... а, ну ещё в архивах.
Вот конкретно сейчас мы занимаемся системой торможения для МС-21. Там четыре (хоть и все ARM, но все разные) микроконтроллера с FLASH на 512Кб и 128Кб RAM. Ну-ну запихать туда что-нить не самописное. И оно на 80% состоит из взаимодействия с железом и остальные 20% чутка логики для обхода отказов, включая события единичного отказа. Самолёты целиком состоят из вот таких на наш/ваш взгляд примитивных вычислительных модулей. Что-либо более-менее серьёзное, хотя бы уровня P5M или там Qualcomm S1, которые мы всерьёз не воспринимаем уже лет 10-20, ставят на что-нибудь сугубо интерфейсное или в салон мультики пассажирам крутить. Просто потому что они ненадёжны, и утеря ими функциональности некритична. Вот это ты можешь нагуглить тоннами, это бизнес. P.S. Бизнес – не безопасность.

Я с тобой во многом не согласен. Но кажется, что это все не имеет отношения к теме дискуссии :)
Так что тут можно закончить. Ты в этом веришся, тебе виднее, наверное.
Узкая ниша (плюс ещё и перекос на российскую специфику, а я не уверен, что она отражает мировые тренды). Не вижу смысла обсуждать тут, оно не имеет отношения к winapi vs posix.

Добавлено 20.12.24, 11:53

Цитата Qraizer @ 19.12.24, 16:03

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

Ну так я и говорю, что костыльность реализации не означает то, что концепция плоха.

Добавлено 20.12.24, 11:55

Цитата Qraizer @ 19.12.24, 16:03

В отличие от именованных аргументов, натянуть на каковые объективный смысл весьма затруднительно

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

Добавлено 20.12.24, 11:56

Цитата Qraizer @ 19.12.24, 17:26

Винда на уровне ядра это гарантирует посредством уровней IRQL.

А можно какую-то ссылку на документацию?

WinAPI и POSIX

Majestio — Fri, 20 Dec 2024 00:40:49 +0000

Majestio:

Цитата Majestio @ 19.12.24, 11:57

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

Цитата Qraizer @ 19.12.24, 17:26

Вот в этом ты ошибаешься. RTOS гарантирует времена откликов.

Ну так это какгбэ одно и тоже, только разными словами :blink: Под гарантией понимается возможность задания времён/таимаутов исполнения.

Цитата Qraizer @ 19.12.24, 17:26

Винда на уровне ядра это гарантирует посредством уровней IRQL.

Цитата Qraizer @ 19.12.24, 17:26

Ну так я говорю, Dart переизобрёл MSное OLE Automation, которой 100 лет в обед.

Дело не в изобретении, а во включении в стандарт языка. Вон там, к примеру, подымали тему лямбд. Тоже могу сказать, что С++ в 2011 году их не изобрели, но их включили в стандарт языка. Я лямбды в Perl пользовал еще в далеком 1997 году, сразу как изучил и начал пользоваться. А сам, еще тогдашний Perl 4, релизнулся в 1993 году.

WinAPI и POSIX

Qraizer — Thu, 19 Dec 2024 17:26:36 +0000

Qraizer:

Цитата Majestio @ 18.12.24, 18:13

А тем более вплетать для этого метапрограммирование - ваще беда. И, если честно, я не совсем понимаю как у тебя это получится. Можешь продемонстрировать?

Именно метой. А для чего её по-твоему в язык ~~ввели~~ впрочем да, ввели-то ещё в C++98 случайно, но вот развили в C++11 уже намерено.
Продемонстрировать... ишь ты. Ну как концепт, можно.

Цитата Majestio @ 18.12.24, 18:13

Вот в этом и фишка подхода в Dart - кроме "поименованной" инициализации есть еще возможность объявлять обязательные и необязательные параметры.

Ну так я говорю, Dart переизобрёл MSное OLE Automation, которой 100 лет в обед.

Добавлено 19.12.24, 17:31

Цитата Majestio @ 19.12.24, 11:57

Понятие "RTOS" не подразумевает оценку отклика системных вызовов, или качества планировщика многозадачности, ... Но самое главное отличие обычной оси от RTOS, в том, что RTOS гарантирует и предоставляет прогеру возможности прогать вызовы в строго детерминированных промежутках времени. В Уиндовс такого не было, нет, и пока слабо ожидается!

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

WinAPI и POSIX

Qraizer — Thu, 19 Dec 2024 16:03:46 +0000

Qraizer:

Цитата D_KEY @ 18.12.24, 15:05

Ну судя по тому, что гуглится, вполне себе наблюдается

Цитата D_KEY @ 18.12.24, 15:24

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

Хм. Лично я помню, что очень сильно плевался на буст, потому что таскать за собой его было накладно, но не лямбды. За лямбды я сожалел, что они хоть и гораздо удобнее функторов, но всё ж недостаточно и ввиду слабой языковой поддержки их эффективность хуже. Но на C++03 большего и не сделать было. Как концепция лямбды мне очень нравились. В отличие от именованных аргументов, натянуть на каковые объективный смысл весьма затруднительно. Те же пропертя, только горизонтально.

Добавлено 19.12.24, 16:21

Цитата D_KEY @ 18.12.24, 15:24

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

Ну, за копипасту я слегонца слукавил всё ж. Обычно, если нужен однотипный код в нескольких местах, где копипаста помогает, там нет мульёна параметров или полей структур. Скажем так: мне не приходилось запускать процессы пачками. А с другой стороны, там, где тебе нужно запустить процесс, довольно сложно сделать это поэтапно, ибо старт процесса – это фактически его конструктор. Разделение создания объекта и его последующей инициализации давно уж признано не самым лучших аспектом ООП-модели, ибо в промежутке между этими этапами объект как ресурс существует, но отсутствует как сущность. Так что всё настраиваемые параметры нового процесса нужны здесь и сейчас, а не потом когда-нибудь.

WinAPI и POSIX

Majestio — Thu, 19 Dec 2024 11:57:08 +0000

Majestio:

Цитата Qraizer @ 18.12.24, 14:14

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

Qraizer, а вот тут, батенька, ты, скорее всего, сам себя заводишь в заблуждение ~~и пацанов туманишь~~! :lol:

Понятие "RTOS" не подразумевает оценку отклика системных вызовов, или качества планировщика многозадачности, или еще чего-то (допустим цвета упаковки коммерческого дистра). Да, если эти параметры на высоте - это супер. Но самое главное отличие обычной оси от RTOS, в том, что RTOS гарантирует и предоставляет прогеру возможности прогать вызовы в строго детерминированных промежутках времени. В Уиндовс такого не было, нет, и пока слабо ожидается! Хотя Гугыль подсказывает - подвижки есть. Пример Windows 10 IoT Enterprise, в котором частично реализовано т.н. "мягкое реальное время". Иными словами, часть возможностей реализована.

Что касается Люникса

Люникс - это не операционная система (это, по сути, просто ядро)! А вот моя любимая Фряха - это полноценная ось. Операционной системой Люникс может быть только в составе дистра(ов). Тогда да.

Что касается RTOS Люникса

Я не слышал по полноценных, 100% перепатченых дистров под реальное время. Да, есть отдельные "флагманы", типа RTLinux, FreeRTOS, Xenomai (но это отдельный догружаемый проект). Таким образом ... пшик :lol: Но есть одно "но", ну достаточно продолжительное время начинают выпускаться ядра Люникса, разделённые на "обычные" и "RT". Пример из моего любимого дистра Manjaro (в красных рамках выделены рилтаймовские ядра):

Screenshot_4.png (, : 489)

И, тем не менее ... Даже если я RT-ядро установлю - от этого моя ось полноценной RTOS не станет! Ядро просто предоставляет для рилтайма низкоуровнёвый интерфейс, ко всем прочим интерфейсам. Как мы определились выше (вернее, я вас определил) - ось это ядро + базовый, коробочный, набор софта. Так вот, если это набор на RT плевать хотел, о какой рилтаймовости может идти речь?

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

WinAPI и POSIX

Majestio — Wed, 18 Dec 2024 18:13:56 +0000

Majestio:

Цитата Qraizer @ 18.12.24, 14:14

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

Не, спасибо. Это мне кажется не одно и тоже. А тем более вплетать для этого метапрограммирование - ваще беда. И, если честно, я не совсем понимаю как у тебя это получится. Можешь продемонстрировать?

Цитата Qraizer @ 18.12.24, 14:14

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

Вот в этом и фишка подхода в Dart - кроме "поименованной" инициализации есть еще возможность объявлять обязательные и необязательные параметры. Случайного пропуска не будет - компилятор не даст. А если пропустили "необязательный", то у него обязана быть инициализация по умолчанию, или он инициализируется null. Т.е. тут большая ответственность лежит на том, кто написал такую функцию, конструктор или метод. У того, кто пользует - все гарантии есть. А про количество аргументов ... более 5-7 (или около того) я считаю извратом. Я о таком уже писал выше. Но всяко же бывает.

WinAPI и POSIX

D_KEY — Wed, 18 Dec 2024 15:24:59 +0000

D_KEY:

Цитата Qraizer @ 18.12.24, 14:14

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

Сам же и ответил. И не надо делать вывод, что раз костылями для реализации концепции не пользуются, то и сама концепция не нужна. Я помню, как люди плевались на бустовые лямбды, например. Но как только лямбды появились в языке (стандарте), то почему-то все начали пользоваться.
Потому что проблема в самих костылях, а не концепции.

Добавлено 18.12.24, 15:27

Цитата Qraizer @ 18.12.24, 14:14

Я в общем-то могу повторить про чемлучшемульёнполей буквально.

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

Добавлено 18.12.24, 15:32

Цитата Qraizer @ 18.12.24, 14:14

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

Не знаю, что там в windows. Линукс раньше и не был rtos, были отдельные версии linux для rtos. Сейчас, насколько я знаю, linux умеет работать в real time режиме (вроде в этом году смержили наконец-то патчи, которые жили много лет отдельно). Для windows это не так :)

WinAPI и POSIX

D_KEY — Wed, 18 Dec 2024 15:05:35 +0000

D_KEY:

Цитата Qraizer @ 18.12.24, 14:14

Я говорил не об изделиях, а о средствах их разработки, верификации и сертификации.

А, ну тогда это вообще большого значения не имеет, ИМХО. На чем угодно можно разрабатывать :-?

Добавлено 18.12.24, 15:08

Цитата Qraizer @ 18.12.24, 14:14

Изделия-то зачастую работают вообще на чём-то самописном, где и POSIX даже близко не наблюдается.

Ну судя по тому, что гуглится, вполне себе наблюдается :)
Сам я довольно мало работал с rtos и давно. Но это был ecos, который posix слой предоставлял.

Ну и мы все упёрлись зачем-то в очень узкую нишу.

Пока считаю свой тезис о том, что POSIX таки является стандартом для ОСей и таки реально реализуется и используется, верным.
Точно так же как тезис о том, что winapi подобным стандартом не является и потому сравнивать это с posix некорректно.

WinAPI и POSIX

Qraizer — Wed, 18 Dec 2024 14:14:58 +0000

Qraizer:

Цитата Majestio @ 17.12.24, 19:01

В языках программирования нового поколения (Dart, и как оказалось, и Swift) ввели понятие "именованных параметров". Там это решается проще - просто при инициализации указываем те параметры, которые явно нужно определить (по именам параметров), остальные инициализируются по умолчанию.

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

struct

{

LPCSTR lpApplicantName,

LPCSTR lpPropertyAddress,

LPCSTR lpLoanType,

double dLoanAmount,

int nLoanTerm,

double dInterestRate,

BOOL bFixedRate,

LPCSTR lpCreditScore,

LPCSTR lpEmploymentStatus,

LPCSTR lpIncomeVerification,

BOOL bCoApplicant,

LPCSTR lpCoApplicantName,

LPCSTR lpCoApplicantCreditScore,

LPCSTR lpDownPaymentSource,

double dDownPaymentAmount,

LPCSTR lpPropertyType,

BOOL bFirstTimeHomeBuyer,

LPCSTR lpLoanOfficerName,

LPCSTR lpApplicationID,

BOOL bPreApproval,

LPCSTR lpReferralSource,

LPCSTR lpContactMethod,

BOOL bEmailUpdates,

LPCSTR lpPreferredClosingDate,

LPCSTR lpInsuranceProvider,

LPCSTR lpPropertyInspectionStatus,

LPCSTR lpAppraisalValue,

BOOL bEscrowAccount,

LPCSTR lpMonthlyPaymentEstimate,

LPCSTR lpLoanDisclosureDocuments,

LPCSTR lpAdditionalNotes,

BOOL bSubmitApplication

) SuperCoolStruct_VS_DeepShitParams, *PSuperCoolStruct_VS_DeepShitParams;

BOOL OpeningMicrosoftMortgage(PSuperCoolStruct_VS_DeepShitParams cfg);

и напомнить, что memset() (неважно, что подкапотный) не решает траблю, т.к. далеко не всегда нулевая последовательность бит подходит для значения по умолчанию. Я поступлю по другому, а именно спрошу "дорогой Majestio, откуда у тебя выродилась такая гора входов в одну подсистему?", а потом "как система защищена от человеческого фактора? как она реагирует на случайный пропуск инициализации одного поля? а двух? а десятка потому что скопипастил, и поправил со сдвигом в две строки?" Я об этом уже писал выше, третий раз не буду.

Цитата D_KEY @ 18.12.24, 08:17

Ты сам пишешь про rtos, но винда к ним не относится

Ты возможно удивишься, но ядро у винды на порядок более реалтаймое, чем у линукса. Я даже под Win98SE в своё время получал гарантированные микросекунды реакции, тогда как соседний nix-овый отдел оперировал миллисекундами. Под WinXP ситуация не поменялась, а как нынче у того отдела, беспонятия, меня в том КБ уже 20 лет нету. И не надо, что мол ядро и прикладной уровень не сравнимы. Да, не сравнимы, но прикладное ПО с требованиями жёсткого реал-тайма и проектируются соответственно, одного только наличия RTOS недостаточно.

Цитата D_KEY @ 18.12.24, 08:17

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

Скорее просто случайное совпадение аббревиатур. Хотя вариант с развитием ОСи в направлении мультиплатформенности тоже может быть. Тогда действиетльно Honeywell могла взять что-то старое и 20 (?) лет использовать в своих продуктах, а ОСь с тех пор эволюционировала. На тот момент в тестируемых нами шелезяках были P5 и i486.

Цитата D_KEY @ 18.12.24, 08:17

Ты хочешь сказать, что в их "RTOS" под капотом была винда?

Нет. Что её API основан на WinAPI. Реализация ОСи в лучшем случае (не факт, ессно) была лицензирована с Windows CE, которая, как известно, с Windows, кроме API, общего ничего не имеет. Это тем более вероятно, что даже их тестовая среда TATS использовала VBScript под лицензией с некоторыми расширениями языка типа групп, драйверов, мониторов итп. (Это всё не те группы, драйверы и мониторы в известном смысле, это названия подсистем тестирования, управляющие входами и контролирующие выходы.)

Цитата D_KEY @ 18.12.24, 08:17

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

WinAPI и POSIX

D_KEY — Wed, 18 Dec 2024 08:17:44 +0000

D_KEY:

Цитата Qraizer @ 17.12.24, 10:18

Какие тебе примеры? Falcon, Boeing, Embraer — недостаточно? Могу ещё с десяток наименований накидать.

Тут проблема в том, что в публичной информации нет никакого упоминания про windows, есть информация про разные rtos и они основаны не на винде, а или на чем-то своем или на линуксах. И даже когда на своем, то есть как минимум частичная реализация posix. Про WinAPI ни слова.

Добавлено 18.12.24, 08:21

Цитата Qraizer @ 17.12.24, 10:18

Вся авионика, с которой я сталкивался, разрабатывается и сертифицируется под виндой.

Ты сам пишешь про rtos, но винда к ним не относится :-? (были какие-то древние rtos виндовоподобные, но мы холиварим сейчас).

Добавлено 18.12.24, 08:23

Цитата Qraizer @ 17.12.24, 10:18

Цитата D_KEY @ 15.12.24, 19:42

Вот офсайт вроде: DEOS

Это не та DEOS, то была собственная.

Так DEOS они и делают вроде :-?
Может раньше была какая-то старая и другая, а сейчас перешли на что-то новое? Почему не гуглится ничего?

Ты только правильно пойми, я тебе верю больше, чем себе, но для холивара нужно что-то более существенное :)

Добавлено 18.12.24, 08:27

Цитата Qraizer @ 17.12.24, 10:18

Хошь кусочек заголовков?

Извини за нубские вопросы. Ты хочешь сказать, что в их "RTOS" под капотом была винда?

WinAPI и POSIX

Majestio — Tue, 17 Dec 2024 19:01:04 +0000

Majestio:

Цитата Qraizer @ 17.12.24, 10:18

И что с ними не так? Регистров не хватает, компилеру приходится стек юзать? Ай-яй-яй.

С ними не хватает ... Нормального подхода. Просто подход - полное говно! :lol: Очень часто туча параметров задаётся по умолчанию. И их всех нужно явно указывать. Но если мы более внимательно, чем менее, зададимся вопросом "а как бы лучше сделать", то сразу обратим свое внимание на паттерн проектирования "Строитель". Иными словами, сперва просто создаем объект/сущность. А потом из его 32-х параметров задаём там три нам очень нужные путём вызова сеттеров. И замечу, это не обязательно С++, такое и в Си можно и нужно было бы сделать, в рамках WinAPI.

Добавлено 17.12.24, 19:12
В языках программирования нового поколения (Dart, и как оказалось, и Swift) ввели понятие "именованных параметров". Там это решается проще - просто при инициализации указываем те параметры, которые явно нужно определить (по именам параметров), остальные инициализируются по умолчанию. В этом случае можно обойтись и без "строителя", но и вызов будет гораздо компактнее.

Добавлено 17.12.24, 19:14

Цитата Qraizer @ 17.12.24, 10:18

Ну так VB.NET. И ещё VBA. А ещё так можно в IDispatch. Только какое отношение это имеет в API?

Такое не говори! У меня от такого бабки в подъезде крестятся! :rolleyes:

WinAPI и POSIX

Qraizer — Tue, 17 Dec 2024 10:18:54 +0000

Qraizer:

Цитата D_KEY @ 15.12.24, 16:52

А что-то сертифицируется на WinAPI? Я пока так и не увидел примеров от тебя.

Какие тебе примеры? Falcon, Boeing, Embraer — недостаточно? Могу ещё с десяток наименований накидать. Вся авионика, с которой я сталкивался, разрабатывается и сертифицируется под виндой. У нас как-то был один проект на LynxOS, договора благополучно подохли (потому что французы; и это не первый раз с ними, никогда с французами не работайте) в 18-м, наклюнулся было ещё один, на этот раз отечественный, сдулся из-за недостатка финансирования.

Цитата D_KEY @ 15.12.24, 19:42

Вот офсайт вроде: DEOS

Это не та DEOS, то была собственная. Нафик им вовне выкладывать собственные IP. Хошь кусочек заголовков?

#ifndef DEOS_H

#define DEOS_H

#include <windows.h>

#define semaphoreHandle HANDLE

#define semaphoreStatus int

#define timeoutSpecifier unsigned int

#define waitIndefinitely 0xFFFFFFFF

#define semaphoreSuccess 0

#define process_handle_t HANDLE

int waitSemaphore( HANDLE handle, unsigned int timeout );

int signalSemaphore( HANDLE handle );

void waitUntilNextPeriod( );

...

#ifndef EVENTAPI_H

#define EVENTAPI_H

** HHdr-beg ****************************************************************

** Copyright Honeywell Inc 03/01/96

** Honeywell Proprietary

** Include File name: EVENTAPI.H

** Purpose:

** Everything needed to call event related DEOS API functions.

** Note: This header file MUST be compatible with a "C" compiler.

** HPrj-beg ****************************************************************

** HPrj-end ****************************************************************

** HHdr-end ****************************************************************

...

#ifdef __cplusplus

extern "C" {

#endif

DEOSBASEAPI eventStatus DEOSKERNAPI createEvent(const char * name, eventHandle *createdEvent);

DEOSBASEAPI eventStatus DEOSKERNAPI getEventHandle(

const char * name, process_handle_t procHand, eventHandle *createdEvent);

DEOSBASEAPI eventStatus DEOSKERNAPI waitForEvent(eventHandle theEventHandle, timeoutSpecifier timeout, DWORD currentCount);

DEOSBASEAPI eventStatus DEOSKERNAPI pulseEvent( eventHandle theEventHandle );

DEOSBASEAPI DWORD DEOSKERNAPI eventPulseCount( eventHandle theEventHandle );

DEOSBASEAPI eventStatus DEOSKERNAPI deleteEvent( eventHandle theEventHandle );

DEOSBASEAPI eventStatus DEOSKERNAPI grantEventAccess( eventHandle theEventHandle, process_handle_t processHandle, eventAccessRightsType access, bool grantToAllProcesses );

#ifdef __cplusplus

}

#endif

...

Думаю, хватит. Вроде ничего из конфиденциального не слил, но плз, не распространяйте. Этому коду 15 лет от последнего использования нами. Контракты кончились в кризис 08-09 годов, как у них там нынче, беспонятия.

Цитата Majestio @ 15.12.24, 21:08

Посмотрите на количество аргументов функций, а-ля CreateProcess, NtCreateUserProcess, CreateProcessAsUser, RegCreateKeyEx, NtCreateSection. Это же не хухры-мухры, это уже просто мама-дарагая!

И что с ними не так? Регистров не хватает, компилеру приходится стек юзать? Ай-яй-яй.

Добавлено 17.12.24, 10:20

Цитата Majestio @ 15.12.24, 21:08

Ради прикола, ну и кому не лениво, посмотрите, пожалуйста, как красиво и изящно это обыгрывается в языке программирования Dart

Ну так VB.NET. И ещё VBA. А ещё так можно в IDispatch. Только какое отношение это имеет в API?

WinAPI и POSIX

Majestio — Sun, 15 Dec 2024 22:56:58 +0000

Majestio:

Цитата D_KEY @ 15.12.24, 21:37

Еще раз, winapi корректно сравнивать с API какой-то конкретной ОС. А не с POSIX.

Не - ну ту без вопросов! WinAPI - это ~~местячковая~~ корпоративная спецификация. А вот POSIX - хош-не-хош, а это уже стандарт.

WinAPI и POSIX

Majestio — Sun, 15 Dec 2024 21:53:43 +0000

Majestio:

Цитата D_KEY @ 15.12.24, 21:37

Dart не изучал

Ну я сцылку дал - не поленись, посмотри :lol:

Добавлено 15.12.24, 21:55

Цитата D_KEY @ 15.12.24, 21:37

как в Swift сделано

Бегло глянул - мне кажется почти один-в-один :-?

WinAPI и POSIX

D_KEY — Sun, 15 Dec 2024 21:37:01 +0000

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

Добавлено 15.12.24, 21:42

Цитата Majestio @ 15.12.24, 21:08

Да, как писали выше, уже есть костыли в виде epool/kqueue. Но тут, положа честную руку на моё самое доброе сердце - венда тут на этаж впереди.

Я еще раз напомню, что сранивать некорректно. Захотели MS ввести какой-нибудь IOCP и все, в следующей версии ждите. Одна компания, одно семейство ОС. А теперь для POSIX. Когда-то унифицировали select/poll. Потом времена поменялись, стало недостаточно, разные *nix системы пошли чуть разными путями, придумали epoll(linux), kqueue(*bsd), а сейчас в linux все больше обороты набирает io_uring. И это круто, что в разных ОС продолжают эксперементировать. Это развитие. Но что вы хотите от POSIX? Чтобы он побежал описывать разные эксперементальные штуки и обязал тем самым кучу разных компаний и ОС это все реализовывать? Это же требует согласований. И сертификации.

Еще раз, winapi корректно сравнивать с API какой-то конкретной ОС. А не с POSIX.

Добавлено 15.12.24, 21:51

Цитата Majestio @ 15.12.24, 21:08

красиво и изящно это обыгрывается в языке программирования Dart

Dart не изучал, мне нравится, как в Swift сделано

WinAPI и POSIX

Majestio — Sun, 15 Dec 2024 21:08:17 +0000

Majestio: Хе-хе ... немножко про WinAPI ;)

В моем "личном зачёте" для WinAPI я бы поставил оценку "удовлетворительно". Нельзя сказать что сей стандарт полное удобрение. Кстати, я пишу с Венды. Нет, в нем есть очень и очень здравые моменты проектирования. Меня больше всего радует объектно-событийный подход к проектированию. Мое скромное ИМХО, это - та бомба, которую до сих пор не изобрели и не унифицировали в POSIX. Да, как писали выше, уже есть костыли в виде epool/kqueue. Но тут, положа честную руку на моё самое доброе сердце - венда тут на этаж впереди.

Но есть и тяжелое наследие

Я имею ввиду Си-наследие. Когда зарплаты платились по 1.5 индийских рупий за килограмм кода. Нужно было добывать, майнить строки и объёмы. Посмотрите на количество аргументов функций, а-ля CreateProcess, NtCreateUserProcess, CreateProcessAsUser, RegCreateKeyEx, NtCreateSection. Это же не хухры-мухры, это уже просто мама-дарагая! :blink:

Я вот тоже решил немножко закинуть гиперболоид в тему топика. Как вам моя функция в стиле WinAPI Futures? :lol:

BOOL OpeningMicrosoftMortgage(

LPCSTR lpApplicantName,

LPCSTR lpPropertyAddress,

LPCSTR lpLoanType,

double dLoanAmount,

int nLoanTerm,

double dInterestRate,

BOOL bFixedRate,

LPCSTR lpCreditScore,

LPCSTR lpEmploymentStatus,

LPCSTR lpIncomeVerification,

BOOL bCoApplicant,

LPCSTR lpCoApplicantName,

LPCSTR lpCoApplicantCreditScore,

LPCSTR lpDownPaymentSource,

double dDownPaymentAmount,

LPCSTR lpPropertyType,

BOOL bFirstTimeHomeBuyer,

LPCSTR lpLoanOfficerName,

LPCSTR lpApplicationID,

BOOL bPreApproval,

LPCSTR lpReferralSource,

LPCSTR lpContactMethod,

BOOL bEmailUpdates,

LPCSTR lpPreferredClosingDate,

LPCSTR lpInsuranceProvider,

LPCSTR lpPropertyInspectionStatus,

LPCSTR lpAppraisalValue,

BOOL bEscrowAccount,

LPCSTR lpMonthlyPaymentEstimate,

LPCSTR lpLoanDisclosureDocuments,

LPCSTR lpAdditionalNotes,

BOOL bSubmitApplication

);

Ради прикола, ну и кому не лениво, посмотрите, пожалуйста, как красиво и изящно это обыгрывается в языке программирования Dart. Сорян, ссылаюсь на свой же сайт - но это во благо :lol: Поищите там подраздел "Именованные аргументы". Там очень-очень красиво - ящетаю!

WinAPI и POSIX

Majestio — Sun, 15 Dec 2024 19:57:12 +0000

Majestio:

Цитата D_KEY @ 15.12.24, 19:42

Про WinAPI ни слова.

Возможно Qraizer где-то немного попутал :lol: Там действительно есть упоминания про Венду. Но это в плане окружения для разработки, но не исполнения. Скриню:

Screenshot_2.png (, : 395)

WinAPI и POSIX

D_KEY — Sun, 15 Dec 2024 19:42:08 +0000

D_KEY: Вот офсайт вроде: DEOS

Про WinAPI ни слова.

Есть немного про POSIX:

Цитата

Deos™, DDC-I’s safety-critical time and space partitioned real-time operating system (RTOS) that has been verified to the guidance of DO-178C/ED-12C Design Assurance Level A (DAL A) for Avionics Applications, supports ARINC 653 APEX, Rate Monotonic Scheduling (RMS), and is targeted at the Future Airborne Capability Environment (FACE™) Safety Extended and Safety Base Profiles. Deos is the first RTOS to receive OSS Conformance Certification for the FACE Technical Standard, Edition 3.1. The Safety Extended Profile, which adds support for TCP/IP communications, multi-process support, and expanded POSIX capability (80 extra functions), is a superset of the functionality required by the Safety Base and Security Profiles

:-?

Добавлено 15.12.24, 19:45
И от них же вроде есть HeartOS, которая POSIX.

WinAPI и POSIX

Majestio — Sun, 15 Dec 2024 19:35:14 +0000

Majestio:

Цитата Qraizer @ 15.12.24, 15:07

DEOS построена на WinAPI.

Гугыль молчит. А чят-гпт крутит пальцем у виска. Но последнему доверие так себе - научился врать ппц.

WinAPI и POSIX

D_KEY — Sun, 15 Dec 2024 19:32:28 +0000

D_KEY:

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 14.12.24, 10:55

Чем это лучше-то?

Два результата сразу: bool и int, причём смысл последнего разный в зависимости от bool. Удобно

Чем это лучше std::expected того же? Я уже не говорю про безопасный код и пр.

WinAPI и POSIX

D_KEY — Sun, 15 Dec 2024 16:52:44 +0000

D_KEY:

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Ну нагрузочное проходит регулярно. И все равно продакшн - это продакшн :D

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%.

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

А что-то сертифицируется на WinAPI? Я пока так и не увидел примеров от тебя.

Цитата Qraizer @ 15.12.24, 15:07

Цитата D_KEY @ 13.12.24, 23:42

А разве это не linux?

Вопрос Majestio был за API, а не ОС. И я сразу предупредил, что это не совсем то.

Ну т.е. там POSIX поддержан хотя бы отчасти, а winapi - нет. Верно?

Цитата Qraizer @ 15.12.24, 15:07

Гуглится довольно плохо. И вроде как там тоже POSIX (но не уверен). А с HeartOS не работал? Она точно POSIX, как я понял.

Цитата Qraizer @ 15.12.24, 15:07

DEOS построена на WinAPI.

А можно подробнее? Гуглится плохо, вместе с winapi вообще ничего не нашел. Есть упоминание POSIX, но как-то невнятно.

Без обид, но ты как-то очень сильно зациклен на довольно узкую нишу, в которой работаешь :)

WinAPI и POSIX

Qraizer — Sun, 15 Dec 2024 15:07:38 +0000

Qraizer:

Цитата D_KEY @ 13.12.24, 23:42

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Ну это вы у себя никогда RFS не проводили, оно у нас занимает ~месяца со 100% нагрузкой всех подключённых исполнительных устройств. И ещё WCET, который увеличивает нагрузку раз в 10. Но так-то да, в обычном режиме нагрузка невелика. Если не считать, что в это время стенд обслуживает "кривые поделки", ещё не отлаженные.

Цитата D_KEY @ 13.12.24, 23:42

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%.

Цитата D_KEY @ 13.12.24, 23:42

А разве это не linux?

Вопрос Majestio был за API, а не ОС. И я сразу предупредил, что это не совсем то.

Цитата D_KEY @ 14.12.24, 10:55

Чем это лучше-то?

Два результата сразу: bool и int, причём смысл последнего разный в зависимости от bool. Удобно

Добавлено 15.12.24, 15:13

Цитата D_KEY @ 14.12.24, 10:55

А WinAPI?

Наш лучший в 0-ых импортный партнёр Honeywell, чьим подрядчиком был наш основной московский заказчик, и который сам был одним из подрядчиков Boeing, вовсю использовал свою DEOS. Она использовалась на куче всякоразного коммерческого летающего, от Агусты и Цесны до Эмбрайров и Хоризонов. DEOS построена на WinAPI.
И кстати, процессы у Honeywell были бесподобные. Мы в своё время многое из них почерпнули как образец для подражания. (Я даже с их подсистемы групп, основанных на скриптовании тестовых воздействий и исполнении их прямо на исполнительных устройствах, слизал архитектуру реал-тайм чеков для внедрения в функциональных тестовых окружениях. И улучшил, конечно :) .) Наши нынешние отечественные заказчики и близко по их качеству не валялись. Ну вот Labs разве что похожа, но пока рано судить, мы с ними только начали.

WinAPI и POSIX

D_KEY — Sat, 14 Dec 2024 11:05:51 +0000

D_KEY: Ну все тогда, холивар считаем закрытым :lol:

WinAPI и POSIX

Majestio — Sat, 14 Dec 2024 11:01:58 +0000

Majestio:

Цитата D_KEY @ 14.12.24, 10:55

А WinAPI?

:blink:

WinAPI и POSIX

D_KEY — Sat, 14 Dec 2024 10:55:36 +0000

D_KEY:

Цитата Majestio @ 14.12.24, 09:58

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

А WinAPI? :D

Добавлено 14.12.24, 10:56

Цитата macomics @ 14.12.24, 10:51

Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

Чем это лучше-то?

WinAPI и POSIX

macomics — Sat, 14 Dec 2024 10:51:54 +0000

macomics:

Цитата D_KEY @ 13.12.24, 23:42

Пишешь под DOS?

Освежите у себя в памяти DOS API. Там было простое и элегантное решение по определению ошибок. Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

WinAPI и POSIX

Majestio — Sat, 14 Dec 2024 09:58:09 +0000

Majestio:

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

Но гугление немного прояснило суть последних тем. POSIX - это считают стандартом, а ARINC-653 - это спецификация, стандартизующая определенный интерфейс(ы). Таким образом, POSIX - предназначен для обеспечения переносимости и повторного использования кода. Тогда как ARINC-653 предназначена для обеспечения пространственной и временной разделяемости в критически важных авионических системах реального времени. И не только в авионических, в любых RTOS системах, где безопасность и надежность являются критически важными. Сюда можно отнести и космонавтику, и военные системы. Таким образом наблюдается "перпендикулярность" :lol: Ибо они решают совсем разные проблемы проектирования.

WinAPI и POSIX

D_KEY — Sat, 14 Dec 2024 09:15:27 +0000

D_KEY:

Цитата D_KEY @ 13.12.24, 23:42

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас.

А разве это не linux?

Или ты имеешь в виду VxWorks? А она разве POSIX не поддерживает?

WinAPI и POSIX

D_KEY — Fri, 13 Dec 2024 23:42:25 +0000

D_KEY:

Цитата Qraizer @ 13.12.24, 16:26

Почему это не считается?

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Впрочем, ты прав, возможно что у вас супер стенды со всем вышеперечисленным и имитацией реальных запросов с реальными данными, реальной частотой и пр.

Добавлено 13.12.24, 23:50

Цитата Qraizer @ 13.12.24, 16:26

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

Ну термины нельзя использовать правильно или неправильно. О терминах договариваются.

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

Добавлено 13.12.24, 23:52

Цитата Qraizer @ 13.12.24, 16:26

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

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%. А у топовых компаний процент ещё выше.

Добавлено 14.12.24, 00:04

Цитата macomics @ 13.12.24, 16:37

Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

И что ты предлагаешь? Писать софт на asm x86 из-за этого?
И в чем костыльность std:: expected?

Добавлено 14.12.24, 00:06

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

А разве это не linux?

Добавлено 14.12.24, 00:07

Цитата macomics @ 13.12.24, 18:13

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

Пишешь под DOS?

WinAPI и POSIX

macomics — Fri, 13 Dec 2024 18:13:27 +0000

macomics:

Цитата Qraizer @ 13.12.24, 17:16

macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

WinAPI и POSIX

Qraizer — Fri, 13 Dec 2024 17:16:21 +0000

Qraizer:

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас. Причём это вполне себе полноценная ОСь, в ней даже слой OpenGL есть. Но и стоят такие ОСи баснословно. Гораздо чаще выходит дешевле написать свою realtime ОСь на коленке, полностью её оттестировать модульными (а как иначе, если это тупо набор .o собранных в набор либ) со 100% покрытием, предоставить отчёты по WCET и WCSU, разработать и предоставить наборы сценариев для квалификационных её испытаний в составе будущего прикладного ПО под неё и сертифицировать в таком виде.

Добавлено 13.12.24, 17:21
macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

WinAPI и POSIX

Majestio — Fri, 13 Dec 2024 16:42:58 +0000

Majestio:

Цитата Qraizer @ 13.12.24, 16:26

Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения. Но, тут соглашусь, не слышал - но варик достойный! Ибо решает вопросы не все, но в своей теме. Тут уважуха!

WinAPI и POSIX

macomics — Fri, 13 Dec 2024 16:37:11 +0000

macomics: Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

WinAPI и POSIX

Qraizer — Fri, 13 Dec 2024 16:26:47 +0000

Qraizer:

Цитата D_KEY @ 11.12.24, 14:46

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

Почему это не считается? Там полноценная ОСь, без отключений чего-либо и кастраций, даже Защитник работает. Файрволл, правда, отключён. Или ты имеешь в виду рабочие нагрузки? Ты ж их даже не спросил.
У меня такое впечатление, что ты неправильно употребляешь термин "сервис". Стандартные сервисы из ОСи вполне себе надёжны, аптайм как бы вот он. Самописные... ну по реализации они не сервисы, но по факту они самые, т.к. работают те же 24/7. Может быть у вас там с виндой не всё гладко просто потому, что спецы по сервисам не такие уж и спецы? Это не наезд ни в коем случае, создание сервисов не вполне то же самое, что обычных приложений. Я вот по демонам никакой, не приходилось за ненадобностью.
А так-то в целом... не думаю, что открою большой секрет: все процессы разработки и верификации флай-кода ориентированы на винду. POSIX встречается крайне, реально крайне, вот прям очень крайне редко. Как исполнительная платформа для эмбеддед – бывает, но там обычно форкают, ~~кастрируют~~ скорее даже режут по живому, оставляя только потенциально требуемый минимум функционала. Мы как-то занимались верификацией RTEMS для одного из заказчиков, отправленное количество Сообщений о Проблемах я не припомню, но на каждый модуль (архитектурный) десяток в среднем набирался. Где-то больше, где-то меньше. Та ёлки, там баги даже в системных заголовках были, явно расходились с даташитами к PPC. И это притом, что RTEMS на MPC5200 вполне себе официально портирована и довольно давно.

Добавлено 13.12.24, 16:30
Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

WinAPI и POSIX

Majestio — Fri, 13 Dec 2024 16:09:22 +0000

Majestio:

Цитата D_KEY @ 11.12.24, 14:46

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу

Наброшу и плюсую :lol: Законный вопрос: а есть какойта более другой способ стандартизации и унификации программных вызовов в сериях независимых осей, кроме как POSIX?

WinAPI и POSIX

D_KEY — Wed, 11 Dec 2024 14:46:26 +0000

D_KEY:

Цитата Qraizer @ 11.12.24, 14:31

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года

Ну стендовая это не считается :D
На моем опыте аптайм на линуксах был всегда очень хороший на реальных серваках. И был всегда такой себе на windows. Но может там админы плохие были у нас, не знаю :-?

Добавлено 11.12.24, 14:49

Цитата Qraizer @ 11.12.24, 14:31

Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY.

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

Добавлено 11.12.24, 14:53

Цитата Qraizer @ 11.12.24, 14:31

Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу :)

WinAPI и POSIX

Qraizer — Wed, 11 Dec 2024 14:31:01 +0000

Qraizer:

Цитата D_KEY @ 10.12.24, 20:16

Явно надежнее сервисов под windows, кстати.

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года, с момента их переезда с нашего этажа. Четыре штуки. Они от инета отключены, поэтому обновлений на них не прилетает, ребутать нет причин. Свет вырубался, но они под UPSами и хибернетом. Да, мои апликухи там тоже есть. Не оформлены сервисами, но по факту они самые. (Одну из них ты даже должен помнить, архитектуру я малёхо описывал в теме про объекты синхронизации.) С аптаймом поменьше, потому как они изредка апдейтятся под меняющиеся ТЗ на них.
Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY. Я легко могу поверить и пруфов не потребую, что у тебя там всё хорошо. Потому что вот конкретно твоё окружение не имеет проблем. Вот только когда речь заходит за высококритичное ПО, во главу угла ставится документация, а не испытания. И коли там сказано, что вот так оно могёт быть, твоё ПО не пройдёт аудит, если ты не предусмотришь у себя обработку сего. И пофик, что структурное покрытие его никогда не покроет. Будет написан модульный тест, имитирующий оговоренный отказ. Готовить своё приложение для такого случая придётся. Каждое приложение для каждого подобного случая. Можешь сам зайти на маны, почитать и посчитать ноуты под каждой функцией и прикинуть объём "никому не нужной" работы.
P.S. Библиотеки не спасут вообще ни разу. Только хуже сделают, т.к. для них тоже будет аудит. Я как-то уже упоминал, что флай-код в авионике отключает стандартные библиотеки и в лучшем случае пилит их аналоги, обычно сильно упрощённые. Так их хоть как-то можно сертифицировать за разумные деньги. А уж за third party и говорить нечего.

Цитата D_KEY @ 10.12.24, 20:16

Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.

Возможно. Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

WinAPI и POSIX

D_KEY — Tue, 10 Dec 2024 20:16:31 +0000

D_KEY:

Цитата Qraizer @ 10.12.24, 19:39

Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки.

Писал в течение некольких лет, все было в порядке. Явно надежнее сервисов под windows, кстати. Хотя там сама ОС чудила чаще :D

Добавлено 10.12.24, 20:26

Цитата Qraizer @ 10.12.24, 19:39

Ну весело же.

Нормально :)
Поверь мне, это будет последнее из-за чего упадет твой сервис :D

Цитата Qraizer @ 10.12.24, 19:39

При чем тут это? У тебя один и тот же тип объектов, возвращенный разными функциями, при ошибке то будет равен одному значению, то другому, в зависимости от конкретной функции. Постоянно нужно сверятся с документацией конкретной функции. Это просто странно.

Цитата Qraizer @ 10.12.24, 19:39

Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.

У POSIX всегда будет -1. А для указателей всегда будет NULL (если одна единственная функция, которая действует не так из-за легаси, но ее очень редко используют - sbrk).

Цитата Qraizer @ 10.12.24, 19:39

Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора.

Не согласен. С объектами гораздо легче работать, чем с параметрами функций. Их удобо отдельно валидировать, сохранять, модифицировать и т.д.
Писать обертки для C++ так же удобнее.

Цитата Qraizer @ 10.12.24, 19:39

Параметр ты не пропустишь, инициализацию поля же легко.

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

Ну и вообще функции с миллионом параметров в принципе означают плохой дизайн. Классика же, "If you have a procedure with 10 parameters, you probably missed some" :D

Добавлено 10.12.24, 20:35
А вообще, еще раз, странно сравнивать. Оба API уродливы, каждый по своему (мне posix нравится больше winapi, но он все равно кривой). При этом POSIX касается большого числа совершенно разных ОС, от совершенно разных производителей и для разных задач. Соответственно, кривость хоть как-то можно оправдать. В случае winapi, который является поделкой одной единственной компании, наличие косяков выглядит более странным.

Добавлено 10.12.24, 20:40
Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.
Не было такого, что сначала кто-то придумал стандарт, а остальные начали его реализовывать, делая с нуля свои ОС.

WinAPI и POSIX

Qraizer — Tue, 10 Dec 2024 19:39:00 +0000

Qraizer:

Цитата Majestio @ 10.12.24, 14:47

Ты просто пойми, что линупсы и их апдейты растут как грибы - и гораздо чаще твоей сраной венды апдейтяться! И самое главное, а ни не просто растут - а выставляют стабильные и LTS ветки.

Ну так я и назвал это зоопарком. Ты пытаешься этим оправдать для себя несовместимость их API? Ну так вспомни, что я вот буквально только что писал про стандартизацию Языка. Оказывается, так можно.
А венда обновляется чаше, чем тебе кажется. Дважды в год. LTS на этом фоне выглядят как-то скромненько.

Добавлено 10.12.24, 19:56

Цитата D_KEY @ 10.12.24, 16:27

Что я, как разработчик софта, тут изменю в своем коде выше?

Ничего. Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки. Знаешь, если атомарная операция не гарантирует атомарности... ну это ж POSIX же, чё. В WinAPI никогда новый HANDLE не будет выдан, если он полностью не вышел из использования. А вот в POSIX мультипотоковое ПО, оказывается, должно само об этом заботиться. Ну весело же.

Цитата D_KEY @ 10.12.24, 16:27

Так будет код-то?

А тебе мало было, что ли? Чай не первый холивар-то.

Цитата D_KEY @ 10.12.24, 16:27

Зоопарк разнородных подходов (пример привел выше с handle), функции с миллионом параметров, монструозные структуры данных и т.д. и т.п.

Пример с INVALIDE_HANDLE_VALUE чётко следует (внезапно) POSIXовой же традиции при ошибках возвращать -1, потому что бинарно с ним совместим, а бинарно совместимый с нулём NULL является вполне себе корректным stdin. В совокупности это нивелирует проблемы совместимости с криво писаным легаси, которые в 90-ых были весьма значимы. Нынче это не проблема, однако совместимость документированных интерфейсов ОСей требует. Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.
Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора. Параметр ты не пропустишь, инициализацию поля же легко. Особо важные параметры, которые если поменять местами, могут поломать поведение кода из-за незамеченной ядром ошибки их порядка в аргументах, не пройдут компиляцию из-за несовместимых типов. Это вам не int на все случаи жизни. А за монструозные структуры вообще странно в контексте негатива в адрес миллиона параметров. Я вот счас ещё вспомню про версии API, которые в WinAPI определяются элементарно sizeof() в первом поле, а в POSIX как (c_legacy_cast)какой_то_поинтер_на_мамой_клянусь_правильную_структуру. Ой, вспомнил.

WinAPI и POSIX

D_KEY — Tue, 10 Dec 2024 16:49:25 +0000

D_KEY: Зато чет захотелось прям понастольгировать и какую-нибудь кроссплатформенную шляпу запилить. Может что-то на тему iocp, io_uring и пр. (ну и kqueue тож сделать и потом на сдачу posixовый select/poll), но, в отличие от asio, например, накрутить там реактивные стримы или еще чего другого придумать, чтобы оправдать существование поделки :lol:

WinAPI и POSIX

D_KEY — Tue, 10 Dec 2024 16:27:20 +0000

D_KEY:

Цитата Qraizer @ 10.12.24, 13:36

D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.
...
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects

И что? Что я, как разработчик софта, тут изменю в своем коде выше? :) Он будет работать в большинстве случаев, когда мне будет нужно. В некоторых редких я сделаю что-то еще (Deleter добавить не проблема, сам знаешь).

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

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

Цитата Qraizer @ 10.12.24, 13:36

Те в натуре серьёзно думаешь, что однотипное API для разнородных объектов является преимуществом?

Они не разнородны в достаточном смысле для использующего их программиста :)

Цитата Qraizer @ 10.12.24, 13:36

Если ты считаешь WinAPI уродским, то интересно почему.

Зоопарк разнородных подходов (пример привел выше с handle), функции с миллионом параметров, монструозные структуры данных и т.д. и т.п.

Для одной компании и одной ОС - странно.

Цитата Qraizer @ 10.12.24, 13:36

Один из таких примеров – как раз отделение INVALID_HANDLE_VALUE от NULL в ряде применений ради обеспечения отсутствия утечек ресурсов и гарантий атомарности сложных операций во многозадачных средах.

Можешь подробнее рассказать? Это может быть интересным.

Цитата Qraizer @ 10.12.24, 13:36

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

По-моему, не пояснил. Плюс продолжаешь игнорировать, что он для огромного числа совершенно разных ОС.

Цитата Qraizer @ 10.12.24, 13:36

Я даже не могу элементарный контейнер из сокетов создать, потому что по факту сокеты полиморфны, а в API они тупо int.

Поясни, пожалуйста. Не понял.

Цитата Qraizer @ 10.12.24, 13:36

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

При чем тут вообще opensource? Есть и закрытые posix ОС :-?

Цитата Qraizer @ 10.12.24, 13:36

Скажем так: это не проблема API.

Это проблема наличия только одной "настоящей" реализации API.
Впрочем, это вообще не проблема.

Никто на winapi уже почти и не пишет.

WinAPI и POSIX

Majestio — Tue, 10 Dec 2024 14:47:51 +0000

Majestio: Qraizer, я позволю себе поддержать ДиКея :lol:
Ты просто пойми, что линупсы и их апдейты растут как грибы - и гораздо чаще твоей сраной венды апдейтяться! И самое главное, а ни не просто растут - а выставляют стабильные и LTS ветки. Когда твоя венда делала раз в пятилетку (максимум). Я понимаю твою "любовь" в виндам, но мир меняется. И не меняться с ним себе дороже.

WinAPI и POSIX

Qraizer — Tue, 10 Dec 2024 13:36:13 +0000

Qraizer: D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

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

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

Цитата D_KEY @ 09.12.24, 20:27

У них коммерческая задача - сохранить совместимость.

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

Добавлено 10.12.24, 13:49

Цитата D_KEY @ 09.12.24, 20:27

По поводу отсутствия читов и недокументированных особеностей почитай что пишут разработчики wine.

Скажем так: это не проблема API. Я в своём тесте чего-то там могу сломать любой его функционал, но это не значит, что функционал плохо спроектирован.

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 21:49:04 +0000

D_KEY:

struct unique_fd

{

explicit unique_fd(int fd = -1) noexcept

: fd_(fd)

{

}

unique_fd(const unique_fd &) = delete;

unique_fd& operator=(const unique_fd &) = delete;

unique_fd(unique_fd && other) noexcept

: fd_(other.release())

{

}

unique_ptr& operator=(unique_ptr&& other) noexcept

{

reset(other.release());

return *this;

}

~unique_fd()

{

reset(-1);

}

void reset(int fd) noexcept

{

if (fd_ != -1)

::close(fd_);

fd_ = fd;

}

[[nodiscard]] int release() noexcept

{

int res = fd_;

fd_ = -1;

return res;

}

int get() noexcept

{

return fd_;

}

private:

int fd_;

};

Вот еще упражнение, написать для winapi с той же степенью применимости для объектов разного рода (файлов, сокетов, pipe, ...).

P.S. код не проверял, сильно не пинайте. Идея, надеюсь, понятна.

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 21:02:23 +0000

D_KEY: Ну раз мы уже в холиварах, то наброшу.
WinAPI не способна даже определиться с тем, что является кривым HANDLE: INVALID_HANDLE_VALUE или NULL (или -1 для 16битных версий, впрочем об этом уже можно забыть). А это ведь базовая вещь, о чем тут вообще можно говорить? :D

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 20:27:53 +0000

D_KEY:

Цитата Qraizer @ 09.12.24, 19:39

D_KEY, а чем тебе Windы не разные ОСи?

Тем, что это версии одной ОС и производства одной компании. Не смотря на разные технологии и их развитие. Это суть не меняет. У них коммерческая задача - сохранить совместимость.

Добавлено 09.12.24, 20:34

Цитата Qraizer @ 09.12.24, 19:39

Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Так это одна компания, конечно, она будет бороться за совместимость. Кто будет обновлять ОС, если старые программы перестанут работать? :-?

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

Я тебя не понимаю, честно.
Вот живет одна компания, которая одна делает свою ОС. Конечно, она обеспечивает совместимость. Конечно, у нее будет более заточенное под ее применимость API.

Тут скорее нужно удивляться, почему winapi такое уродливое. Вон macos современный вообще вполне себе хорошо живет еще и с новым нормальным языком (swift), при этом сохраняя совместимость с их старым objective-С (который, кстати, совместим с Си). И там как-то симпатичнее все выглядит.
И сравни с winapi, на котором никто сейчас писать программу не станет, возьмет либы.

WinAPI и POSIX

Qraizer — Mon, 09 Dec 2024 19:39:11 +0000

Qraizer: D_KEY, а чем тебе Windы не разные ОСи? Притом, что родной API для NT линейки вообще ни разу не Win32, а т.н. Native API. Сравни возможности Win32s, упомянутый Majestio костыль для 16-битных Win3xx, Win32c сиречь отменённое обозначение Win32 для Win9x, настоящее Win32 для исходно 32-битных NT до WinXP включительно и нынешнее Win32 под современные Win7/8/10/11, включая редакции для 64-битных ОСей. (Одно время MS хотела, впрочем, отказаться от процедурного API в Win8, заставив всех перейти на объектный API из .NET, но слава богу передумала пересаживать разработчиков исключительно в универсальные приложения, так что классические до сих пор в ходу и ещё долго будут в ходу.) Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Добавлено 09.12.24, 19:47

Цитата Majestio @ 09.12.24, 15:04

А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ

Та не. Win32s (s означает subset, кажется) не планировалась, но в итоге была выпущена для облегчения миграции разработчиков под ...хм, правильные 32-битные ОСи. И это неплохо получилось, я на Win3.1 + Win32s сидел аж до 98-го года, пока не вышла Win98SE, и у меня всё мне нужное работало. Игры под DirectX не работали, да, но тогда это не имело значения, аппаратный рендер был ещё в диковинку. Имеет ли это какое-то отношение к разрыву сотрудничества, ну... честно не знаю, но сомневаюсь.

Добавлено 09.12.24, 19:56
P.S. Решил погуглить и нашёл вот такую статью. Похожа на объективную. Краткое резюме: IBM захотела занять нишу системного ПО для своих же ПК, вытеснив т.с. с рынка Microsoft, последняя решила побороться и выиграла.

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

Цитата Majestio @ 09.12.24, 15:17

Просто пройди тест сертификации!

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

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 15:38:39 +0000

D_KEY: В общем, winapi можно сравнивать с конкретным API конкретной ОС. Например, macos (которая тож posix, если что). Сравнивать же непосредственно с posix можно будет тогда, когда winapi будет использоваться разными ОС от разных производителей.
:-?

WinAPI и POSIX

Majestio — Mon, 09 Dec 2024 15:37:09 +0000

Majestio: Ну я не буду Джордано Бруно, и не открою вам секреты мироздания, но кернель спейс и юзер спейс - это всего лишь абстракции. У каждной оси есть свои, скажем так, "области ответственности" для кернеля и юзерспейса. И не для никого не секрет, что если в юзерспейсе что-то запрещено, то мы пишем дрова, и оно, волшебным образом становится/может становиться разрешено. Вывод - везде можно сделать всё!

Но как говорили многие ораторы в этой теме - важно "договориться". Для кросс-платформеров вопрос возможностей уже. Для видовс-фагов он почти 100% в своей области. Но нет ничего абсолютно нерешаемого. Цитирую DKE_Y:

Цитата D_KEY @ 09.12.24, 15:11

Ну так библиотеки (хорошие) ты просто используешь, не задумываясь об ОС. Тот же asio тому пример.

Или, например, libevent.

Другой вопрос кросс-соместимости по всем 100% возможностей разных осей :-? А кто сказал, что вы в сказку попали?

WinAPI и POSIX

Majestio — Mon, 09 Dec 2024 15:17:11 +0000

Majestio: Qraizer, конечно шютка :lol: но у тебя есть возможность стать POSIX-совместимым модератором исходников. Просто пройди тест сертификации! :lol:

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 15:11:38 +0000

D_KEY:

Цитата Qraizer @ 09.12.24, 14:36

тогда как реализации POSIX делают вид, что они совместимы с POSIX, а по факту нет

Ну так они и не сертифицированы :) linux официально не posix (не сертифицирован), хотя по факту большинство важные вещей использовать можно.

Добавлено 09.12.24, 15:15

Цитата Qraizer @ 09.12.24, 14:36

Мне чтобы написать полностью переносимое POSIX-приложение придётся опуститься до уровня его API образца эдак 199x-ых и лишиться всего его 30 летнего последующего развития.

Верно. Но никакой альтернативы не существует. С чем ты сравниваешь? winapi-то вообще не переносимо :)

Цитата Qraizer @ 09.12.24, 14:36

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

Да. Я сам описал выше кейс с epoll/io_uring/kqueue/etc. vs select/poll.
Но вопрос тот же. С чем ты сравниваешь?

Цитата Qraizer @ 09.12.24, 14:36

Да-да, есть библиотеки, которые вроде бы должны это брать на себя. Вот только это самое «бы». Ад просто сменил место дислокации и теперь не в POSIX, а в этих библиотеках, потом что у них точно такая же трабля.

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

WinAPI и POSIX

Majestio — Mon, 09 Dec 2024 15:10:26 +0000

Majestio: Qraizer, сорян, туплю!
Ты вообще о чем? Приведи плс примеры, которые мы вместе с тобой сперва будем гнобить, а потом попробуем порешать. А пока это только твой взрыв негодований.
Давай по полкам? В плане действий - ты делаешь "я сделал всё по доке посикса, а оно-говно не работает". Мы вместе все смотрим. Oke?

WinAPI и POSIX

D_KEY — Mon, 09 Dec 2024 15:06:32 +0000

D_KEY:

Цитата Qraizer @ 03.12.24, 18:36

P.S. Я тем не менее с удовольствием посмотрел бы на транслятор сигналов POSIX в C++EH хотя бы краем глаза.

Разные реализации JVM делают подобное для java. Можно там поглядеть.

Я как-то делал костыли тоже сто лет назад, но код не найду уже :)

WinAPI и POSIX

Majestio — Mon, 09 Dec 2024 15:04:19 +0000

Majestio:

Цитата Qraizer @ 09.12.24, 14:36

Что до Win32 API, так он и разрабатывался по заказу самой IBM для использования в её OS/2, которая по итогу должна была выйти как OS/2 NT или как-то так.

Нет. Ну я "со свечкой не стоял". Но там был разрыв ни "до" и не "после". А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ :lol: Впереди маячило лютое бабло.

Опять же, я рядом не стоял. Но ты сам прикинь - IBM с кучей баблищя, рядом толковые недооцененные Мелкомягкие. Они щито, по-твоему, могли чисто по-братски разойтись краями? :lool:

WinAPI и POSIX

Qraizer — Mon, 09 Dec 2024 14:56:30 +0000

Qraizer: Majestio, было бы желание, это решаемо, и весьма недорого. Но ведь желания-то как раз и нет. Та ёлки ж:

Цитата dup(2) — Linux manual page

The error returned by dup2() is different from that returned by fcntl(..., F_DUPFD, ...) when newfd is out of range. On some systems, dup2() also sometimes returns EINVAL like F_DUPFD.

Их за ногу — серьёзно??! Вот это вот Стандарт на API? В котором функция может вести себя по-разному по желанию левой пятки очередного форкера? Когда две функции, выполняющие априори одинаковое действие, работают по-разному?!
Не надо защищать очевидное фуфло. И пожалуйста, не называйте POSIX экосистемой. Зоопарк экосистем – согласен.

WinAPI и POSIX

Majestio — Mon, 09 Dec 2024 14:49:06 +0000

Majestio:

Цитата Qraizer @ 09.12.24, 14:36

Это не проблема, что API ОСей отличаются.

Дружище - тут ты в корне не прав! :lol: Это ОСНОВНАЯ и "КОРНЕВАЯ" ПРОБЛЕММА. Разные оси "проповедуют" разное. А что разное? Разное много: определение процессов и потоков на уровне ядра, определение понятия ресурсов и его захватов, определение "железа" и его отображения во внутренние сущности, да много чего из. Это большая проблема! Многие ОСи не просто "разговаривают" на разных языках, они часто разговаривают "разными способами". В этом плане я как-то где-то даже поддерживаю macomics в его презентации HAL, как способа унификации. Но, увы, тут HAL+1 будет на порядок-два сложнее. Не аргументирую, чисто чуйка. Но это, думаю, лучший варик компромиссов кросс-разработок. Но туман тут, к гадалке не ходи!

WinAPI и POSIX

Qraizer — Mon, 09 Dec 2024 14:36:06 +0000

Qraizer:

Цитата D_KEY @ 08.12.24, 12:07

POSIX - это попытка описать API, который бы подходил для очень разных ОС. И на практике так и есть. Но иногда это действительно проблема.

Та нет же. Это не проблема, что API ОСей отличаются. Вон, есть же Стандарт языка и есть агромадная куча несовместимых друг с другом его реализаций. Проблема-то в том, что несовместимые реализации Стандарта языка совместимы однако с самим Стандартом, тогда как реализации POSIX делают вид, что они совместимы с POSIX, а по факту нет. Мне чтобы написать полностью переносимое POSIX-приложение придётся опуститься до уровня его API образца эдак 199x-ых и лишиться всего его 30 летнего последующего развития. А чтобы воспользоваться этим развитием, оно же вкусное как-никак, я обязан буду сосредотачиваться на его частных реализациях и с головой окунуться в ад портабельности и саппорта. Да-да, есть библиотеки, которые вроде бы должны это брать на себя. Вот только это самое «бы». Ад просто сменил место дислокации и теперь не в POSIX, а в этих библиотеках, потом что у них точно такая же трабля.

Добавлено 09.12.24, 14:45

Цитата Majestio @ 09.12.24, 12:15

"Заинтересованная" компания IBM разосралась с тогдашним партнёром Microsoft Co., и как итог - проект издох. И потом получилось то, что сейчас радует Qraizer'а.

Ну, "разосралась" тут неуместно. У них кончился 10-летний контракт, и не стали перезаключать. Если там и были тёрки, послужившие причиной, то вряд ли их можно описать таким эпитетом. Что до Win32 API, так он и разрабатывался по заказу самой IBM для использования в её OS/2, которая по итогу должна была выйти как OS/2 NT или как-то так. Просто посмотрев на маркетинговые успехи MS и сравнив их со своими, IBM решила воспользоваться услугами профессионалов для продвижения своей ОСи. В частности снабдив MS своими консультантами по созданию качественных 32-битных ОСей. Ну и т.к. контракт истёк до финала, разработку MS бросать в мусорник не хотела, то просто выкупила права и переобозвала как Windows NT.