Re[42]: MSVC2010 + C99
От: Piko  
Дата: 27.06.12 22:47
Оценка:
Здравствуйте, 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>Это я тоже не понял.

чем он эффективней?
статический тип один раз пишется — и забыл. параметры на выходе и входе проверять нужно всегда
Re[36]: Ты тут троллил или заблуждался?
От: Piko  
Дата: 27.06.12 22:53
Оценка:
Здравствуйте, Erop, Вы писали:

P>>>>в каких случаях qsort, по твоему мнению, быстрее?

E>>>Конкретно вот тут ты что имел в виду? Что шарики имеют форму кубиков но в другом метрическом пространстве?
P>>я везде не копипастил оговорку — так как надоедает и должно быть очевидно.
P>>так как не говорил об конкретном компиляторе и реализации, то я думал очевидно, что речь идёт об интерфейсе и одинаковых алгоритмах.
E>Я не понимаю. Интерфейс и того и того фиксирован. И интерфейс std::sort вынуждает юзать алгоритм склонный вызывать лишние, по сравнению с qsort сравнения, в случае, если в сортируемой последовательности есть повторы...

точно также как и компаратор qsort должен делать лишнее в случае если на типах определён только предикат сравнения, и компаратор реализован через него
имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем.
Re[43]: MSVC2010 + C99
От: Erop Россия  
Дата: 27.06.12 23:07
Оценка:
Здравствуйте, Piko, Вы писали:

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


1) Тут даже юнит-тесты не нужны. Вполне достаточно ассертов.

P>нет

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

P>ну вызвал ты f, ну ок — ну поймал на том что границы разные, ну хорошо.

P>но вот стоит капельку усложнить пример: диапазоны совпадают, и что теперь??

Ну вообще код должен предметно что-то делать. Ты всё равно в систему типов всю семантику не загонишь...
Может быть возраст того и иного сотрудника, например. Они же одного типа будут?

P>я встречал, не так часто, как хотелось бы. Но, ценность type-safety от этого ничуть не убавляется

А зачем тебе этого хочется, если это не прижилось на практике?

P>вот тебе нужно на каждый чих писать unit-test, при type-safety всё вообще прозрачно и не требует внимания — бери и используй

Ну тест всё равно нужно писать, даже с типами. Или у вас ответственность программиста заканчивается, как только он смог собрать свой код? Даже типа и запускабельности не требуете?

E>>Обычно нормальные программисты пишут код осознанно...

E>>И потом запускают и проверяют, что оно работает...

P>ну я же говорю, чёткие поцоны.

Либо у тебя нет опыта разработки в команде, либо ты меня троллишь.
Опиши, как по твоему выглядит процесс разработки?


P>чем он эффективней?

Ну, как минимум функции самодокумментируются

P>статический тип один раз пишется — и забыл. параметры на выходе и входе проверять нужно всегда

Так их нужно вне зависимости от типов. Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[37]: Ты тут троллил или заблуждался?
От: Erop Россия  
Дата: 27.06.12 23:08
Оценка:
Здравствуйте, Piko, Вы писали:


P>имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем.


Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[38]: Ты тут троллил или заблуждался?
От: Piko  
Дата: 27.06.12 23:20
Оценка:
Здравствуйте, Erop, Вы писали:

P>>имхо, то что спор идёт не о разнице компараторов, не о возможной разнице реализованных алгоритмов, в этой теме очевидно почти всем.

E>Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?

я правильно тебя понимаю, что в твоём понимании tristate компаратор для сортировки — это C-style, а two-state less/предикат — это C++style? и сначала всей дискуссии ты обсуждаешь именно это?
Re[44]: MSVC2010 + C99
От: Piko  
Дата: 27.06.12 23:32
Оценка:
Здравствуйте, 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>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?


я этого не говорил
Re[40]: MSVC2010 + C99
От: CreatorCray  
Дата: 28.06.12 00:37
Оценка: 3 (1) +1 :)
Здравствуйте, Erop, Вы писали:

CC>>Сколько бы у тебя опыта не было — недостаток автоматики в С это никак не исправляет. С этим можно только смириться и писать всё руками.

E>Обсуждалось совсем другое, вроде как.
Да тут уже такой срач развели что тяжко отследить что там на самом деле обсуждали.
Надо всю ветку сносить к троллям в КСВ .

