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

P>я тебя поздравляю, _Debug_lt небось

Попробуй получить число меньше 100%

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

P>>я тебя поздравляю, _Debug_lt небось
E>Попробуй получить число меньше 100%

то есть всё таки не 180%
так получил ведь, но на stable_sort, которая также является частью стандарта который ты всё пытаешься "выкинуть на помоечку"

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

P>нет, не входят.
Тогда какой смысл выделять именно те ошибки, которые находятся при компиляции?

P>юнит-тесты — это во-превых runtime тесты, во-вторых их ещё необходимо написать. а например в случае sort мы получаем compile-time проверки без дополнительных усилий, и даже наоборот — его проще использовать.
Это самообман. Что бы его потом было "проще использовать" тебе понадобится написать кучу всякой хрени.

P>статические анализаторы кода ловят далеко не все те ошибки, которые можно поймать используя типизацию и т.п.
Ну лучше всего ошибки ловят, тем не менее, тесты. Они же лучше всего описывают поведение.
Ты просто почему-то считаешь, что кодирование требований к коду в системе типов бесплатное. А если посмотреть на С++ с его шаблонами и наворотами в библиотеках, то оно очень сильно платное и вообще непростое и череватое своими специфическими ошибками.
И чем ошибка "почему у меня не компилируется bind" лучше ошибки, что не работает такая-то С-библиотека -- не понятно.

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

И чё, кто-то в продакшине так делает?
Все пишут assert's и всё...


P>в qsort всегда нужно передавать размер массива, и элемента -> проще ошибиться и получить overflow
P>в std::sort конечно тоже можно ошибиться с границей, но имхо — это намного реже происходит,
Почему? Ровно наоборот. Если в программе есть несколько массивов чисел, например, то ситуаци, когда они все имеют равные или близкие размеры весьма распространена. Так что если ты передашь размер не от того массива, то получишь намного менее фатальную проблему, чем если передашь end не от того массива


P>во вторых не нужно передавать размер элемента, и в третьих "unit-test" внутрb sort, для debug, легче добавить проверку диапазона — что и делается в некоторых реализациях.

В С тоже есть средства, ловли оращения мимо буферов...

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

P>ипать,

Во-первых, мат тут запрещён!

P>вот это выводы: в одном случае компаратор tristate — в другом обычный предикат, и ты из этого делаешь вывод, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА

Во-вторых, попробуй подышать, успокоиться и прочитать то, что писал я, а не продиктовали тебе твои эмоции.
Я писал, что если Страуструпу удалось ввести тебя в заблуждение, то это хорошо иллюстрирует насколько С++ сильно скрывает суть дела от программистов. Ты же считаешь себя опытным программистом, я надеюсь?

или ты всё это время троллил, в след за Бьярне?..

Ну и главное, что за вспышка эмоций-то? Я в таком тоне беседовать не хочу. Давай ты подышишь, покипишь, выпустишь пар, а потом взвешенно попробуешь понять, как так получилось, что ты вс время приводил аргумент против себя. И расскажешь всем нам, что помешало тебе сразу заметить, что тебя водят за нос.

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


P>ога, ога.
P>замени
P>

P>RandNum() : body( rand() ) {}
P>на
P>RandNum() {static int cnt=100000000; body=cnt;--cnt;}
P>

P>и сравни qsort, sort и stable_sort, раз уж мы об алгоритмах заговорили и об C++way
P>у stable_sort почти в три раз меньше вызовов предиката чем вызовов компаратора у qsort.
P>и что теперь?
P>я жду новых чудесных выводов с твоей стороны

Ну ты прекрасно показал, что твоё первоначальное "std::sort всегда быстрее qsort" девальвировало до "std::stable_sort на моём компиляторе и в релиз версии лучше qsort на очень длинных ОБРАТНО УПОРЯДОЧЕННЫХ последовательностях".
Не могу не заметить, что это, конечно очень ценное свойство, но reverse вообще в компараторе на этих данных не нуждается и всё прекрасно сортирует

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

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

Обсуждалось совсем другое, вроде как.
А так, да, можешь считать, что С-программы намного в болььшей степени hand-made, потому и хороши. Я вот, например, люблю свитера ручной вязки, хотя большинство остального трикотажа предпочитаю фабричной выделки. Тут, насколько я понимаю приверженцев С, примерно такая же фигня. Выписанность кода руками вообще не считается недостатком, это достоинство.


CC>Тон бывает в устной речи. Как его углядеть в тексте —
Разве не ты начал про тон?..
IMHO, тебе есть о чём с собой поговорить...

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

E>>>Или поясни, что такое compile-time? Входит ли в него время прогона статических анализаторов кода и юнит-тестов?
P>>нет, не входят.
E>Тогда какой смысл выделять именно те ошибки, которые находятся при компиляции?

самый передний фронт защиты.

P>>статические анализаторы кода ловят далеко не все те ошибки, которые можно поймать используя типизацию и т.п.
E>Ну лучше всего ошибки ловят, тем не менее, тесты. Они же лучше всего описывают поведение.
E>Ты просто почему-то считаешь, что кодирование требований к коду в системе типов бесплатное.

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

