M>>Это прекрасно в теории. На практике за overload +/- во многих местах бьют канделябром по рукам, и правильно делают. А иногда не бьют, и тоже правильно делают
М>хорошо, не надо overload. пускай будут функции типа delta(temperature1, temperature2). таки если temperature1 и temperature2 это разные типы -- то delta все равно будет вычислена правильно. ну или мы получим ошибку компиляции. на выбор. а вот если температура хранится как int, то мы тоже получим ошибку. но уже в вычислениях.
А, ну с этим я вроде нигде и не спорю
М>хорошо, давайте поговорим о вашей задаче:
Не надо про мою задачу
Пока что с ней никто, от слова вообще, не справился
М>я не знаток си++, но вы же не требовали си++, так? возьмем питон с его утиной типизацией. все работает просто великолепно. легко создать тип (в случае питона — класс или функцию) "отправлен" и "не отправлен". и все. остается только связать его с заказом. пускай заказ у нас это A. пускай A.status это статус заказа. в момент отправки A.status меняет тип и потому где бы ни располагалась операция изменения суммы -- она неизбежно обломается с попыткой уменьшения суммы после отправки. при этом транслятор не будет возвращать ошибку. ошибка возвратиться в рантайтме с описанием на человеческом языке (если это необходимо).
Охохонюшки. Опять только один статус и только одна проверка
У нас в рантайме все хорошо и без типов и трансляторов
И да, у нас можно изменять сумму после отправки
И условий, при которых нельзя — с десяток. Создавать десяток классов?
M>> потому что под капотом b делает full database lock, а c поднимает в память четыре терабайта данных
М>я уже писал, но напишу еще. си (си++) ужасно противный язык. нет никакого способа (исключая грязные хаки) узнать сколько у нас осталось стека. и мы не знаем накладные расходы на создание кадрового фрейма. они очень сильно зависят от компилятора и ключей компиляции. в результате рекурсия это очень и очень плохо.
Я про рекурсию даже не упоминал
М>вопрос: может ли уронить сервер код (2*2)? пускай этот код вообще в другом процессе. ответ — в конфигурации по умолчанию в win server/workstation очень даже может и порой роняет. почему роняет -- это уже другой вопрос ответ на который требует знания потрохов винды. умеючи можно изменить конфигурацию (штатными средствами) так, чтобы не ронял. но оно не так часто происходит, чтобы это было актуально.
Вооот. А у нас ситуация «люди запустили отчет за последний год и система начала терять производитльность вплоть до падения ноды» одно время происходило раз в месяц
Оказался один отчет на одной странице, на которой не стояло «if DateRange > 1 месяца», не разрешать :D И это не решается никаким типизациями, а только волшебными пенделями программистам
Offtop:
Эта багофича имела вообще другое начало, которое было еще прекраснее.
У нас в качестве основной базы данных используется (в плане abuse, а не use)
mnesia, в которой по дизайну базы таблица не может содержать больше 2GB объектов. Как только таблица переваливает за 2 GB, ее нужно разбивать на части.
И есть у нас архивные заказы. Текущая таблица архивных заказов висит в памяти, остальные (кусками по 2 GB) — на диске. И вот кто-то приходит и требует отчет по заказам.
Я когда впервые увидел код, который это реализует, я ржал, наверное, полчаса.
Псевдокод:
orderIds = order_table.get_all_ids()
foreach(table in archived_order_tables):
ids = table.get_all_ids()
orderIds.append(ids)
sort(orderIds)
filter(OrderIds, определенное_условие)
и так — на каждый отчет (даже не годовые). На тот момент было 32 архивные таблицы, то есть на каждый отчет 64 гига поднимались в память, из них считывалось в память несколько миллионов записей, потом в памяти же они сортировались и фильтровались. А мы удивлялись, какого хрена постоянно mnesia нагруженная и один из процессов веб-сервера стабильно около 300 гигов в памяти занимает
И да, этот код был написан одним из гуру Эрланга, к тому же
И да, тут ничего не спасет, только живительная эвтаназия.
