Как стать автором
Обновить
87
0.2
Евгений Охотников @eao197

Велосипедостроитель, программист-камикадзе

Отправить сообщение

А вот когда ввели шаблоны, то понеслась массовая истерия в стиле "долой макросы, до здравствуют шаблоны!", "если ты до сих пор используешь макросы, то ты не понимаешь C++". И все бы ничего, если б хватило ума и настойчивости приделать к тем шаблонам вменяемые средства управления.

Осталось определиться на что вы жалуетесь:

а) на накладные расходы, которые связанны с шаблонами (какие, кстати говоря?);
b) на отсутствие "средств управления" (какого, кстати говоря?)

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

И да. Мне привычнее было бы делать все на С/С++. И я пробовал это делать на С/С++.

Ну понятно. Именно C++ плох потому, что вы пришли из C++. Пришли бы из Java, то плохой по сравнению с RPG была бы Java. Но т.к. в вашем багаже Java (или C#) не было, то плох именно C++.

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

Можно примеры?

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

Такое впечатление, что уход тех, кто "просекал фишку" состоялся во времена добавления в C++ механизма исключений. А то и еще раньше, когда перегрузку операторов сделали.

Речь не о чувствах, а о том, чтобы картина была объективна.

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

Но, как я понимаю, было не совсем так. На этой платформе уже был инструмент, который заруливал и C++, и Java, и C#. Было бы странно отказываться от него. Но раз инструмент заточен и под платформу, и под задачу, то какой смысл все время противопоставлять его C++?

Вот кто-то бы начал сравнивать C++ с регулярными выражениями, уместно бы было такое сравнение?

Да, на C++ вы могли бы закатывать Солнце вручную выписывая что-то вроде:

auto exp = capture(repetition(2, 8, range('0', '9')));

вместо ([0-9]{2,8})

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

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

Тогда зачем продолжать полоскать C++?

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

Э...

В статически-типизированном языке C++ можно определить шаблон класса bounded_value, что-то типа:

template<typename T, T Lower_Bound, T Upper_Bound>
class bounded_value {...};

конструктор которого будет проверять, что переданное ему значение попадает в [Lower_Bound, Upper_Bound]. Что легко протестировать один раз.

После чего при тестировании функций вида

void do_something(bounded_value<char, -90, 90> a, bounded_value<char, 0, 90> b) {...}

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

В отличии от языков с динамической типизацией.

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

Замечательно. Осталось понять при чем здесь C++.

Ведь из ваших слов логичным образом вытекает, что в ваших условиях и на ваших задачах RPG будут сливать и Java (со Scala-ми и Kotlin-ами), и C# с F# впридачу, и другие высокоуровневые универсальные языки (ну, может быть, за исключением COBOL-а).

Но "на помоечку" (с) отправить нужно именно C++.

Почему вы так полагаете?

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

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

Он вам не на это указывает.

Вот пример для проверки вашего подхода:

#include <iostream>
#include <functional>

struct demo
{
    long long m_delta;

    template<typename T>
    auto apply(T v) const { return v + m_delta; }
};

template<typename T>
struct wrapper
{
    T m_value;

    void view(std::function<void(const T&)> fn) const {
        fn(m_value);
    }

    template<typename R>
    R view(std::function<R(const T&)> fn) const {
        return fn(m_value);
    }
};

template<typename T>
void accept_and_show(const char * case_name, T && v)
{
    std::cout << "=== " << case_name << " ===" << std::endl;
    std::cout << "T: " << typeid(T).name() << std::endl;
    std::cout << v << std::endl;
    std::cout << "===" << std::endl;
}

int main() {
    wrapper<demo> w{ demo{13} };

    long l{ 55 };
    accept_and_show("l+delta",
        w.view([l](const auto & delta) { return delta.apply(l); }));

    char c{ 33 };
    accept_and_show("c+delta",
        w.view([c](const auto & delta) { return delta.apply(c); }));
}

Можно обратить внимание на то, что demo::apply возвращает auto.

Попробуйте сделать так, чтобы этот код скопилировался. И не был захардкожен на текущую реализацию demo (чтобы было понятнее: код должен компилироваться даже если тип demo::m_delta будет заменен на какой-то другой (вроде short, float, double или даже любой другой пользовательский тип с поддержкой operator+).

У меня, например, получилось вот так: https://wandbox.org/permlink/WumQM0PTODKQKRwL

В тоже время: https://wandbox.org/permlink/ev55r0kfjP0R1fzI

Полагаю, вы просто не поняли о чем вам сказали.

совсем другое когда сразу начинают писать про "поносные лучи" :) диалог получается из этой же серии

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

За обилие смайлов в ответных комментариях еще одна порция оных.

Да, пожалуйста. Все верно так и проходил.

Еще одно доказательство для тех, кто сомневается в адекватности подобной системы отбора.

Как я уже написал выше, класс SharedState полностью работоспособный

Ну да, ну да. А вот здесь ув.тов@Kelbonn вовсе не косяк в вашей реализации нашел.

Так это зависит от субъективной оценки - в моем понимании кликабельный, в вашем кликбейт.
Опять же ваша субъективная оценка.

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

Дело не в том слышал

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

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

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

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

Интересно, интересно. Вот этот поворот!
Может мне еще нужно и денежку куда-то занести, за то, что вы здесь статью опубликовали и снизошли до того, чтобы донести до темных и лапотников результаты своих изысканий?

А то ведь пока не компенсирую вам ваши затраты, у меня нет никаких прав на критику.

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

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

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

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

PS. Если позволите, нескромный вопрос: а в Kaspersky Lab вы попали обычным образом -- через серию собеседований, включая знание языка, алгоритмическую секцию и т.д.?

Вот я о чем спрашиваю.

Скажите, а когда вы читаете документацию к std::lock_guard, вы тоже задаетесь вопросом: а там действительно нужно делать именно так?

Т.е. вот такой вариант синхронизации - это уже крайний случай.

"Отучаемся говорить за всех" (c)

А вокруг выдернутого из контекста куска кода можно рассуждать только абстрактно.

Да блииииин! Ну нет в этой статье ничего абстрактного или выдернутого из контекста. Здесь все предельно понятно: если у вас в одном объекте два мутекса и N полей, для К из которых нужно захватывать первый мутекс, а для остальных M полей -- второй мутекс, то высока вероятность ошибиться. Например, захватить первый мутекс и модифицировать поле, защищенное вторым мутексом. Чтобы исключить подобные ошибки как класс, предлагается отдать первые K полей в одну структуру, а вторые M полей -- во вторую. Каждая структура будет защищена своим мутексом. Но не просто так, а инкапсулирована вместе с мутексом в отдельный объект. И доступ к содержимому только через специальный метод(ы) с коллбэком. Внутри коллбэка доступ к данным есть. Вне -- нет.

Все!

Это же очевидно как не знаю что.

Какой здесь еще кому-то контекст потребовался... Ну вот, честно, ХЗ.

Да, да, и офтопик с MVCC из СУБД тоже я, как и часовню.

Вы ведете себя как ребенок, поэтому и обращаться с вами приходится как с ребенком.

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

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

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

Вам интересно и что? Почему на вас кто-то должен тратить свое время?

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

Чем минусы ставить - читать стоит сначала.

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

Там было сказано - обычно не имеет. Имелось в виду тех самых задачах concurrent computing и blocking I/O.

Только вот это "обычно не имеет" было сказано задолго до того, как вы про blocking I/O упомянули.

Вообще не очевидно.

Даже если просто читать внимательно, то уже очевидно. А если еще и хоть слегка в теме, то и подавно.

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

Multithreading -- это всего лишь инструмент для использования в двух принципиально разных областях:

  • parallel computing (яркий пример -- OpenMP), выигрыш от multithreading в том, что все в рамках одного адресного пространства без необходимости использования каких-либо средств IPC;

  • concurrent computing (яркий пример -- упомянутые вами blocking I/O). Опять же удобно то, что все в рамках одного адресного пространства.

И если в случае concurrent computing вопрос производительности дискуссионный и может быть даже принесен в жертву простоте/надежности реализации, то в случае parallel computing все гораздо очевиднее (опять же отсылка к OpenMP, а так же к инструментам вроде task-flow и HPX).

И заявлять о том, что multi-threading не имеет отношения к производительности даже не уточнив о какой именно области идет речь -- это "мощно, внушаить!" (c)

PS. Очевидно, что @SpiderEkb в своих комментариях выше говорил о parallel computing. При этом ему везло оказываться в ситуациях, когда расходы на IPC по сравнению с основной обработкой данных в его задачах были настолько малы, что ими можно было пренебречь.

Зачем для организации динамически расширяющихся тредпулов вообще нужны мутексы? Чушь какая-то...

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

Так "не обойтись" или "чушь какая-то"

Вы уж определитесь.

И речь шла не про очереди заявок для thread-pool-а.

Потому что в статье описан подход, который применим только к прикладной разработке

Ошибаетесь. Вам тут уже привели пример вашей же MDBX, в которой около 200 применений мутексов.

При чем тут принципы БД офтопик?

Подумайте.

С какой стати они вообще офтопик, если там все очень плотно на конкуретном доступе и реализовано?

Потому что там конкурентность для решения задач СУБД. Если создается, скажем, видеоредактор или прокси-сервер, то конкурентность и там потребуется, но вряд ли она будет такая же, как в случае с СУБД.

Что мутексы это круто и они очень хорошие и они всегда нужны?

Нет.

Ок, эту мысль зафиксировали.

Вы зафиксировали совсем не то.

Информация

В рейтинге
2 159-й
Откуда
Гомель, Гомельская обл., Беларусь
Зарегистрирован
Активность