E>А так, да, можешь считать, что С-программы намного в болььшей степени hand-made

Да чего там считать, я на plain C пописал достаточно чтоб за это его недолюбливать.

E> потому и хороши.

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

E>Выписанность кода руками вообще не считается недостатком, это достоинство.

Вот тока когда сам эти художества выписываешь, причём дофига выписываний это то, что в том же С++ работает автоматически, то как то заколёбывает. Хочется воткнуть нормальные классы, операторы, контейнеры и прочие радости жизни.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[36]: MSVC2010 + C99
От: CreatorCray  
Дата: 28.06.12 00:37
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

CC>>Передача по значению вместо ссылки, введён совершенно бесполезный класс Y. Мда...

AS>Да именно так. Предполагалось что читающий таки умеет думать и чуток знает язык, а не только способен внимательно читать )))

Ты в качестве примера написал говнокод. Объясни внятно — зачем?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[34]: Звезда Ф ШОКЕ!!!
От: CreatorCray  
Дата: 28.06.12 01:32
Оценка: +1 :)
Здравствуйте, Erop, Вы писали:

E> у меня, например, возвращает 182%

98
Читай рядом как так вышло.
PS. STL — на помоечку, я давно это говорю!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[36]: MSVC2010 + C99
От: CreatorCray  
Дата: 28.06.12 01:32
Оценка: 3 (1) +1
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[37]: Звезда Ф ШОКЕ!!!
От: CreatorCray  
Дата: 28.06.12 02:13
Оценка: +1
Здравствуйте, Piko, Вы писали:

P>является частью стандарта который ты всё пытаешься "выкинуть на помоечку"


STL вообще то надо бы на помоечку.
По крайней мере некоторые его реализации.
Ну и архитектурно там изъянов полно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[38]: Ты тут троллил или заблуждался?
От: CreatorCray  
Дата: 28.06.12 02:13
Оценка:
Здравствуйте, Erop, Вы писали:

E>Речь идёт о сравнении двух подходов к кодированию. Типа С-стиль против С++-стиля. Не?


использование less компаратора вместо 3-state в STL не означает что только так и никак иначе следует писать на С++.
Я когда то избавился от STL в своих проектах, написав свои аналоги. Сортировки в том числе.
Так, интересу ради вот тебе выдержка из regression tests:

Сортируем 1М UTF16 случайно сгенерёных строк.

Sort: Done
std::sort<vector> : ( 1.934116) 6'368'170'140
CrayLib sort3<crVector> : ( 0.496543) 1'634'890'059
Difference : 3.895167


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, значит пора закрыть эту страницу.
Всем пока
Re[45]: MSVC2010 + C99
От: Erop Россия  
Дата: 28.06.12 03:58
Оценка:
Здравствуйте, Piko, Вы писали:

P>а чем

P>
P>Salary DoSomething(Age); 
P>

P>не документирована?

Не понятно, какой диапазон возрастов допускает DoSomething

P>имхо, даже лучше чем тестами, так как видно на месте всё


Я. вообще-то, говорил про assert'ы

P>не спорю, но так как многих мелких ошибок быть не может в принципе, можно спокойно подниматься на более высокий уровень, и делать unit-тесты именно там

Это иллюзия. В реале для DoXXX, в зависимости от того, что скрывается за XXX, нужны разные ограничения.

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

E>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?


P>я этого не говорил


Ну значит предусловия на входе в функции всё равно надо проверять, а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип.
И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[37]: MSVC2010 + C99
От: Erop Россия  
Дата: 28.06.12 05:44
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>И внезапно получаем:

CC>C: 12048 : C++: 11866
CC>98

И теперь этот новый шаблон как ёжки тестируем

CC>Мы не обсуждаем конкретную реализацию std::sort. Мы обсуждаем подход: шаблонный код с вкомпиливаемым компаратором vs отдельный заранее скомпиленный код с функцией-компаратором.


Это понятно, что если функци подставится, то может быть немного быстрее, а если функция тривиальная, то и много.
Беда тут в том, что всё станет сложнее, std::map, std::set, для всяких типов, вроде int работать из коробки не будет, либо надо будет для них функцию сравнения приивинтить и т. д...
И так выходит на круг, что фиг бы с ней, с той эффективностью, главное реюзабельность
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[46]: MSVC2010 + C99
От: Piko  
Дата: 28.06.12 09:14
Оценка:
Здравствуйте, Erop, Вы писали:

