P>шутник

P>>>и при этом, внутри, возюканья в любом случае меньше. допустим подходят только старше 20 — не вопрос, просто проверка на >20, проверку на верхнюю границу делать не надо

P>это был пример, зачем лезть в бутылку?

P>если у функции могут быть дополнительные требования к возрасту, если это требование нужно один раз — можно проверять внутри

E>>В С/С++ принято давать понятные имена параметрам функций, как и самим функциям

money getEstimaedSalary(int age)

P>ох ты какой чёткий, даже возвращаемому параметру имя дал

P>или это таки тип?

typedef double money;

P>какой хочешь — хочешь целое, хочешь Age

P>>шутник

E>Я вообще плохо понимаю, как ты собираешься выбрать адекватные границы для "возраста вообще"? А для какой-то конкретной ситуации?

assert( IsValidAge( age ) );

E>А то я вижу такой сценарий, что мы в какой-то функции посмотрели, что возраст гарантирует, что он до 100 ну и заложились на этот факт, а ассерт не написали. Потом кто-то где-то найдёт, что возраст бывает и 123, ну подправит класс Age. Думаешь он проверит, что там у нас в функции написано, или, хотя бы, потестирует её?

P>>если у функции могут быть дополнительные требования к возрасту, если это требование нужно один раз — можно проверять внутри

E>>>В С/С++ принято давать понятные имена параметрам функций, как и самим функциям

money getEstimaedSalary(int age)

P>>ох ты какой чёткий, даже возвращаемому параметру имя дал

P>>или это таки тип?

typedef double money;

P>>какой хочешь — хочешь целое, хочешь Age

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

E>>>А то я вижу такой сценарий, что мы в какой-то функции посмотрели, что возраст гарантирует, что он до 100 ну и заложились на этот факт, а ассерт не написали. Потом кто-то где-то найдёт, что возраст бывает и 123, ну подправит класс Age. Думаешь он проверит, что там у нас в функции написано, или, хотя бы, потестирует её?

E>Я не знаю, что он делает. Его же ты придумал

В С, как и в "С++ для не слишком умных" можно просто написать
int IsValidAge( int );
и потом писать везде на входе в функции
assert( IsValidAge( age ) );

P>>а лучше нормальный класс

E>Потому, что это дорого, сложно и чревато другими ошибками...

P>>код чего? класса с инвариантами?

E>Это совпадение или какой-то математический факт? Если первое, то напишу все 20 независимо, если второе -- то введу функцию, проверки этого факта. Но тоже не всегда. Скажем > 0 буду писать везде независимо...

E>И надо во всех посмотреть и решить, что тут вот надо, а тут вот не надо, а тут надо, но другое условие...

E>Так задача же не ясна. В некоторых может и бывает валидный и невалидный возраст...

вот например, параметром функции является возраст, в случае с С, в каждой функции принимающей возраст нужно делать проверку. В случае C++ будет просто класс Age, и внутри функции не о чём не нужно парится. (можно даже использовать различные трюки, чтобы ловить конструкцию Age с неправильным возрастом compile time, но не об этом речь). И как тут поможет статический анализатор кода??

P>>в смысле тип результата, или чего? я не телепат

Age + int
Age + int // если это не то же, что и выше

ох как ты вертишься, как уж на сковородке.[-q]Конкретика какая-нибудь будет?

P>да, математический факт — у 20 функций одинаковые условия.
Пример мат. факта -- три числа могут быть сторонами прямоугольного треугольника. А если у меня в программе 100500 функций и аргумент 20 из них не должен превышать 65, то это случайное совпадение просто...

P>ога. как ещё оправдаешь копипасту?
За копи-пасту -- штраф. Писать всегда надо с чистого листа.

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

P>у меня в голове было конкретное Т.З. на проект, где этот тип будет применяться, со всеми требованиями?
Я тебя вообще плохо понимаю. Я так подозреваю, что класс Age какой-то простой довольно, может ты его приведёшь, хотя бы на псевдокоде?

P>А главное, как тебе тут поможет статический анализатор кода???
Он поможет от другого. От того, что передают бинарно несовместимые данные.

P>брееед
Что конкретно бред? То, что взятую с потолка верхнюю границу возраста придётся пододвинуть?

P>ога, как ты там говоришь, поменяем ограничение? сегодня это число центов, завтра сотые доли центов. И что, менять весь код?

Нет, одну константу...

P>например:
P>Age + Age — недоступная операция, Age
а как быть с верхней границей?..
P>Age + int — недоступная операция, Age,
Это логично, если int -- разница возрастов, иначе не понятно
P>Age — Age — недоступная операция, AgeDiff, Age
чем AgeDiff отличается от int? Может ли Age быть отрицательным?
P>Age + age_diff — недоступная операция, Age
P>Age / Age — недоступная операция, floating point
P>Age * 0.5 — недоступная операция, Age

P>[q]
P>Age + int
P>Age + age_diff// если это не то же, что и выше

E>Вообще, если у тебя есть семейство функций, с одинаковыми условиями вызова, например семейство аллокаторов, то решать проблему того, что всем надо дать одни и те же параметры, надо архитектурно. Должен быть промежуточный слой, который гарантирует корректность вызова

class Age
{
    int age;
public:
    struct WrongAgeRange{};
    explicit Age(int x)
    {
        if( x>0 && x<200 )
            age=x;
        else
            throw WrongAgeRange();
    }
    int value()
    {
        return age;
    }
};

E>Нет, одну константу...