Здравствуйте, Mamut, Вы писали:

M>Это прекрасно в теории. На практике за overload +/- во многих местах бьют канделябром по рукам, и правильно делают. А иногда не бьют, и тоже правильно делают
хорошо, не надо overload. пускай будут функции типа delta(temperature1, temperature2). таки если temperature1 и temperature2 это разные типы -- то delta все равно будет вычислена правильно. ну или мы получим ошибку компиляции. на выбор. а вот если температура хранится как int, то мы тоже получим ошибку. но уже в вычислениях.

и еще раз о строках. семантика "+" в отношении строк в том же паскале сильно отличается от семантики "+" в отношении int. но мы привыкли к этому и даже не замечаем. а питон может даже умножать строку на число. семантика понятна на интуитивном уровне и сильно упрощает код в определенных местах.


M> Так и со сложными +/-, которые прячут что-то под капотом. В результате строка a = b + c может спокойно положить сервер,
"что-то прячут под капотом" -- вы же сами говорите, что "А что? API-вызов всего лишь требует типа TDate". по вашему и API вызовов нужно воздержаться. разговор идет про возможность реализации логики на типах. +/- это чисто для примера. без них легко обойтись. речь про то, что если ожидается тип А, вместо которого передается тип Б, то операция преобразования это и есть логика на типах. если такая операция возможна вообще.

хорошо, давайте поговорим о вашей задаче:

# если заказ отправлен, нельзя увеличивать, можно уменьшать
у нас есть тип "отправлен" и "не отправлен". у типа "отправлен" метод "уменьшить сумму" пускай всегда возвращает ошибку. пускай даже ошибку + id строки с текстом объяснения почему нельзя.

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

M> потому что под капотом b делает full database lock, а c поднимает в память четыре терабайта данных
я уже писал, но напишу еще. си (си++) ужасно противный язык. нет никакого способа (исключая грязные хаки) узнать сколько у нас осталось стека. и мы не знаем накладные расходы на создание кадрового фрейма. они очень сильно зависят от компилятора и ключей компиляции. в результате рекурсия это очень и очень плохо.

вопрос: может ли уронить сервер код (2*2)? пускай этот код вообще в другом процессе. ответ — в конфигурации по умолчанию в win server/workstation очень даже может и порой роняет. почему роняет -- это уже другой вопрос ответ на который требует знания потрохов винды. умеючи можно изменить конфигурацию (штатными средствами) так, чтобы не ронял. но оно не так часто происходит, чтобы это было актуально.