Здравствуйте, Erop, Вы писали:
E>А компиляция в типичном цикле разработки -- это интимное дело прогера. Я бы понял ещё ошибки, которые выявляются на момент коммита, например, но чем так выделен момент компиляции-то?
ну я хз ещё как объяснить, сорри
P>>этот юнит тест будет проверять все места использования типа ?? E>Это предложение я тоже не понял. Ты пишешь библу. Ну, например, функцию qstable_sort, юнит-тестируешь её, потом она работает в твоём коде...
нет, вот у меня есть тип Age, который заботится о сохранении своего инварианта. написав его один раз — я уверен, что в него никогда не придёт никакая хрень — и все его пользователи имеют нормальное значение. как твои юниты тесты смогут дать хотя-бы близкую к этой гарантию??
P>>жесть E>Ну ты реально часто встречал такие вот классы Age? А для концепта "разница в возрасте" чего делали, например? А для "суммарный возраст работников нашего склада"? А для "средний возраст сотрудника" что делали и как вычисляли?
конкретно Age — нет, с erp и т.п. не сталкивался, и не очень хочу.
но подобная концепция используется
E>Что-то мне кажется, что ты стебёшься.
нет
E>Оставлю весь текст, так как не знаю, что там отрезать. Суть в том, что для того и есть юнит-тесты. E>В частности юнит-тест f должен будет вызвать эту функцию со всеми граничными значениями и возраста и уровня...
ну вызвал ты f, ну ок — ну поймал на том что границы разные, ну хорошо.
но вот стоит капельку усложнить пример: диапазоны совпадают, и что теперь??
P>>а в чём проблема? (при том, что в примере выше, код проверки range будет общим для age и level) E>Проблем много, вообще-то, я там повыше указал, несколько. E>Но я другой вопрос задал. ТЫ ВСТРЕЧАЛ ТАКОЕ в продакшине, а не в учебно-методических измышлениях?.. E>Я вот почти не встречал, например.
я встречал, не так часто, как хотелось бы. Но, ценность type-safety от этого ничуть не убавляется
вот тебе нужно на каждый чих писать unit-test, при type-safety всё вообще прозрачно и не требует внимания — бери и используй
P>>ога, добавляем разные именна в контекста для слежки чёткого пацана. А что? он же чёткий — всё запомнит, всё проверит. E>Обычно нормальные программисты пишут код осознанно... E>И потом запускают и проверяют, что оно работает...
ну я же говорю, чёткие поцоны.
E>>>Вообще есть такой подход, на входе в функцию -- проверка параметров, на выходе -- проверка результатов... E>>>Он намного эффективнее статических типов P>>orly? E>Это я тоже не понял.
чем он эффективней?
статический тип один раз пишется — и забыл. параметры на выходе и входе проверять нужно всегда
Здравствуйте, Erop, Вы писали:
P>>>>в каких случаях qsort, по твоему мнению, быстрее? E>>>Конкретно вот тут ты что имел в виду? Что шарики имеют форму кубиков но в другом метрическом пространстве? P>>я везде не копипастил оговорку — так как надоедает и должно быть очевидно. P>>так как не говорил об конкретном компиляторе и реализации, то я думал очевидно, что речь идёт об интерфейсе и одинаковых алгоритмах. E>Я не понимаю. Интерфейс и того и того фиксирован. И интерфейс std::sort вынуждает юзать алгоритм склонный вызывать лишние, по сравнению с qsort сравнения, в случае, если в сортируемой последовательности есть повторы...
точно также как и компаратор qsort должен делать лишнее в случае если на типах определён только предикат сравнения, и компаратор реализован через него
имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем.
Здравствуйте, Piko, Вы писали:
P>нет, вот у меня есть тип Age, который заботится о сохранении своего инварианта. написав его один раз — я уверен, что в него никогда не придёт никакая хрень — и все его пользователи имеют нормальное значение. как твои юниты тесты смогут дать хотя-бы близкую к этой гарантию??
1) Тут даже юнит-тесты не нужны. Вполне достаточно ассертов.
P>нет
Ну и какие реальные классы, оборачивающие число, ты встречал? И что там происходило для разности, суммы, среднего и т. д.?
P>ну вызвал ты f, ну ок — ну поймал на том что границы разные, ну хорошо. P>но вот стоит капельку усложнить пример: диапазоны совпадают, и что теперь??
Ну вообще код должен предметно что-то делать. Ты всё равно в систему типов всю семантику не загонишь...
Может быть возраст того и иного сотрудника, например. Они же одного типа будут?
P>я встречал, не так часто, как хотелось бы. Но, ценность type-safety от этого ничуть не убавляется
А зачем тебе этого хочется, если это не прижилось на практике?
P>вот тебе нужно на каждый чих писать unit-test, при type-safety всё вообще прозрачно и не требует внимания — бери и используй
Ну тест всё равно нужно писать, даже с типами. Или у вас ответственность программиста заканчивается, как только он смог собрать свой код? Даже типа и запускабельности не требуете?
E>>Обычно нормальные программисты пишут код осознанно... E>>И потом запускают и проверяют, что оно работает...
P>ну я же говорю, чёткие поцоны.
Либо у тебя нет опыта разработки в команде, либо ты меня троллишь.
Опиши, как по твоему выглядит процесс разработки?
P>чем он эффективней?
Ну, как минимум функции самодокумментируются
P>статический тип один раз пишется — и забыл. параметры на выходе и входе проверять нужно всегда
Так их нужно вне зависимости от типов. Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
P>имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем.
Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем. E>Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?
я правильно тебя понимаю, что в твоём понимании tristate компаратор для сортировки — это C-style, а two-state less/предикат — это C++style? и сначала всей дискуссии ты обсуждаешь именно это?
Здравствуйте, Erop, Вы писали:
P>>нет, вот у меня есть тип Age, который заботится о сохранении своего инварианта. написав его один раз — я уверен, что в него никогда не придёт никакая хрень — и все его пользователи имеют нормальное значение. как твои юниты тесты смогут дать хотя-бы близкую к этой гарантию?? E>1) Тут даже юнит-тесты не нужны. Вполне достаточно ассертов.
и где гарантия что assert не забудут вставить везде? можешь не отвечать, я знаю ответ...
в случае с типом — такая гарантия есть и заметь, телодвижений нужно меньше делать
P>>ну вызвал ты f, ну ок — ну поймал на том что границы разные, ну хорошо. P>>но вот стоит капельку усложнить пример: диапазоны совпадают, и что теперь?? E>Ну вообще код должен предметно что-то делать. Ты всё равно в систему типов всю семантику не загонишь...
не спорю, я этого и не говорил
но, получается возложить большую часть той возни которую ты предлагаешь делать юнит тестами
E>Может быть возраст того и иного сотрудника, например. Они же одного типа будут?
да. одного
P>>я встречал, не так часто, как хотелось бы. Но, ценность type-safety от этого ничуть не убавляется E>А зачем тебе этого хочется, если это не прижилось на практике?
ну знаешь, я naked new/delete встречал на практике больше чем хотелось бы, и что из этого??
P>>вот тебе нужно на каждый чих писать unit-test, при type-safety всё вообще прозрачно и не требует внимания — бери и используй E>Ну тест всё равно нужно писать, даже с типами. Или у вас ответственность программиста заканчивается, как только он смог собрать свой код? Даже типа и запускабельности не требуете?
конечно нужно писать, но не на всякую мелочь
P>>чем он эффективней? E>Ну, как минимум функции самодокумментируются
а чем
Salary DoSomething(Age);
не документирована?
имхо, даже лучше чем тестами, так как видно на месте всё
P>>статический тип один раз пишется — и забыл. параметры на выходе и входе проверять нужно всегда E>Так их нужно вне зависимости от типов.
не спорю, но так как многих мелких ошибок быть не может в принципе, можно спокойно подниматься на более высокий уровень, и делать unit-тесты именно там
либо вообще не unit-тесты, а просто полностью внешние real-case тесты
E>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
Здравствуйте, Erop, Вы писали:
CC>>Сколько бы у тебя опыта не было — недостаток автоматики в С это никак не исправляет. С этим можно только смириться и писать всё руками. E>Обсуждалось совсем другое, вроде как.
Да тут уже такой срач развели что тяжко отследить что там на самом деле обсуждали.
Надо всю ветку сносить к троллям в КСВ .
E>А так, да, можешь считать, что С-программы намного в болььшей степени hand-made
Да чего там считать, я на plain C пописал достаточно чтоб за это его недолюбливать.
E> потому и хороши.
Не соглашусь. Как только надо писать что либо относительно крупное то это становится нефиговым недостатком. Очень много времени уходит на восходы и закаты небесных светил вручную. Особенно ощущается когда с другого языка приходишь.
E>Выписанность кода руками вообще не считается недостатком, это достоинство.
Вот тока когда сам эти художества выписываешь, причём дофига выписываний это то, что в том же С++ работает автоматически, то как то заколёбывает. Хочется воткнуть нормальные классы, операторы, контейнеры и прочие радости жизни.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Alexey Sudachen, Вы писали:
CC>>Передача по значению вместо ссылки, введён совершенно бесполезный класс Y. Мда... AS>Да именно так. Предполагалось что читающий таки умеет думать и чуток знает язык, а не только способен внимательно читать )))
Ты в качестве примера написал говнокод. Объясни внятно — зачем?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали:
E>Суть в том, что на С и С++ пишут ПО РАЗНОМУ.
Капитан на линии?
E>Но прикольно тут не это, а то, что вам с Пико было не очевидно, как получить пример тормозов std::sort'а...
Конкретно сам std::sort алгоритмически не идеален, факт. Я прекрасно понял на что ты намекаешь — на использование оператора сравнения c семантикой bool operator < (), т.е. чтоб проверить на == надо его вызывать дважды.
Вот только разговор шёл не об этом. А о темплейтном коде с предикатом.
Берём твой тест счётчик вызовов компаратора.
Лёгким движением руки делаем простой тест: клонируем std::sort, и меняем там предикат так, чтоб он принимал int (< 0, == 0, > 0).
Меняем соответственно вызывающий код.
#include <CrayLib.h>
#include <stdlib.h>
#include <algorithm>
#include <vector>
class RandNum {
int body;
static int countCpp;
static int countC;
public:
RandNum() : body( rand() ) {}
static int CmpImpl( const RandNum* arg1, const RandNum* arg2 )
{ countC++; return arg1->body - arg2->body; }
static int CPPCmpImpl( const RandNum& arg1, const RandNum& arg2 )
{ countCpp++; return arg1.body - arg2.body; }
static int Cmp( const void* arg1, const void* arg2 ) { return CmpImpl( (const RandNum*) arg1, (const RandNum*) arg2 ); }
static const int CppCount() { return countCpp; }
static const int CCount() { return countC; }
};
int RandNum::countC = 0;
int RandNum::countCpp = 0;
void RN_test( int n = 1000 )
{
std::vector<RandNum> arrCpp;
for( int i = 0; i < n; i++ ) {
arrCpp.push_back( RandNum() );
}
std::vector<RandNum> arrC( arrCpp );
qsort( &arrC[0], arrC.size(), sizeof( RandNum ), RandNum::Cmp );
mod_sort( arrCpp.begin(), arrCpp.end(), [] (const RandNum& a, const RandNum& b) {return RandNum::CPPCmpImpl (a, b);});
printf ("C: %u : C++: %u\n", RandNum::CCount(), RandNum::CppCount());
printf ("%u\n", RandNum::CppCount() * 100 / RandNum::CCount());
}
int main ()
{
RN_test ();
}
И внезапно получаем:
C: 12048 : C++: 11866
98
E>вы и правда не видите, что std::sort пессимизирован в угоду красоте и реюзабельности кода, я просто показал вам код и пример.
Мы не обсуждаем конкретную реализацию std::sort. Мы обсуждаем подход: шаблонный код с вкомпиливаемым компаратором vs отдельный заранее скомпиленный код с функцией-компаратором.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали:
E>Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?
использование less компаратора вместо 3-state в STL не означает что только так и никак иначе следует писать на С++.
Я когда то избавился от STL в своих проектах, написав свои аналоги. Сортировки в том числе.
Так, интересу ради вот тебе выдержка из regression tests:
sort3 это вариант сортера, который принимает 3-state предикат.
выглядит это примерно так:
template<class Iter, class LessComparator> void sort (Iter first, Iter last, LessComparator LCmp)
{
Sort::Main (first, last, last - first, [LCmp] (decltype(*first) a, decltype(*last) b) {return (LCmp (a, b)) ? -1 : (LCmp (b, a) ? 1 : 0);}, LCmp);
}
template<class Iter> void sort (Iter first, Iter last)
{
Sort::Main (first, last, last - first,
[] (decltype(*first) a, decltype(*last) b) {return (a < b) ? -1 : ((b < a) ? 1 : 0);},
[] (decltype(*first) a, decltype(*last) b) {return (a < b);}
);
}
template<class Iter, class Comparator> void sort3 (Iter first, Iter last, Comparator Cmp)
{
Sort::Main (first, last, last - first, Cmp, [Cmp] (decltype(*first) a, decltype(*last) b) {return (Cmp (a, b) < 0);});
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Не понятно, какой диапазон возрастов допускает DoSomething
P>имхо, даже лучше чем тестами, так как видно на месте всё
Я. вообще-то, говорил про assert'ы
P>не спорю, но так как многих мелких ошибок быть не может в принципе, можно спокойно подниматься на более высокий уровень, и делать unit-тесты именно там
Это иллюзия. В реале для DoXXX, в зависимости от того, что скрывается за XXX, нужны разные ограничения.
Ну например, если ХХХ = "получить пенсию", то можно проверить, что возраст подходящий либо есть иное основание для пенсии.
E>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
P>я этого не говорил
Ну значит предусловия на входе в функции всё равно надо проверять, а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип.
И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
И теперь этот новый шаблон как ёжки тестируем
CC>Мы не обсуждаем конкретную реализацию std::sort. Мы обсуждаем подход: шаблонный код с вкомпиливаемым компаратором vs отдельный заранее скомпиленный код с функцией-компаратором.
Это понятно, что если функци подставится, то может быть немного быстрее, а если функция тривиальная, то и много.
Беда тут в том, что всё станет сложнее, std::map, std::set, для всяких типов, вроде int работать из коробки не будет, либо надо будет для них функцию сравнения приивинтить и т. д...
И так выходит на круг, что фиг бы с ней, с той эффективностью, главное реюзабельность
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
P>>не документирована? E>Не понятно, какой диапазон возрастов допускает DoSomething
конкретно здесь — любой валидный возраст
P>>имхо, даже лучше чем тестами, так как видно на месте всё E>Я. вообще-то, говорил про assert'ы
ты assert'ы в интерфейсы выносишь? или каждый раз в код вызываемой функции смотришь?
P>>не спорю, но так как многих мелких ошибок быть не может в принципе, можно спокойно подниматься на более высокий уровень, и делать unit-тесты именно там E>Это иллюзия. В реале для DoXXX, в зависимости от того, что скрывается за XXX, нужны разные ограничения. E>Ну например, если ХХХ = "получить пенсию", то можно проверить, что возраст подходящий либо есть иное основание для пенсии.
ок, допустим в этом случае — пусть не будем вводить новый тип для пенсионеров, но всё равно уже одной проверкой на верхнюю границу меньше — разве плохо?
E>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций? P>>я этого не говорил E>Ну значит предусловия на входе в функции всё равно надо проверять
если типов недостаточно — то надо
допустим когда проверка параметров зависит от двух параметров — можно и ввести проверку — не проблема. но, проверка получается меньше
E>а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип.
чтобы уменьшить возню с assert.
E>И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д...
ок, только ты ответь сначала, что означает сумма возрастов семантически?
Здравствуйте, Piko, Вы писали:
P>ок, допустим в этом случае — пусть не будем вводить новый тип для пенсионеров, но всё равно уже одной проверкой на верхнюю границу меньше — разве плохо?
Конечно плохо, так как проверки размазаны по коду не понятно где их искать и как их менять, если вдруг понадобится...
P>если типов недостаточно — то надо
То есть ты таки надешься? E>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
P>допустим когда проверка параметров зависит от двух параметров — можно и ввести проверку — не проблема. но, проверка получается меньше E>>а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип. P>чтобы уменьшить возню с assert.
Это если ты считаешь, что assert -- это "возня", хотя на самом деле это один из способов самотестирования и самодокументирования программы.
Система типов хороша, когда она гарантирует бинарную корректность данных, так так тогда сильно упрощается анализ поведения программы. А всякая ерунда, вроде "числа месяца" это типа IntRange<1, 31>::Type, а числа года IntRange<1, 365>::Type, но в високосном IntRange<1, 366>::Type -- это от лукавого...
E>>И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д... P>ок, только ты ответь сначала, что означает сумма возрастов семантически?
Это то, что делятна число людей, что бы узнать их средний возраст, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>ок, допустим в этом случае — пусть не будем вводить новый тип для пенсионеров, но всё равно уже одной проверкой на верхнюю границу меньше — разве плохо? E>Конечно плохо, так как проверки размазаны по коду не понятно где их искать и как их менять, если вдруг понадобится...
что понадобится?
Тип Age заботится о том, чтобы возраст был допустимым
P>>если типов недостаточно — то надо E>То есть ты таки надешься? E>>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
P>>допустим когда проверка параметров зависит от двух параметров — можно и ввести проверку — не проблема. но, проверка получается меньше E>>>а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип. P>>чтобы уменьшить возню с assert. E>Это если ты считаешь, что assert -- это "возня", хотя на самом деле это один из способов самотестирования и самодокументирования программы.
ну так если типы намного проще в использовании и документировании
E>Система типов хороша, когда она гарантирует бинарную корректность данных, так так тогда сильно упрощается анализ поведения программы.
E>А всякая ерунда, вроде "числа месяца" это типа IntRange<1, 31>::Type, а числа года IntRange<1, 365>::Type, но в високосном IntRange<1, 366>::Type -- это от лукавого...
А в чём проблема? Может для числа месяца это избыточно, отчасти потому, что само по себе редко используется.
Но сделать нормальный класс Date с инвариантами — намного легче чем сувать везде assert(IsValidDate(x))
E>>>И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д... P>>ок, только ты ответь сначала, что означает сумма возрастов семантически? E>Это то, что делятна число людей, что бы узнать их средний возраст, например...
я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так?
Здравствуйте, Piko, Вы писали:
P>что понадобится?х P>Тип Age заботится о том, чтобы возраст был допустимым
Можешь выразить это "допустимым" конкретнее? С чего ты вообще взял, что для разных дел допустимый возраст один и тот же?
P>>>если типов недостаточно — то надо E>>То есть ты таки надешься? E>>>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
P>ну так если типы намного проще в использовании и документировании
Давай, покажи нам на примере возраста
P>я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так?
нет не так. Ещё дисперсия бывает, или скидка молодой семье, суммарный возраст которой меньше 45 лет
И разность возрастов не забывай пожалуйста
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>что понадобится?х P>>Тип Age заботится о том, чтобы возраст был допустимым E>Можешь выразить это "допустимым" конкретнее? С чего ты вообще взял, что для разных дел допустимый возраст один и тот же?
Тип Age отвечает вообще за возраст. Допустим от 0 до 200 (ну мало ли, главное слишком большой не допустить).
А дальше, можно делать либо более требовательные типы, либо проверку внутри (если проверка одноразовая). Не вижу никаких проблем.
и при этом, внутри, возюканья в любом случае меньше. допустим подходят только старше 20 — не вопрос, просто проверка на >20, проверку на верхнюю границу делать не надо
P>>>>если типов недостаточно — то надо E>>>То есть ты таки надешься? E>>>>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций? P>>ну так если типы намного проще в использовании и документировании E>Давай, покажи нам на примере возраста
я уже показал
Salary getEstimaedSalary(Age);
Принимает возраст, возвращает зарплату
а что у тебя что
int getEstimaedSalary(int);
?
и ассерты внутри??
P>>я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так? E>нет не так. Ещё дисперсия бывает, или скидка молодой семье, суммарный возраст которой меньше 45 лет
ну и считай — в чём проблема-то? вроде умеешь
E>И разность возрастов не забывай пожалуйста
Здравствуйте, Piko, Вы писали:
P>Тип Age отвечает вообще за возраст. Допустим от 0 до 200 (ну мало ли, главное слишком большой не допустить). P>А дальше, можно делать либо более требовательные типы, либо проверку внутри (если проверка одноразовая). Не вижу никаких проблем.
А я вот вижу проблемы. Мафусуил, например, прожил 997 лет, что ли, а Адам 600 с чем-то, а число 200 ты взял с потолка, нагородил вокруг целый тип, и навёл кучу тени на плетень... Заметь, на пустом месте.
Абстракции они того, трудно делаются, особенно если ты хочешь их из пальца высасывать и при этом ещё и не ошибаться
P>и при этом, внутри, возюканья в любом случае меньше. допустим подходят только старше 20 — не вопрос, просто проверка на >20, проверку на верхнюю границу делать не надо
А зачем вообще делать проверку на верхнюю, если она не нужна?
А если уж нужна, то что хорошего в том, что одна проверка записана в функции, а другая где-то в недрах возраста?
E>>Давай, покажи нам на примере возраста
P>я уже показал
Пока показал лишь то, что ты некомпатибл с Библией...
P>
P>Salary getEstimaedSalary(Age);
P>
P>Принимает возраст, возвращает зарплату P>а что у тебя что P>
P>int getEstimaedSalary(int);
P>
P>? P>и ассерты внутри??
В С/С++ принято давать понятные имена параметрам функций, как и самим функциям
money getEstimaedSalary(int age)
P>>>я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так? E>>нет не так. Ещё дисперсия бывает, или скидка молодой семье, суммарный возраст которой меньше 45 лет
P>ну и считай — в чём проблема-то? вроде умеешь
тип какой у всех этих выражений будет?
E>>И разность возрастов не забывай пожалуйста
P>ага, ещё умножение до-кучи — возраст в квадрате
возраст в квадрате концепт небанальный, хотя в какой-нибудь медицинский индекс запросто может входить, а вот на сколько Петя старше своей жены Маши вопрос весьма жизненный
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском