Здравствуйте, Erop, Вы писали:
P>>в каких случаях qsort, по твоему мнению, быстрее? E>Слушайте, люди, вы меня правда пугаете. E>Ты сам не можешь написать пример в котором qsort порвёт std::sort? E>Хочешь совет? Напиши пример где функция сравнения ДОЛГАЯ. E>Например, у тебя есть массив неотрицательных чисел, E>чтобы сравнить два, ты от каждого вычисляешь exp( x / x_max ), с точностью 1 000 000 знаков, и потом в лексографическом с конца порядке сортируешь. Ну и чисел тысяч 10 хотя бы в массиве E>Вот, что бы лучше думалось, попробуй угадать, что вернёт функция RN_test:
class RandNum {
E>
у меня, например, возвращает 182%
идея зачётная но, к дискуссии имеет мало отношения
это уже разница самих алгоритмов(вытекающих из интерфейсов). с тем же успехом, можно имея только предикат less, реализовать через него компаратор для qsort.
с этой точки зрения пример не удачный, имхо очевидно
с тем же успехом можно взять хорошую реализацию qsort, и плохую sort, эта тема уже обсуждалась в начале топика
P>>в каких случаях qsort, по твоему, мнению надёжней? E>По моему мнению для всех. Ещё надёжнее, будет если её немножко шаблонно обернуть, но даже в чистом С-варианте она неверно работает только если передать не так буфер или напутать с типами.
ога, или с размером массива, или с размерам типа ...
E>Ещё надёжнее, будет если её немножко шаблонно обернуть
то есть ты согласен, что на C++ она была бы надёжней?
E>В std::sort способов накрячится есть просто невообразимое множество
не хочу опять начинать с тобой спорить на эту тему (ты же про duck-typing, отсутствие концепций и т.п.?).
но, вопрос: где по-твоему мнению программисты ошибаются чаще? с qsort или sort?
не количество возможных путей и бла-бла, а именно на практике что надёжней.
P>>>>3. что безопасней E>>>Зависит от задачи и от программиста P>>в каких случаях qsort, по твоему, мнению безопасней? E>А что значит "безопаснее"? Какая модель угроз?
Здравствуйте, Piko, Вы писали:
P>уже писал. P>вкратце: надёжность — больше ошибок(классов ошибок) ловится compile-time.
Я не согласен что это надёжность. Или поясни, что такое compile-time? Входит ли в него время прогона статических анализаторов кода и юнит-тестов?
P>безопасность — менее подверженность vulnerabilities. P>но это вкратце
Я не совсем понимаю, как qsort или std::sort могут быть опасными, тогда...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
P>идея зачётная но, к дискуссии имеет мало отношения P>это уже разница самих алгоритмов(вытекающих из интерфейсов). с тем же успехом, можно имея только предикат less, реализовать через него компаратор для qsort. P>с этой точки зрения пример не удачный, имхо очевидно P>с тем же успехом можно взять хорошую реализацию qsort, и плохую sort, эта тема уже обсуждалась в начале топика
А я считаю, что имеет.
1) Ты тут всем вслед за Страуструпом проел всем плешь, что qsort медленнее std::sort, хотя для долгих операций сравнения это просто ПРЯМАЯ ЛОЖЬ.
Мне было смешно тебя читать, и все эти ужимки про то, что тормоз порвёт скорохода.
Страуструп всех просто немного подколол, он это любит, а вот ты тоже дурачился или на голубом глазу повёлся?
Если второе, то это очень неплохая иллюстрация, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА, и это его главный и основной недостаток...
2) Про плохую и хорошую реализацию. Мы таки несём STL на помоечку или как? И то и то стандартные средства своих языков, а не поделки криворуких тенденциозных тестеров, вообще-то. И авторы стандарта С++ и STL, и самого std::sort конечно же понимали, что они пессимизируют свой код примерно в два раза, по сравнению с С, но при этом они вынужденно пошли на это, стыдливо прикрывшись подстановкой функций обмена и сравнения
Как ты думаешь, зачем std::sort в STL cделан тормозом?
P>ога, или с размером массива, или с размерам типа ...
Ну надо контролировать тип, это можно поручить статическому анализатору или макросу, а в С++ ещё и простому шаблону-обёртке.
E>>Ещё надёжнее, будет если её немножко шаблонно обернуть
P>то есть ты согласен, что на C++ она была бы надёжней?
Нет не согласен. На С++ писали бы как на С++ и получили бы в конце std::sort E>>В std::sort способов накрячится есть просто невообразимое множество
P>не хочу опять начинать с тобой спорить на эту тему (ты же про duck-typing, отсутствие концепций и т.п.?). P>но, вопрос: где по-твоему мнению программисты ошибаются чаще? с qsort или sort? P>не количество возможных путей и бла-бла, а именно на практике что надёжней.
Я не согласен с твоим определением надёжности, но я думаю, что в готовом оттестированном коде ошибки с std::sort остаются чаще, чем с qsort...
Но тут надо учесть, что вызвать std::sort для vector<bool> я считаю ГРУБОЙ ошибкой. Но она на С++ скорее всего никогда не будет выявлена, если только случайно, в то время как на С ей вообще не удастся закодировать...
P>тот же buffer overflow
Очевидно, что неверные границы буфера можно передать в оба алгоритма...
Мало того, если в С-шный передают счётчик, что даёт надежду, что он будет сортировать не всю память, а посортирует какой-то кусок и расслабится, то в С++ный передают пару итераторов. Если они будут от разных массивов, то приятной вам отладки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>уже писал. P>>вкратце: надёжность — больше ошибок(классов ошибок) ловится compile-time. E>Я не согласен что это надёжность. Или поясни, что такое compile-time? Входит ли в него время прогона статических анализаторов кода и юнит-тестов?
нет, не входят.
юнит-тесты — это во-превых runtime тесты, во-вторых их ещё необходимо написать. а например в случае sort мы получаем compile-time проверки без дополнительных усилий, и даже наоборот — его проще использовать.
статические анализаторы кода ловят далеко не все те ошибки, которые можно поймать используя типизацию и т.п.
хотя бы тупо по тому, что они могут не знать где есть ошибка, а где нет.
вот например, параметром функции является возраст, в случае с С, в каждой функции принимающей возраст нужно делать проверку. В случае C++ будет просто класс Age, и внутри функции не о чём не нужно парится. (можно даже использовать различные трюки, чтобы ловить конструкцию Age с неправильным возрастом compile time, но не об этом речь). И как тут поможет статический анализатор кода??
P>>безопасность — менее подверженность vulnerabilities. P>>но это вкратце E>Я не совсем понимаю, как qsort или std::sort могут быть опасными, тогда...
в qsort всегда нужно передавать размер массива, и элемента -> проще ошибиться и получить overflow
в std::sort конечно тоже можно ошибиться с границей, но имхо — это намного реже происходит, во вторых не нужно передавать размер элемента, и в третьих "unit-test" внутрb sort, для debug, легче добавить проверку диапазона — что и делается в некоторых реализациях.
Здравствуйте, Erop, Вы писали:
E>Если второе, то это очень неплохая иллюстрация, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА, и это его главный и основной недостаток...
ипать, вот это выводы: в одном случае компаратор tristate — в другом обычный предикат, и ты из этого делаешь вывод, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА
E>2) Про плохую и хорошую реализацию. Мы таки несём STL на помоечку или как? И то и то стандартные средства своих языков, а не поделки криворуких тенденциозных тестеров, вообще-то.
в стандартных use-case'ах sort рвёт qsort
далее, в своём же примере попробуй stable_sort
E>И авторы стандарта С++ и STL, и самого std::sort конечно же понимали, что они пессимизируют свой код примерно в два раза,
бред.
180% — это на каком компиляторе, и в каком режиме? не debug ли случайно?
и сколько выдаёт stable_sort???
E>по сравнению с С, но при этом они вынужденно пошли на это, стыдливо прикрывшись подстановкой функций обмена и сравнения E>Как ты думаешь, зачем std::sort в STL cделан тормозом?
маразм
P>>ога, или с размером массива, или с размерам типа ... E>Ну надо контролировать тип, это можно поручить статическому анализатору или макросу, а в С++ ещё и простому шаблону-обёртке.
макрос для контроля типа компаратора в студию. (либо поручение статическому анализатору)
E>>>Ещё надёжнее, будет если её немножко шаблонно обернуть P>>то есть ты согласен, что на C++ она была бы надёжней? E>Нет не согласен. На С++ писали бы как на С++ и получили бы в конце std::sort
то есть на C++ нельзя сделать сортировку, которая сортирует только массивы, принимает только указатели на компараторы, и при этом более надёжную?
E>>>В std::sort способов накрячится есть просто невообразимое множество P>>не хочу опять начинать с тобой спорить на эту тему (ты же про duck-typing, отсутствие концепций и т.п.?). P>>но, вопрос: где по-твоему мнению программисты ошибаются чаще? с qsort или sort? P>>не количество возможных путей и бла-бла, а именно на практике что надёжней. E>Я не согласен с твоим определением надёжности, но я думаю, что в готовом оттестированном коде ошибки с std::sort остаются чаще, чем с qsort...
на выделенное ответишь?
E>Но тут надо учесть, что вызвать std::sort для vector<bool> я считаю ГРУБОЙ ошибкой. Но она на С++ скорее всего никогда не будет выявлена, если только случайно, в то время как на С ей вообще не удастся закодировать...
это не ошибка
сортировка отработает с заявленной сложностью. да, константа будет большой, но во-первых никто не запрещает
сделать специализацию для vector<bool>, никто не запрещает сделать сортировку, которая принимает только обычные массивы — и при этом будет лучше qsort
P>>тот же buffer overflow E>Очевидно, что неверные границы буфера можно передать в оба алгоритма...
я это и сказал:
в std::sort конечно тоже можно ошибиться с границей,
зачем ты меня повторяешь
но имхо — это намного реже происходит
комментарии будут?
E>Мало того, если в С-шный передают счётчик, что даёт надежду, что он будет сортировать не всю память, а посортирует какой-то кусок и расслабится, то в С++ный передают пару итераторов. Если они будут от разных массивов, то приятной вам отладки
проверка итераторов делается в debug моде, во многих реализациях из каропки
E>2) Про плохую и хорошую реализацию. Мы таки несём STL на помоечку или как? И то и то стандартные средства своих языков, а не поделки криворуких тенденциозных тестеров, вообще-то. И авторы стандарта С++ и STL, и самого std::sort конечно же понимали, что они пессимизируют свой код примерно в два раза, по сравнению с С, но при этом они вынужденно пошли на это, стыдливо прикрывшись подстановкой функций обмена и сравнения
ога, ога.
замени
RandNum() : body( rand() ) {}
на
RandNum() {static int cnt=100000000; body=cnt;--cnt;}
и сравни qsort, sort и stable_sort, раз уж мы об алгоритмах заговорили и об C++way
у stable_sort почти в три раз меньше вызовов предиката чем вызовов компаратора у qsort.
и что теперь?
я жду новых чудесных выводов с твоей стороны
Здравствуйте, Erop, Вы писали:
E>Не затруднит пояснить с чем конкретно ты не согласен и почему? Ну кроме тона...
С формулировкой в стиле "первые 10 лет в тюрьме тяжело, а потом привыкнешь".
Сколько бы у тебя опыта не было — недостаток автоматики в С это никак не исправляет. С этим можно только смириться и писать всё руками.
CC>>Советовать. E>IMHO, советую как-то иначе, в иных тонах и наклонениях и т. п...
Тон бывает в устной речи. Как его углядеть в тексте —
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Т.е. ты тут упираешь на то, что алгоритмически qsort и std::sort отличаются, и у qsort в твоём случае колво вызовов компаратора меньше.
А речь шла об интерфейсе вызова.
Т.е. для правильного сравнения надо брать алгоритм qsort и модифицировать его в тот вид, в котором юзеру вытарчивает std::sort, т.е.
E>>>>>Зависит от задачи и от программиста P>>>>в каких случаях qsort, по твоему мнению, быстрее? AS>>> X(const X &x) { for( int i=0; i < x.q_.size(); ++i ) q_.push_back(x.q_[i]); } AS>>> qsort(&y[0],y.size(),sizeof(y[0]),(int(*)(const void*,const void*))X_sum_comp); P>>шутник, UB'шник
Ну вот, опять догматы... таки не готов ты пока смотреть за шоры. ))) Всего осталного ты не заметил?
P>
P>bool operator < (const X& a, const X &b){
P>void swap(X &l,X &r){
P>
P>и sort рвёт qsort, и при том без UB
Вот прямо рвёт? ))) Может таки работает с статистически незначительной разницей, особенно с учётом что там разные алгоритмы? Или сливает, если программист забыл или сделал ОДНУ опечатку. Однако очень надёжно и безопастно. )))
Здравствуйте, Alexéy Sudachén, Вы писали:
E>>>>>>Зависит от задачи и от программиста P>>>>>в каких случаях qsort, по твоему мнению, быстрее? AS>>>> X(const X &x) { for( int i=0; i < x.q_.size(); ++i ) q_.push_back(x.q_[i]); } AS>>>> qsort(&y[0],y.size(),sizeof(y[0]),(int(*)(const void*,const void*))X_sum_comp); P>>>шутник, UB'шник AS>Ну вот, опять догматы...
какие догматы — насколько я помню побитовое копирование non-POD — UB, но могу ошибаться
AS>таки не готов ты пока смотреть за шоры. ))) Всего осталного ты не заметил?
чего? отсутствие "&" ? заметил, отчасти поэтому и сделал отдельный operator<
P>>
P>>bool operator < (const X& a, const X &b){
P>>void swap(X &l,X &r){
P>>
P>>и sort рвёт qsort, и при том без UB AS>Вот прямо рвёт? ))) Может таки работает с статистически незначительной разницей, особенно с учётом что там разные алгоритмы?
это уже действительно уныло
AS>Или сливает, если программист забыл или сделал ОДНУ опечатку. Однако очень надёжно и безопастно. )))
int X_sum_comp(const X *a,const X *b) {
return N_sum(a->q_) - N_sum(b->q_);
}
CC>Т.е. ты тут упираешь на то, что алгоритмически qsort и std::sort отличаются, и у qsort в твоём случае колво вызовов компаратора меньше.
Я упираю совсем не на это.
CC>А речь шла об интерфейсе вызова.
ДА, именно об этом. ИМХО, код — истина в последней инстанции. Мне к нему вобщем-то добавить нечего. Скушно это, каждую закорючку обьеснять, всё равно что обьяснять шутки ))))
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>это уже действительно уныло P>>перепутал "-" на "+" и "шеф, усё пропало" AS>Что ты там говорл про кнопку бачка?
просто это:
AS>Вот прямо рвёт? ))) Может таки работает с статистически незначительной разницей, особенно с учётом что там разные алгоритмы?
действительно уныло, так как я здесь ни раз говорил "при одинаковых алгоритмах"
AS>>>Вот прямо рвёт? ))) Может таки работает с статистически незначительной разницей, особенно с учётом что там разные алгоритмы?
P>>действительно уныло, так как я здесь ни раз говорил "при одинаковых алгоритмах" AS>Именно это я и уточнил. Уточнил что мы говорим о языке а не о алгоритмике. AS>Так что свою унылость ты можешь отнести к тому же бачку.
AS>>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
P>ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.
P>>>>Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort
1>>>Ну я то тут причем? Это вы ведь приводите исследование их сравнивающее. Причем уже во второй раз. На Си там быстрая сортировка.
P>>я согласен, просто сравнение скорости std::sort и qsort из какой-нибудь реализации не полностью честно.
P>>Но, идея в том, что если взять одинаковые алгоритмы, один из которых обвернуть в qsort, другой в std::sort, std::sort будет быстрее.
1>Но это си. Здесь нельзя ничего обернуть не получив проигрыша в скорости. Но если взять одинаковые алгоритмы, хорошо написанные, то 1>скорость либо будет одинаковой либо у С больше.
AS>>>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
P>>ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.
Ну, то есть ты не понимаешь что специфика конструкторов, операторов и ограничений на обработку исключений к алгоритму сортировки не относится, но влияет на скорость и валидность? И никакая 'типа надёжность' тебя не спасёт от тривиальной опечатки или забывчивости. Ровно так же как и в С. По корке же вся эта магия только усложнит поиск проблемы. Я тебе написал пример, и что? Всё что ты увидел это UB, которого в С, с которым мы сравниваем, просто нет. Увидел что можно дописать пару заклинаний... вот только самого примера ты не увидел.
Когда скорость и корректность работы строчки кода зависит от наличия/отсутствия в области видимости неких заклинаний... это нечто, да. )))
AS>>>>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
P>>>ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.
AS>Ну, то есть ты не понимаешь что специфика конструкторов, операторов и ограничений на обработку исключений к алгоритму сортировки не относится, но влияет на скорость и валидность?
что ты хочешь сказать?
AS>И никакая 'типа надёжность' тебя не спасёт от тривиальной опечатки или забывчивости.
спасёт, но не от всего
AS>Ровно так же как и в С. По корке же вся эта магия только усложнит поиск проблемы. Я тебе написал пример, и что? Всё что ты увидел это UB, которого в С, с которым мы сравниваем, просто нет.
так там нет и конструкторов , которые в твоей структуре были
а что, я ещё должен был увидеть? опечатки с сылками? да, я их сразу увидел, хочешь верь, хочешь нет
AS>Увидел что можно дописать пару заклинаний... вот только самого примера ты не увидел.
примера опечаток? или чего?
AS>Когда скорость и корректность работы строчки кода зависит от наличия/отсутствия в области видимости неких заклинаний... это нечто, да. )))
во-первых — можно потребовать реализацию "заклинаний", убрав дефолтовые.
во-вторых можно потребовать, чтобы были конкретные сигнатуры
но, к дискуссии имеет мало отношения 