P>>а чем

P>>
P>>Salary DoSomething(Age); 
P>>

P>>не документирована?
E>Не понятно, какой диапазон возрастов допускает DoSomething

конкретно здесь — любой валидный возраст

P>>имхо, даже лучше чем тестами, так как видно на месте всё

E>Я. вообще-то, говорил про assert'ы

ты assert'ы в интерфейсы выносишь? или каждый раз в код вызываемой функции смотришь?

P>>не спорю, но так как многих мелких ошибок быть не может в принципе, можно спокойно подниматься на более высокий уровень, и делать unit-тесты именно там

E>Это иллюзия. В реале для DoXXX, в зависимости от того, что скрывается за XXX, нужны разные ограничения.
E>Ну например, если ХХХ = "получить пенсию", то можно проверить, что возраст подходящий либо есть иное основание для пенсии.

ок, допустим в этом случае — пусть не будем вводить новый тип для пенсионеров, но всё равно уже одной проверкой на верхнюю границу меньше — разве плохо?

E>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?

P>>я этого не говорил
E>Ну значит предусловия на входе в функции всё равно надо проверять

если типов недостаточно — то надо
допустим когда проверка параметров зависит от двух параметров — можно и ввести проверку — не проблема. но, проверка получается меньше

E>а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип.


чтобы уменьшить возню с assert.

E>И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д...


ок, только ты ответь сначала, что означает сумма возрастов семантически?
Re[47]: MSVC2010 + C99
От: Erop Россия  
Дата: 28.06.12 13:33
Оценка:
Здравствуйте, Piko, Вы писали:

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


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

P>если типов недостаточно — то надо

То есть ты таки надешься?
E>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?

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

E>>а тогда не понятно на кой возиться с выделением ввозраста в отдельный тип.
P>чтобы уменьшить возню с assert.

Это если ты считаешь, что assert -- это "возня", хотя на самом деле это один из способов самотестирования и самодокументирования программы.
Система типов хороша, когда она гарантирует бинарную корректность данных, так так тогда сильно упрощается анализ поведения программы. А всякая ерунда, вроде "числа месяца" это типа IntRange<1, 31>::Type, а числа года IntRange<1, 365>::Type, но в високосном IntRange<1, 366>::Type -- это от лукавого...

E>>И ты так и не ответил про производные типы. Разность взрастов, сумму, средний и т. д...

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

Это то, что делятна число людей, что бы узнать их средний возраст, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[48]: MSVC2010 + C99
От: Piko  
Дата: 28.06.12 14:55
Оценка:
Здравствуйте, 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>Это то, что делятна число людей, что бы узнать их средний возраст, например...

я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так?
Re[49]: MSVC2010 + C99
От: Erop Россия  
Дата: 28.06.12 17:54
Оценка:
Здравствуйте, Piko, Вы писали:

P>что понадобится?х

P>Тип Age заботится о том, чтобы возраст был допустимым
Можешь выразить это "допустимым" конкретнее? С чего ты вообще взял, что для разных дел допустимый возраст один и тот же?

P>>>если типов недостаточно — то надо

E>>То есть ты таки надешься?
E>>>>>>Или ты надеешься написать систему типов, которая предусмотрит предусловия всех разработанных в последствии функций?

P>ну так если типы намного проще в использовании и документировании


Давай, покажи нам на примере возраста


P>я это и хотел услышать, то есть сумма сама по себе не нужна, а нужно усреднение, так?

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

И разность возрастов не забывай пожалуйста
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[50]: MSVC2010 + C99
От: Piko  
Дата: 28.06.12 18:27
Оценка:
Здравствуйте, 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>И разность возрастов не забывай пожалуйста


ага, ещё умножение до-кучи — возраст в квадрате
Re[51]: MSVC2010 + C99
От: Erop Россия  
Дата: 28.06.12 22:39
Оценка:
Здравствуйте, 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>ага, ещё умножение до-кучи — возраст в квадрате

возраст в квадрате концепт небанальный, хотя в какой-нибудь медицинский индекс запросто может входить, а вот на сколько Петя старше своей жены Маши вопрос весьма жизненный
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.