E>А если посмотреть на С++ с его шаблонами и наворотами в библиотеках, то оно очень сильно платное и вообще непростое и череватое своими специфическими ошибками.

да какие навороты? простой класс Age, наворот?

E>И чем ошибка "почему у меня не компилируется bind" лучше ошибки, что не работает такая-то С-библиотека -- не понятно.

"не работает" может случится у клиента, если тесты профукали. а "не компилируется bind" — видно сразу

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

как? использует классы с инвариантами?

E>Все пишут assert's и всё...

жесть. то есть в каждой функции которая принимает "int age", копипастится assert

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

CC>template<class _RanIt, class _Pr> void sort (_RanIt _First, _RanIt _Last, _Pr _Pred)

CC>Тогда сравним то, о чём на самом деле ведётся речь.

Суть в том, что на С и С++ пишут ПО РАЗНОМУ.
Но прикольно тут не это, а то, что вам с Пико было не очевидно, как получить пример тормозов std::sort'а...
или ты таки стебался?
Сначала я думал, что вы прикалываетесь, но когда я понял, что вы и правда не видите, что std::sort пессимизирован в угоду красоте и реюзабельности кода, я просто показал вам код и пример.

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

P>>вот это выводы: в одном случае компаратор tristate — в другом обычный предикат, и ты из этого делаешь вывод, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА
E>Я писал, что если Страуструпу удалось ввести тебя в заблуждение, то это хорошо иллюстрирует насколько С++ сильно скрывает суть дела от программистов.

чем ему удалось ввести меня в заблуждение? и в какое заблуждение?
конкретно

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

E>Ну ты прекрасно показал, что твоё первоначальное "std::sort всегда быстрее qsort" девальвировало до "std::stable_sort на моём компиляторе и в релиз версии лучше qsort на очень длинных ОБРАТНО УПОРЯДОЧЕННЫХ последовательностях".

какое первоначальное?
я говорил "при одинаковых алгоритмах":
http://www.rsdn.ru/forum/cpp/4795130.1.aspx

Автор: Piko
Дата: 27.06.12

E>Не могу не заметить, что это, конечно очень ценное свойство, но reverse вообще в компараторе на этих данных не нуждается и всё прекрасно сортирует

шутник

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

E>Сначала я думал, что вы прикалываетесь, но когда я понял, что вы и правда не видите, что std::sort пессимизирован в угоду красоте и реюзабельности кода, я просто показал вам код и пример.

ога, взяв подмышку debug_lt

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

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

Это не иллюзия даже, это просто фейл. Ошики надо начинать намного раньше, чем случилась компиляция, чего бы то ни было, и даже раньше начала кодирования...

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

Ну ты можешь попробовать написать юнит-тест на свой тип, и гарантировать его работоспособность тестированием, а не типизацией. Откуда уверенность, что это дороже/хуже/ненадёжнее?

P>да какие навороты? простой класс Age, наворот?
Для числа?
Конечно наворот и пессимизация!
Правда в С++ можно сделать и так

Автор: Erop
Дата: 29.04.08

...
Но это всё равно навороты

В С, как и в "С++ для не слишком умных" можно просто написать

int IsValidAge( int );

и потом писать везде на входе в функции

assert( IsValidAge( age ) );

P>"не работает" может случится у клиента, если тесты профукали. а "не компилируется bind" — видно сразу
C++ умеет плодить ошибки, которые проявляются крайне редко. Скажем зависимость от порядка инициализации/деинициализации статических переменных...
Ограниченная проверка соблюдени ODR и много других, которые в С в принципе не возможны.
При этом цикл разработки на С подразумевает более тщательное тестирование

P>как? использует классы с инвариантами?
Пишет класс для возраста.

P>жесть. то есть в каждой функции которая принимает "int age", копипастится assert
Почему копипастится? Обычно у функций параметры называются по-разному, кстати.

Вообще есть такой подход, на входе в функцию -- проверка параметров, на выходе -- проверка результатов...
Он намного эффективнее статических типов

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

P>то есть всё таки не 180%
Ты читаешь невнимательно. 182%...

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

P>чем ему удалось ввести меня в заблуждение? и в какое заблуждение?
P>конкретно

Что std::sort всегда быстрее qsort...
Ты вроде это довольно долго и последовательно утверждал?..

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

P>какое первоначальное?
P>я говорил "при одинаковых алгоритмах":
P>http://www.rsdn.ru/forum/cpp/4795130.1.aspx

Автор: Piko
Дата: 27.06.12

Я это утверждение вообще не понимаю. Это примерно как сказать, что кубики всегда легче шариков, если кубики и шарики имеют одинаковую форму...

E>>Не могу не заметить, что это, конечно очень ценное свойство, но reverse вообще в компараторе на этих данных не нуждается и всё прекрасно сортирует

P>шутник
Ну так на тебя сморю и учусь...

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

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

