Кто реально угрожает C++ (нет, Rust, не ты)

Мало кто толком понимает, как работает эта кухня, поэтому большинство лишь применяет то, что сделано "продвинутыми программистами"

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

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

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

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

Допустим, у вас 10KLOC и вы в состоянии оценить качество кода для семейства x86 процессоров. А если добавить сюда еще и пару-тройку ARM-ов? А если еще и e2k? А если еще что-нибудь?

А для проекта в 100KLOC вы в состоянии глобальное качество отслеживать?
А для проекта в 500KLOC?
А для проекта в 1MLOC?
И т.д.?

Может для проекта хотя бы в 100KLOC будет уже свой набор требований, в которых требования к производительности уже не будут приоритетом №1 (а если и будут, то не ко всему коду, а к отдельным его кускам)? Например, там будут иметь значения такие вещи, как обеспечение корректности, повторное использование и отсутствие копипасты с ее проблемами. Как раз те вещи, для обеспечения которых шаблоны (включая многоэтажные) хорошо себя зарекомендовали.

Кто реально угрожает C++ (нет, Rust, не ты)

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

Посмотрите эту ветку обсуждения: https://habr.com/ru/articles/811151/comments/#comment_26776101
Я там основную претензию высказал -- когда начинается декларация типов в Python, исходная динамическая типизация прощается с нами.

А хотелось бы перенести проверки на этап компиляции.

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

Кто реально угрожает C++ (нет, Rust, не ты)

Почему же?

По факту.

Без декларации типов не заработает.

Кто реально угрожает C++ (нет, Rust, не ты)

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

Вот только динамическая типизация, о которой речь шла выше, где-то по дороге закончилась.

Кто реально угрожает C++ (нет, Rust, не ты)

И, честно говоря, не совсем понимаю вашу позицию - вы что пытаетесь доказать?

Я пытаюсь доказать, что когда вы сравниваете RPG с C++ в своих задачах, то вы напрасно акцентируетесь на C++. Т.к. на место C++ в этом сравнении можно подставить хоть Java, хоть C#, хоть Kotlin, хоть Scala. Ничего не поменяется.

И кому?

Вам.

Кто реально угрожает C++ (нет, Rust, не ты)

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

Да я вам уже устал повторять: на вашей платформе RPG для ваших задач рвет чуть ли не всех. Но вы упорно говорите про то, что именно C++ не лучший выбор. Хотя вместо C++ можно подставить любой современный мейнстримный язык.

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

Если и сейчас до вас не дойдет...

Кто реально угрожает C++ (нет, Rust, не ты)

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

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

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

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

Ваше восхваление 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++ (нет, Rust, не ты)

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

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

Э...

В статически-типизированном языке 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 не попадают в разрешенный диапазон.

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

Кто реально угрожает C++ (нет, Rust, не ты)

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

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

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

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

Вы все еще пишете многопоточку на 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

Вы все еще пишете многопоточку на C++ с ошибками синхронизации?

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

Вы все еще пишете многопоточку на C++ с ошибками синхронизации?

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

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

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

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

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

Вы все еще пишете многопоточку на C++ с ошибками синхронизации?

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

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

Вы все еще пишете многопоточку на C++ с ошибками синхронизации?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы все еще пишете многопоточку на C++ с ошибками синхронизации?

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

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

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

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