Є кілька причин на те. Наприклад зміни які потрібно зробити не несуть користі чи навіть будуть шкідливими користувачам open source рішення
Доброго дня Спільното,
Підбираю команду волонтерів на проєкт для ЗСУ:
— Андроід девелопер із досвідом використання NDK
— С++ девелопер під Linux
Проєкт — це мобільний додаток із простим інтерфейсом і бекендом для обробки даних у реальному часі. Є опен-соурс рішення але воно по якості і надійності не підходить для виконання завдань.
На себе беру С++, але там роботи вистачить і на двох
По моїх оцінках при повній зайнятості проєкт зайняв би 2 місяці. Та враховуючи що це волонтерський проєкт, календарно це може сягнути і до 6 місяців.
Від учасників проєкту очікується комітмент
Мої контакти
tel/whatsapp О93-О47-5І-83
emal: [email protected]
котів/вітру/снігу/листя
А ще є мухи та павуки. Любу камеру перелякають як на об’єктив сядуть
Я без пітону, просто на плюсах, за 20 хв все зробив. А генерувати код хоч на пітоні хоч чим іншим — як тільки доходиш до коваріантності усе зразу стає страшенно складно.
Просто проблема множинної диспетчиризації значно глибша ніж видається з першого погляду
Та то не ліньки. Ви просто заявили більше ніж можете подужати і тепер задкуєте.
То згенеруйте
То не код а текст. Він не компілюється, і не вирішує задачу 25 класів 40 методів
Що небудь аби не пусто. В [2] використали просте додавання, у мене в прикладі теж додавання, але воно мабуть зоптимізувалось в простий return
Код покажіть
1) Нема умов прикладу
Ще раз умови: 25 класів і 40 методів визначених тут godbolt.org/z/4n1xd8
2) Мені не платять за цей код
Якщо це так просто то ви б витратили на це менше часу ніж на диспути. Я свій приклад зробив за 20 хв.
Бо ви не заплатили.
Не можете написати, то так і скажіть, навіщо оці дитячі відмазки?
Допишіть в верхньому рядку назви ще 37 фігур, і автоматом буде створена матриця для 40.
Класів 25, а методів не 625 а лише 40. Різницю бачите?
А давайте статтю напишемо?
Покажемо, що мій метод швидший та простіший за наведені в літературі...
То покажіть же ж нарешті.
Можна буде до таблиці звести учі відомі рішення, їх ціну та швидкість.
Таблиця із зведеними порівняннями є в [2]. Чомусь там такий простий метод як ваш обійшли увагою.
Впаде, побачать, і виправлять.
На деяких проєктах «впаде» звучить буквально і занадто загрозливо.
З таблицею можна диспетчитись будь-яким методом, не лише за суперкласом.
То де ж ваш код?
Мій ось godbolt.org/z/1caGTs
У цьому прикладі чотири namespace:
given — те що дано в godbolt.org/z/4n1xd8
multimethods — шаблони для мультиметодів із цієї статті
solution — рішення завдання
test — тестування рішення.
Все працює. Покажіть тепер ваше матричне рішення для цього прикладу
Наприклад, трикутник може не буть субкласом полігону в наслідуванні, але для перетину з колом його має сенс розглядати як полігон. Тому, табличний иетод більш гнучкий.
Який результат ви очікуєте якщо передасте трикутник у функцію що очікує на вході полігон і при цьому трикутник не є субкласом полігону?
Поясніть, чому у Вас від 1 до 5 по 4 метода, а далі — по одному?
Так дано. Можна задати по іншому. Головне щоб покривались основні кейзи — субклас+субклас, субклас+суперклас, суперклас+субклас, суперклас+суперклас.
Руками поставити в потрібні місця.
То чого ж ви ще не поставили руцями?
У Вас не руками?
У мене копіпастою.
І усі випадки симетричні?
Ні, не всі випадки симетричні.
Ще раз перепитаю: як в результаті виглядають класи фігур (базовий та похідні) і які дописи в них з’явились для підтримки диспатчу?
Ось такі:
static constexpr auto classid = N; virtual bool instance_of(const multimethods::class_info& expected) const;
Заради чого? В мене код простіший.
У вас код простіший для трьох класів. А для 25 та 40 функцій його не має.
Коли хтось викливає AddSquareAndTriangle(), надаючи кола як аргументи — його проблема.
На проєктах обсягом більше
З котрої це пори в С++ безпека важливіша за швидкість? Може, ще при доступі до елементів вектору варто перевіряти його розмір?
type safity важлива. З котрої пори не пригадаю. Мабуть із початку самих плюсів. Загляньте наприклад в JSF AV rules, чи ISO CPP Core Guidelines.
По-перше, усі ці функції треба ще напсати. 25*25 функцій. І таблиця буде незрівняно меншим об’ємом роботи.
Наявність 625 функцій зовсім не обов’язкова. Багато випадків можуть покриватись коваріантими типами параметрів. Тобто діспетчитись по супертипу.
В [2] розлядають випадок із 40 функцій. Я тут викладав свій код для цього кейсу (щось не можу його знайти, мабуть його поховали). Якщо ви кажете що заповнити матрицю просто, ось вам лінк на 25 класів і 40 визначених на них функції. godbolt.org/z/4n1xd8 . Заповніть вашу матрицю і проілюструйте нам простоту цього процесу
По-друге, в таблиці одну функцію можна використовувати для різних операцій.
Можна і треба. Покажіть тільки як.
По-третє, геть не загажені самі класи фігур, себто
Рішення з цієї статті підтримує обидва способи — хоч методами хоч функціями. А матрицю методами не заповниш, бо різнотипні.
Вчетверте, таблиця швидше працює)
Тут заперечувати не буду. У мене вийшло 545 інструкцій на диспетч. Ви мабуть і в 50 вкладетесь. Питання в тому чи аплікація може дозволити ці 500 циклів чи ні.
Так, це я зробив шаблони Class та addi щоб не писати купу класів та методів для тестування продуктивності. Вони майже нічим не відрізняються від тих що у статті.
msvcc не ставив за мету. компілюю з gcc та clang, опції -std=c++17 -pedantic, -Wall
Ось код:
template<unsigned N> class Class : public Class<N/5> { public: static constexpr auto classid = multimethods::class_hash<Class>(); virtual ~Class() {} protected: using base = Class<N/5>; virtual bool instance_of(const class_info& expected) const noexcept { return classinfo(*this) == expected or base::instance_of(expected); } }; template<> class Class<0> { public: static constexpr auto classid = multimethods::class_hash<Class>(); template<class Expected> bool instanceof() const noexcept { return instance_of(classinfo<Expected>()); } virtual ~Class() {} protected: virtual bool instance_of(const class_info& expected) const noexcept { return classinfo(*this) == expected; } }; using Base = Class<0>; size_t add(const Base& a, const Base& b); template<class A, class B> size_t addi(const A& a, const B& b) { DTRACE(); return a.classid + b.classid; }
Для ієрархії 20->4->1 класів визначено 40 функцій:
size_t add(const Base& a, const Base&b) { return multimethod<size_t, addi<Class<24>,Class< 6>>, addi<Class<24>,Class< 5>>, addi<Class<24>,Class< 4>>, addi<Class<22>,Class<22>>, addi<Class<22>,Class< 3>>, addi<Class<22>,Class< 2>>, addi<Class<20>,Class<22>>, addi<Class<20>,Class<12>>, addi<Class<21>,Class<15>>, addi<Class<21>,Class<14>>, addi<Class<20>,Class<13>>, addi<Class<20>,Class<12>>, addi<Class<19>,Class<16>>, addi<Class<18>,Class<15>>, addi<Class<18>,Class<14>>, addi<Class<17>,Class<13>>, addi<Class<17>,Class<12>>, addi<Class<16>,Class<11>>, addi<Class<16>,Class<10>>, addi<Class<15>,Class<15>>, addi<Class<14>,Class<14>>, addi<Class<14>,Class<13>>, addi<Class<13>,Class<13>>, addi<Class<12>,Class<12>>, addi<Class<11>,Class<11>>, addi<Class<10>,Class< 4>>, addi<Class< 9>,Class< 3>>, addi<Class< 9>,Class< 3>>, addi<Class< 8>,Class< 2>>, addi<Class< 8>,Class< 2>>, addi<Class< 7>,Class<11>>, addi<Class< 7>,Class<12>>, addi<Class< 7>,Class<10>>, addi<Class< 6>,Class<16>>, addi<Class< 6>,Class< 6>>, addi<Class< 5>,Class<15>>, addi<Class< 5>,Class< 5>>, addi<Class< 5>,Class< 1>>, addi<Class< 4>,Class< 4>>, addi<Class< 4>,Class< 1>>, addi<Class< 3>,Class< 3>>, addi<Class< 2>,Class< 2>>, addi<Class< 1>,Class< 1>> >::dispatch(a, b); }При нагоді оновлю на гітхабі.
1,000,000 диспетчеризацій по таблиці із 40 функцій виконується за 55 сек. Тобто, в середньому, 55 мкс на один виклик. Як поміряти cycles per loop щоб порівняти з [2] поки що не знайшов. Це чесна динамічна диспетчиризація. Статична унеможливлена рознесенням функцій по різних одиницях компіляції.
gcc-8 з оптимізацією -O2 без RTTI генерує код у якому на рядок у таблиці виконується
Ні, ви не вірно зрозуміли. Список міститиме лише 40 визначених функцій.
ЗЫ: но для ерунды на 25 классов с кучей ерунды
Приклад із 20 класами — з [2].
я просто напишу генератор и мне будет уже всё равно 25 там классов или 200500 и добавление нового сведётся к рутине «делай раз делай два» равно как и все «правки по коду»
Як напишете, приносьте подивимось.
вот селяви который вы сами не смогли решить на уровне «доказуемых примеров»
Що до цитати — то вона про gcc а приклади компілюються із clang.
Усе що міг розказати публічно — виклав у топіку