P>>>ок, но сначала ответь, желательно с аргументами: qsort vs std::sort
P>>>1. что быстрее
E>>Зависит от задачи и от программиста

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

Конкретно вот тут ты что имел в виду? Что шарики имеют форму кубиков но в другом метрическом пространстве?

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

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

E>>>Тогда какой смысл выделять именно те ошибки, которые находятся при компиляции?
P>>самый передний фронт защиты.
E>Это не иллюзия даже, это просто фейл. Ошики надо начинать намного раньше, чем случилась компиляция, чего бы то ни было, и даже раньше начала кодирования...

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

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

этот юнит тест будет проверять все места использования типа ??

P>>да какие навороты? простой класс Age, наворот?
E>Для числа?

внутри Age, по-идеи одно число

E>Конечно наворот и пессимизация!

жесть

E>В С, как и в "С++ для не слишком умных" можно просто написать

int IsValidAge( int );

и потом писать везде на входе в функции

assert( IsValidAge( age ) );

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

int f(int age, int level);// где level - это допустим "уровень" работника по внутренней шкале фирмы, допустим от 1 до 50.

ок, это чоткий парень пишет

assert(IsValidAge( age ));
assert(IsValidLevel( level ));

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

int g(int level, int age);

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

E>>>И чё, кто-то в продакшине так делает?
P>>как? использует классы с инвариантами?
E>Пишет класс для возраста.

а в чём проблема? (при том, что в примере выше, код проверки range будет общим для age и level)

P>>жесть. то есть в каждой функции которая принимает "int age", копипастится assert
E>Почему копипастится? Обычно у функций параметры называются по-разному, кстати.

ога, добавляем разные именна в контекста для слежки чёткого пацана. А что? он же чёткий — всё запомнит, всё проверит.

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

orly?

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

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

я везде не копипастил оговорку — так как надоедает и должно быть очевидно.
так как не говорил об конкретном компиляторе и реализации, то я думал очевидно, что речь идёт об интерфейсе и одинаковых алгоритмах.
а иначе можно взять быстрый qsort, и std::sort внутри которого sleep стоит, либо debug_lt и ещё какая-нибудь хрень. и в чём тогда смысл?
Я всё таки стараюсь уважать сообразительность собеседников и не разжёвывать очевидные вещи

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

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

Ты вообще очень непонятно выражаешь мысли, если честно. Так что не понятно. В частности не понятно, почему именно ошибки компиляции так важны.
Обычно как бывает? Система проектируется, прототипируется, тестируется потом по подсистемам реализуется. Тесты переиспользуются при этом...
А компиляция в типичном цикле разработки -- это интимное дело прогера. Я бы понял ещё ошибки, которые выявляются на момент коммита, например, но чем так выделен момент компиляции-то?

P>этот юнит тест будет проверять все места использования типа ??
Это предложение я тоже не понял. Ты пишешь библу. Ну, например, функцию qstable_sort, юнит-тестируешь её, потом она работает в твоём коде...

P>жесть
Ну ты реально часто встречал такие вот классы Age? А для концепта "разница в возрасте" чего делали, например? А для "суммарный возраст работников нашего склада"? А для "средний возраст сотрудника" что делали и как вычисляли?

Что-то мне кажется, что ты стебёшься.

P>

P>int f(int age, int level);// где level - это допустим "уровень" работника по внутренней шкале фирмы, допустим от 1 до 50.
P>

P>ок, это чоткий парень пишет
P>

P>assert(IsValidAge( age ));
P>assert(IsValidLevel( level ));
P>

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

P>int g(int level, int age);
P>

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

Оставлю весь текст, так как не знаю, что там отрезать. Суть в том, что для того и есть юнит-тесты.
В частности юнит-тест f должен будет вызвать эту функцию со всеми граничными значениями и возраста и уровня...

P>а в чём проблема? (при том, что в примере выше, код проверки range будет общим для age и level)
Проблем много, вообще-то, я там повыше указал, несколько.
Но я другой вопрос задал. ТЫ ВСТРЕЧАЛ ТАКОЕ в продакшине, а не в учебно-методических измышлениях?..
Я вот почти не встречал, например.

P>ога, добавляем разные именна в контекста для слежки чёткого пацана. А что? он же чёткий — всё запомнит, всё проверит.

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

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

P>orly?
Это я тоже не понял.

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

P>>>в каких случаях qsort, по твоему мнению, быстрее?
E>>Конкретно вот тут ты что имел в виду? Что шарики имеют форму кубиков но в другом метрическом пространстве?

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

Я не понимаю. Интерфейс и того и того фиксирован. И интерфейс std::sort вынуждает юзать алгоритм склонный вызывать лишние, по сравнению с qsort сравнения, в случае, если в сортируемой последовательности есть повторы...


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

В общем я так и не понял, что ты имел в виду в примере про сортировки. Хотя ты вслед за статьёй ссылался на какие-то замеры производительности, вроде?
В любом случае, попробуй ТОЧНО сформулировать свой тезис. Возможно он не вызовет ни в ком желания спорить