Здравствуйте, Piko, Вы писали:
AS>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих. P>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++)
Тем что это не даёт возможности решать задачу в терминах С. Недоступны принципиальные возможности, дико порицаемые адептами двух плюсов. Если вы сможете компилировать свой C код C++ компилятором, то вам просто кажется что вы пишете на С, но на самом деле лишь на подмножестве С++.
Ну и самое важное, человек будет писать на кастрированном С++! Чётко понимать это и постоянно донимать работодателя на тему разрешить от эту и от эту фишку С++, что в конечном случае приведёт к тому к чему всегда приводит — вместо решения задачи, будет решаться задача как это правильно сделать на С++. Иначе говоря люди будут вместо работы заниматься синтаксическим онанизмом, результат которого для понимания будет требовать ещё большей квалификации чем та которая была у аФФтАра.
ИМХО, но страус просто неАсилил научится писать на С )))
AS>>То что вы чего-то не видите или не соображаете, означает ровно то что означает. Как сделать я уже не раз писал. P>если вам трудно описать как вы используете автоматическое управление ресурсами на C и исключения, хотя бы в паре предложений, я не вижу смысла продолжения моего общения с вами
Дык, сделайте усилие, небольшое такое, гляньте хотя бы в избранное что ли. На КЫВТ'е все такие гордые, что даже брезгают посмотреть чего до этого писал их собеседник. ))) То что вы смысла не видите, дык енто дело сугубо ваше. Неужто вы думаете, меня сколь бы то ни было расстроит, что вы сужаете своё восприятие действительности?!
P.S.
Я сюда не для просвещения страждущих хожу, мне сие с некоторого момента сугубо фиолетово, но троллинга и флуда ради. Короче, поразвлекаться.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих. P>>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++) AS>Тем что это не даёт возможности решать задачу в терминах С.
[...]
это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...
Dr. Memory version 1.4.0 build 1 built on Jan 3 2012 23:51:15
Application cmdline: ""C:\Projects\12\1.exe" "1.c""
Recorded 32 suppression(s) from default c:\visus\drm/bin/suppress-default.txt
DUPLICATE ERROR COUNTS:
SUPPRESSIONS USED:
NO ERRORS FOUND:
0 unique, 0 total unaddressable access(es)
0 unique, 0 total uninitialized access(es)
0 unique, 0 total invalid heap argument(s)
0 unique, 0 total warning(s)
0 unique, 0 total, 0 byte(s) of leak(s)
0 unique, 0 total, 0 byte(s) of possible leak(s)
ERRORS IGNORED:
153 still-reachable allocation(s)
(re-run with "-show_reachable" for details)
P>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих. P>>>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++) AS>>Тем что это не даёт возможности решать задачу в терминах С. P>[...]
P>это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...
Хм, ... ладно, не буду писать что хотел, всё таки публичное место, забанят ещё ))) Однако я не телепат, шоб значит определить что вопрос не вопрос, а цитата, што бы показать что типа что-то знаешь, но не совсем ... и сделать отсюда далеко идущие выводы )))
Пожалуй надо сделать так, шоб в телепатов не играть: P>>>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++)
Этот кастрированный С хуже чем кастрированный С++, на котором по своей природной доброте предлагают писать всем 'неАсилившим нормальный С++', адепты двух плюсов. А вот нет такого (комфортного) подмножества. Его придумали С++ программисты, чтобы считать что они умеют писать на С, ведь С++ включает его в себя, не правда ли. Ну с мелкими оговорками, которые право дело, совершенно не важны.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих. P>>>>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++) AS>>>Тем что это не даёт возможности решать задачу в терминах С. P>>[...]
P>>это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...
AS>Хм, ... ладно, не буду писать что хотел, всё таки публичное место, забанят ещё ))) Однако я не телепат, шоб значит определить что вопрос не вопрос, а цитата, што бы показать что типа что-то знаешь, но не совсем ... и сделать отсюда далеко идущие выводы )))
специально для не телепатов, я сделал ссылку , и вставил как цитату в тэг q
Здравствуйте, Piko, Вы писали:
P>специально для не телепатов, я сделал ссылку , и вставил как цитату в тэг q
Классно, тогда для не телепатов, продолжи свою мысль. Что ты хотел сказать этой цитатой? Потому как мне как не телепату, это видится в единственно возможной аналогии 'небо синее, вода мокрая'. В совокупности с советом всегда писать на С++, это ровным счётом ничего нового не говорит. Не телепатам )
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>специально для не телепатов, я сделал ссылку , и вставил как цитату в тэг q
AS>Классно, тогда для не телепатов, продолжи свою мысль. Что ты хотел сказать этой цитатой? Потому как мне как не телепату, это видится в единственно возможной аналогии 'небо синее, вода мокрая'. В совокупности с советом всегда писать на С++, это ровным счётом ничего нового не говорит. Не телепатам )
ну вообще история следующая, по мне так всё должно быть понятно.
AS>>>>>>И да, на С, но с исключениями, автоматическим управлением ресурсами и объектной моделью. С++ для всего этого не особенно и не нужен.
P>>>>>Я не совсем понял, вы используете подмножество C++ ? P>>>>> Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.
AS>>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих.
P>>>http://www.rsdn.ru/forum/cpp/4730917.1.aspx
P>>> [quote tag] P>>>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++) P>>>[/quote tag]
AS>>Тем что это не даёт возможности решать задачу в терминах С. Недоступны принципиальные возможности, дико порицаемые адептами двух плюсов. Если вы сможете компилировать свой C код C++ компилятором, то вам просто кажется что вы пишете на С, но на самом деле лишь на подмножестве С++. AS>> [...] ИМХО, но страус просто неАсилил научится писать на С )))
P> это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...
P>>>>>>Я не совсем понял, вы используете подмножество C++ ? P>>>>>> Или просто C? AS>>>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих. P>> это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...
Молодец, ткнул. Возьми конфетку )))
С примером, в котором очевидно где 'видно что безопасней и легче', когда тыкать будешь?! А то мне прям как-то интересно даже. Чувствую во мне тролль просыпается и жрать хочет. Надо ещё наверное C-стайл пример с сортировкой привести, шоб ваще весело стало )))) Хотя не, давай сначала с управлением ресурсами разберёмся.
Здравствуйте, 11molniev, Вы писали:
P>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего.
а где в C++ их можно получить по дефолту, да так чтобы не знать об этом?
я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable
P>>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы. 1>Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей.
надо попробовать в эту ручную сортировку привести к интерфейсу std::sort, может разность в скорости обуславливается разными алгоритмами?
1>Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать. 1>Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода.
ну да, на С можно сделать тоже самое, но кода почти всегда будет больше. И вот этот дополнительный код на C, который автоматом генерируется на C++, зачастую и не пишется.
1>>>std::sort будет медленней алгоритма сортировки для double*.
P>>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort? P>>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется. 1>Да нет же. И шаблоны я знаю. 1>>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном. P>>вы имеете ввиду использование специальных алгоритмов, для специальных случаев? 1>Нет.
я просто пытался понять, что вы имели ввиду...
1>>>Если хотите скину код, состряпанный на скорую руку.
P>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>http://ideone.com/iL6Gb 1>На скорую рука, так что не очень, но общий подход иллюстрирует.
1>>>Для qsort кстати функция сравнения не инлайница P>>браво 1>Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить.
да, именно, не инлайница/indirect call это основные факты почему быстрее..
P>>>>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции. 1>>>ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
P>>вот буквально за 10 секунд увидел: P>>Я правильно понимаю, если это сфейлится 1>>> RETNULL( p = memalloc( ... ) ); P>>то это 1>>> LeaveCriticalSection(&cs); P>>не вызовется? 1>Да. Её следовало вынести за ret.
с указателями конечно немного легче тем, что free ничего не делает для для нулевых указателей.
Но вот чтобы вы сделали если бы было 3 совершенно абстрактных ресурса? Делали бы 3 метки?
1>И? Померились?
?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей...
P>>причём try, может быть намного выше в call hierarchy, когда в C надо сравнивать код всё время. 1>И ещё чаще его там в итоге не будет для выбрасываемого типа исключения)))
catch(std::exception const& e){}
catch(...){}
P>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов.
легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов.
безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов.
вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable
Сама концепция объекта как черного ящика их предполагает.
P>>>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы. 1>>Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей. P>надо попробовать в эту ручную сортировку привести к интерфейсу std::sort, может разность в скорости обуславливается разными алгоритмами?
Разница обусловлена только тем, что std::sort будучи функцией с большей функциональностью (в плане данных над которыми она применяется) за эту функциональность платит скоростью. Более общее решение всегда медленней частного.
Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность. Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер).
1>>Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать. 1>>Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода. P>ну да, на С можно сделать тоже самое, но кода почти всегда будет больше. И вот этот дополнительный код на C, который автоматом генерируется на C++, зачастую и не пишется.
Да вы правы. Но у меня сложилась мнение, что вы считаете это только недостатком. Я же полагаю, что иногда это недостаток, а иногда достоинство.
1>>>>std::sort будет медленней алгоритма сортировки для double*.
P>>>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort? P>>>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется. 1>>Да нет же. И шаблоны я знаю. 1>>>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном. P>>>вы имеете ввиду использование специальных алгоритмов, для специальных случаев? 1>>Нет. P>я просто пытался понять, что вы имели ввиду...
В коде образец. Я постараюсь объяснить, если вы сформулируете вопрос.
1>>>>Если хотите скину код, состряпанный на скорую руку. P>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>http://ideone.com/iL6Gb 1>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>http://pastebin.com/QXPU0zWC P>test_c2 и test_cplusplus3 по скорости примерно одинаковы.
На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199
На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20
т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы.
Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6.
1>>>>Для qsort кстати функция сравнения не инлайница P>>>браво 1>>Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить. P>да, именно, не инлайница/indirect call это основные факты почему быстрее..
Но неинлайница, потому как qsort — функция "обобщенная". И по факту в коде она не используется. Ну как wchar_t под unix. Наверное самая близкая аналогия.
P>>>>>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции. 1>>>>ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
P>>>вот буквально за 10 секунд увидел: P>>>Я правильно понимаю, если это сфейлится 1>>>> RETNULL( p = memalloc( ... ) ); P>>>то это 1>>>> LeaveCriticalSection(&cs); P>>>не вызовется? 1>>Да. Её следовало вынести за ret. P>с указателями конечно немного легче тем, что free ничего не делает для для нулевых указателей. P>Но вот чтобы вы сделали если бы было 3 совершенно абстрактных ресурса? Делали бы 3 метки?
Нет, никогда. Обращаю внимание на макросы — в них забита одна ret. В том то и смысл, что есть инициализатор. Если бы free и CloseHandle не делали этого по умолчанию сами, это выгладило бы как:
if (p) free(p);
if (INVALID_CLOSE_HANDLE != h) CloseHandle(h);
Но обычно в этом нет необходимости.
1>>И? Померились? P>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей...
Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. Особенно если классы выносить из описания)). Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают.
Я кстати как то не обращал внимания на такой способ захвата объектов синхронизации, так что спасибо за ваш пример.
P>>>причём try, может быть намного выше в call hierarchy, когда в C надо сравнивать код всё время. 1>>И ещё чаще его там в итоге не будет для выбрасываемого типа исключения))) P>catch(std::exception const& e){} P>catch(...){}
Это то да. Просто некоторые "программисты" как то не удосуживаются об этом задумываться. Пихают везде буст, а исключения его нигде не ловят. Но это разуметься не в коей мере не относиться к языку.
P>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов.
P>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов.
P>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее.
Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней.
Это безусловно довольно субъективный подход — но согласитесь, у разных людей разные вкусы. Кому то нравиться одно, кому то другое. Поэтому людям которые предпочитают чистый Си с вами согласиться тяжело — для них меньше кода отнюдь не значит безопасней и стопроцентно не значит легче.
Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом.
Здравствуйте, 11molniev, Вы писали:
P>>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable 1>Сама концепция объекта как черного ящика их предполагает.
поясните что именно вы имеете ввиду, в данном контексте
P>>>>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы. 1>>>Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей. P>>надо попробовать в эту ручную сортировку привести к интерфейсу std::sort, может разность в скорости обуславливается разными алгоритмами? 1>Разница обусловлена только тем, что std::sort будучи функцией с большей функциональностью (в плане данных над которыми она применяется) за эту функциональность платит скоростью. Более общее решение всегда медленней частного.
Вы видели
template <class RandomAccessIterator>
void qSortIT(RandomAccessIterator first, RandomAccessIterator last)
?
как сильно оно отличается по функциональности от std::sort?
Может всё-таки дело в разных алгоритмах? std::sort это ведь не обязательно quicksort
1>Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность.
нет. при использовании шаблонов, при определении специализаций для небольших особенностей, при определении алгоритмов которые принимают сущности с большим набором небольших особенностей, полный код алгоритма учитывающий каждую особенность сгенерируется автоматом, и будет он не медленней, а то и быстрее legacy C, так как вручную все эти особенности учесть на несколько порядков труднее.
1>Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер).
это тоже заблуждение, компиляторы сейчас обладают большими знаниями в оптимизации, чем люди.
если речь идёт о расширениях типа sse — то во-первых, сейчас компиляторы умеют делать автовекторизацию, во-вторых если всё-же придётся использовать sse вручную, то это будет не asm, а intrinsic, и в-третьих эти intrinsic при грамотном дизайне не будут разбросаны по всему проекту, а будут аккуратно обвёрнуты в маленькие абстракции.
Пример, http://eigen.tuxfamily.org/index.php?title=Main_Page — см раздел "Eigen is fast"
Тесты: http://eigen.tuxfamily.org/index.php?title=Benchmark как видите, Eigen уделывает legacy код на многих участках.
Так что миф об legacy speed — это миф.
1>>>Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать. 1>>>Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода. P>>ну да, на С можно сделать тоже самое, но кода почти всегда будет больше. И вот этот дополнительный код на C, который автоматом генерируется на C++, зачастую и не пишется. 1>Да вы правы. Но у меня сложилась мнение, что вы считаете это только недостатком. Я же полагаю, что иногда это недостаток, а иногда достоинство.
Почему достоинство?
Перед чем достоинство? — на C++ возможны оба подхода, а на C по большому счёту только один
1>>>>>std::sort будет медленней алгоритма сортировки для double*. P>>>>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort? P>>>>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется. 1>>>Да нет же. И шаблоны я знаю. 1>>>>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном. P>>>>вы имеете ввиду использование специальных алгоритмов, для специальных случаев? 1>>>Нет. P>>я просто пытался понять, что вы имели ввиду... 1>В коде образец. Я постараюсь объяснить, если вы сформулируете вопрос.
Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort
1>>>>>Если хотите скину код, состряпанный на скорую руку. P>>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>>http://ideone.com/iL6Gb 1>>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>>http://pastebin.com/QXPU0zWC P>>test_c2 и test_cplusplus3 по скорости примерно одинаковы. 1>На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199 1>На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20 1>т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы. 1>Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6.
Вы видели test_cplusplus3 ????? У вас там есть разница в скорости?
Кстати, сравнивать сортировку на разных наборах случайных данных не корректно, на определённых данных quicksort вообще может взрываться до N^2.
1>>>>>Для qsort кстати функция сравнения не инлайница P>>>>браво 1>>>Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить. P>>да, именно, не инлайница/indirect call это основные факты почему быстрее.. 1>Но неинлайница, потому как qsort — функция "обобщенная". И по факту в коде она не используется. Ну как wchar_t под unix. Наверное самая близкая аналогия.
ну std::sort ведь тоже обобщённая, и при этом всё инлайнится
1>>>И? Померились? P>>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей... 1>Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах.
я думаю при создании функции с 10 ресурсами, как минимум большинство программистов сделает ошибку, а то и не одну.
Зачем вообще надрываться и использовать C, когда есть C++? (естественно, кроме тех случаев когда использование C++ невозможно из-за отсутствия компилятора)
1>Особенно если классы выносить из описания)).
ну так в этом и смысл, в C++ управление ресурсом можно сделать один раз, и потом использовать многократно. В C такое вынесение практически не возможно (многоэтажные макросы не в счёт), и приходится постоянно тратить время на контроль ресурсов
1>Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают.
далеко не все это понимают.
помимо компактности — это ещё и безопасность и надёжность.
1>Я кстати как то не обращал внимания на такой способ захвата объектов синхронизации, так что спасибо за ваш пример.
рад что вам это пригодится. это касается любых ресурсов.
P>>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов. P>>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее. 1>Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней.
да, язык больше, я не спорю.
но посмотрите на это с другой стороны: какая-либо возможность языка учится один раз, а потом используется многократно, если нет этой возможности то пришлось бы постоянно писать однотипный код.
1>Это безусловно довольно субъективный подход — но согласитесь, у разных людей разные вкусы. Кому то нравиться одно, кому то другое. Поэтому людям которые предпочитают чистый Си с вами согласиться тяжело — для них меньше кода отнюдь не значит безопасней и стопроцентно не значит легче.
не, я не спорю, у людей может быть субъективное, ошибочное мнение
1>Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом.
Тут проблема в образовании, многие начинают учить C++ начиная с legacy C, приобретают вредные привычки, и часто далеко не выходят за пределы legacy C. Прочитайте статью http://www2.research.att.com/~bs/new_learning.pdf — мне понравилось.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>С примером, в котором очевидно где 'видно что безопасней и легче', когда тыкать будешь?!
я уже привёл пример с тремя ресурсами.
AS>А то мне прям как-то интересно даже. Чувствую во мне тролль просыпается и жрать хочет.
сейчас будет рок-н-ролл
AS>Надо ещё наверное C-стайл пример с сортировкой привести, шоб ваще весело стало )))) Хотя не, давай сначала с управлением ресурсами разберёмся.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
AS>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.
Синтаксический онанизм говоришь? методы высокой магии? прорицание в пространствах синтаксических подсластителей? серьёзное упрощение кода?
ну-ну :
#define __Auto_Release \
switch ( 0 ) \
if ( 0 ); else \
while ( 1 ) \
if ( 1 ) \
{ \
int YOYO_LOCAL_ID(Mark); \
Yo_Unwind_Scope(0,0,&YOYO_LOCAL_ID(Mark)); \
break; \
case 0: Yo_Pool_Ptr(&YOYO_LOCAL_ID(Mark),Yo_Pool_Marker_Tag); \
goto YOYO_LOCAL_ID(Body);\
} \
else \
YOYO_LOCAL_ID(Body):
Здравствуйте, MasterZiv, Вы писали:
MZ>On 05/10/2012 07:41 PM, org_256 wrote:
>> P>Так что быстрее? std::sort (C++ style) vs qsort (C-style) ? >> Они идентичны, если речь идёт о стандарте, Если не стандарт, то некоторые >> реализации qsort сливают.
MZ>Как бы ты не прав. Они НЕ идентичны. С++ный шаблоный код потенциально MZ>быстрее, т.к. там возможно встраивание кода функции сравнения, и MZ>прочие оптимизации, отсюда вытекающие. Также С++ный код знает MZ>ТИП массива, а С-шный -- не знает. Тоже могут быть оптимизации.
MZ>Конечно, С-шный код в принципе тоже может это соптимизнуть, MZ>но только это должен быть ОЧЕНЬ умный компилятор.
>> При этом std::sort в ряде реализаций был с косяками...
MZ>Ну, это проблема не языка, а конкретной реализации. MZ>Но я лично такого не слышал никогда.
Я позволил себе объединить часть суждений, а то их стало слишком много.
P>>>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>>>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>>>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable 1>>Сама концепция объекта как черного ящика их предполагает. P>поясните что именно вы имеете ввиду, в данном контексте
То что сама концепция ООП с классами как черными ящиками подразумевает неизвестность будут тормоза или нет. Это "детали скрытые конкретной реализацией". Одновременно и ирония и правда.
P>>>>>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы. 1>>>>Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей. P>>>надо попробовать в эту ручную сортировку привести к интерфейсу std::sort, может разность в скорости обуславливается разными алгоритмами? 1>>Разница обусловлена только тем, что std::sort будучи функцией с большей функциональностью (в плане данных над которыми она применяется) за эту функциональность платит скоростью. Более общее решение всегда медленней частного. P>Вы видели P>template <class RandomAccessIterator> P>void qSortIT(RandomAccessIterator first, RandomAccessIterator last) P>? P>как сильно оно отличается по функциональности от std::sort? P>Может всё-таки дело в разных алгоритмах? std::sort это ведь не обязательно quicksort
Ниже. В самом конце.
1>>Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность. P>нет. при использовании шаблонов, при определении специализаций для небольших особенностей, при определении алгоритмов которые принимают сущности с большим набором небольших особенностей, полный код алгоритма учитывающий каждую особенность сгенерируется автоматом, и будет он не медленней, а то и быстрее legacy C, так как вручную все эти особенности учесть на несколько порядков труднее.
Практический пример в коде. Если вы ознакомитесь с дизассемблерным листингом — то все эти вопросы исчезнут. 1>>Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер). P>это тоже заблуждение, компиляторы сейчас обладают большими знаниями в оптимизации, чем люди. P>если речь идёт о расширениях типа sse — то во-первых, сейчас компиляторы умеют делать автовекторизацию, во-вторых если всё-же придётся использовать sse вручную, то это будет не asm, а intrinsic, и в-третьих эти intrinsic при грамотном дизайне не будут разбросаны по всему проекту, а будут аккуратно обвёрнуты в маленькие абстракции. P>Пример, http://eigen.tuxfamily.org/index.php?title=Main_Page — см раздел "Eigen is fast" P>Тесты: http://eigen.tuxfamily.org/index.php?title=Benchmark как видите, Eigen уделывает legacy код на многих участках. P>Так что миф об legacy speed — это миф.
Тесты аудио/видеодекодеров с вами не согласны. Сравнение скорости крипто алгоритмов тоже. Как раз таки тесты не показатель — их можно подогнать под что угодно.
Ну а насчет мифа — достаточно взглянуть во внутренности математических библиотек Intel'а, чтобы убедиться, как глубоко заблуждаются инженеры этой компании. Люди умней компиляторов.
1>>>>Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать. 1>>>>Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода. P>>>ну да, на С можно сделать тоже самое, но кода почти всегда будет больше. И вот этот дополнительный код на C, который автоматом генерируется на C++, зачастую и не пишется. 1>>Да вы правы. Но у меня сложилась мнение, что вы считаете это только недостатком. Я же полагаю, что иногда это недостаток, а иногда достоинство. P>Почему достоинство? P>Перед чем достоинство? — на C++ возможны оба подхода, а на C по большому счёту только один
В С++ есть один правильный подход и возможность пользоваться неправильным. Но Неправильный подход — это и есть С.
1>>>>>>std::sort будет медленней алгоритма сортировки для double*. P>>>>>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort? P>>>>>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется. 1>>>>Да нет же. И шаблоны я знаю. 1>>>>>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном. P>>>>>вы имеете ввиду использование специальных алгоритмов, для специальных случаев? 1>>>>Нет. P>>>я просто пытался понять, что вы имели ввиду... 1>>В коде образец. Я постараюсь объяснить, если вы сформулируете вопрос. P>Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort
Ну я то тут причем? Это вы ведь приводите исследование их сравнивающее. Причем уже во второй раз. На Си там быстрая сортировка.
1>>>>>>Если хотите скину код, состряпанный на скорую руку. P>>>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>>>http://ideone.com/iL6Gb 1>>>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>>>http://pastebin.com/QXPU0zWC P>>>test_c2 и test_cplusplus3 по скорости примерно одинаковы. 1>>На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199 1>>На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20 1>>т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы. 1>>Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6. P>Вы видели test_cplusplus3 ????? У вас там есть разница в скорости?
Опечатался. Разумеется просто "test_cplusplus". Разница в скорости есть, код у вас есть — можите сравнить. P>Кстати, сравнивать сортировку на разных наборах случайных данных не корректно, на определённых данных quicksort вообще может взрываться до N^2.
Но quicksort там это Си. Что на С++ как вы сами сказали — неизвестно. И что значит случайные сравнивать некорректно — да есть алгоритмы, работающие быстрей при увеличении степени упорядоченности. Но сортировка предназначенная для упорядочивания не упорядоченного массива в том числе и случайных данных (пусть это и худший случай). На чем её ещё тестировать — на возрастающем массиве? Впрочем я не имею ничего против, если вы поменяете способ наполнения массива и скинете код.
1>>>>>>Для qsort кстати функция сравнения не инлайница P>>>>>браво 1>>>>Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить. P>>>да, именно, не инлайница/indirect call это основные факты почему быстрее.. 1>>Но неинлайница, потому как qsort — функция "обобщенная". И по факту в коде она не используется. Ну как wchar_t под unix. Наверное самая близкая аналогия. P>ну std::sort ведь тоже обобщённая, и при этом всё инлайнится
Я взял в кавычки слово обобщенная, потому, что обобщенная в С++ — это объявленная через шаблон(ы). В данном случа я имел в виду, предназначенная под любые типы данных.
1>>>>И? Померились? P>>>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей... 1>>Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. P>я думаю при создании функции с 10 ресурсами, как минимум большинство программистов сделает ошибку, а то и не одну. P>Зачем вообще надрываться и использовать C, когда есть C++? (естественно, кроме тех случаев когда использование C++ невозможно из-за отсутствия компилятора)
Как минимум у разных людей разные предпочтения. Ну действительно — зачем надрываться и сажать картошку, если можно есть саранчу, которая сама вырастит.
1>>Особенно если классы выносить из описания)). P>ну так в этом и смысл, в C++ управление ресурсом можно сделать один раз, и потом использовать многократно. В C такое вынесение практически не возможно (многоэтажные макросы не в счёт), и приходится постоянно тратить время на контроль ресурсов
В си управление ресурсом выноситься в соответствующею ресурсу функцию. Больше кода получается, потому как эту функцию надо вызвать руками и проверить результат её вызова. В итоге вместо одной строчки на С++ для объявления и одновременной инициализации мы получаем две. Для объявления, инициализации и проверки (две операции из этих операций логично объединить в одну).
1>>Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают. P>далеко не все это понимают. P>помимо компактности — это ещё и безопасность и надёжность.
Я об этом уже написал. Печально, что вы не захотели понять, что кто то может иметь точку зрения отличающеюся от вашей и пытаетесь убедить других в своей точке зрения.
1>>Я кстати как то не обращал внимания на такой способ захвата объектов синхронизации, так что спасибо за ваш пример. P>рад что вам это пригодится. это касается любых ресурсов.
P>>>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>>>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов. P>>>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее. 1>>Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней. P>да, язык больше, я не спорю. P>но посмотрите на это с другой стороны: какая-либо возможность языка учится один раз, а потом используется многократно, если нет этой возможности то пришлось бы постоянно писать однотипный код.
И при этом не все сопутствующие последствия человек удерживает в голове. Это как раз одна из причин, по которой люди иногда предпочитают чистый С.
1>>Это безусловно довольно субъективный подход — но согласитесь, у разных людей разные вкусы. Кому то нравиться одно, кому то другое. Поэтому людям которые предпочитают чистый Си с вами согласиться тяжело — для них меньше кода отнюдь не значит безопасней и стопроцентно не значит легче. P>не, я не спорю, у людей может быть субъективное, ошибочное мнение
Ну я сомневаюсь, что есть идеальные люди с объективным и единственно верным мнением. Хотя это конечно немного самоуверенно)) 1>>Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом. P>Тут проблема в образовании, многие начинают учить C++ начиная с legacy C, приобретают вредные привычки, и часто далеко не выходят за пределы legacy C. Прочитайте статью http://www2.research.att.com/~bs/new_learning.pdf — мне понравилось.
Тут проблема в том что С проще и его проще учить. Ну или по крайней мере так полагает большинство авторов.
Насчет статьи:
Я не перепечатывал код полностью — но пример данный мной в прошлом сообщении взят именно из этой статьи. И он хорошо показывает, что статья не в полне объективна. Она показывает выигрыш С++ в скорости над С. Но написав сишный код чуть-чуть подругому мы получаем диаметрально противоположный результат. Мне очень не нравиться попытка сравнить std::sort и qsort. Как я уже сказал, qsort — это нечто вроде wchar_t под unix. Да она есть — но ей в большинстве случаев не пользуются. И она априорно медленней std::sort — что там можно сравнивать, тестировать и как на основе этого теста можно говорить, что С++ быстрей. И утверждение, что более высокий уровень абстракции и защиты от ошибок при этом дает увеличение скорости не лезет ни в какие ворота.
Здравствуйте, 11molniev, Вы писали:
P>>>>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>>>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>>>>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>>>>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable 1>>>Сама концепция объекта как черного ящика их предполагает. P>>поясните что именно вы имеете ввиду, в данном контексте 1>То что сама концепция ООП с классами как черными ящиками подразумевает неизвестность будут тормоза или нет. Это "детали скрытые конкретной реализацией". Одновременно и ирония и правда.
тоже самое можно сказать о функции — вот смотришь на декларацию — и не поймёшь — будут тормоза или нет.
1>>>Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность. P>>нет. при использовании шаблонов, при определении специализаций для небольших особенностей, при определении алгоритмов которые принимают сущности с большим набором небольших особенностей, полный код алгоритма учитывающий каждую особенность сгенерируется автоматом, и будет он не медленней, а то и быстрее legacy C, так как вручную все эти особенности учесть на несколько порядков труднее. 1>Практический пример в коде. Если вы ознакомитесь с дизассемблерным листингом — то все эти вопросы исчезнут. 1>>>Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер). P>>это тоже заблуждение, компиляторы сейчас обладают большими знаниями в оптимизации, чем люди. P>>если речь идёт о расширениях типа sse — то во-первых, сейчас компиляторы умеют делать автовекторизацию, во-вторых если всё-же придётся использовать sse вручную, то это будет не asm, а intrinsic, и в-третьих эти intrinsic при грамотном дизайне не будут разбросаны по всему проекту, а будут аккуратно обвёрнуты в маленькие абстракции. P>>Пример, http://eigen.tuxfamily.org/index.php?title=Main_Page — см раздел "Eigen is fast" P>>Тесты: http://eigen.tuxfamily.org/index.php?title=Benchmark как видите, Eigen уделывает legacy код на многих участках. P>>Так что миф об legacy speed — это миф. 1>Тесты аудио/видеодекодеров с вами не согласны. Сравнение скорости крипто алгоритмов тоже.
какие именно тесты?
что там сравнивается? быстрая реализация на C versus плохая C++ реализация?
1>Как раз таки тесты не показатель — их можно подогнать под что угодно.
Вы посмотрите что сравнивается на графиках: вылизанные реализации типа GOTO2, INTEL_MKL, versus Eigen. Разве это не честно? Или вы сомневаетесь в чистоте тестов?
1>Ну а насчет мифа — достаточно взглянуть во внутренности математических библиотек Intel'а, чтобы убедиться, как глубоко заблуждаются инженеры этой компании.
какие именно библиотеки вы имеете ввиду?
И какие там внутренности? Разве ассемблер?
1>Люди умней компиляторов.
на счёт этого я не спорю.
Компиляторы могут обработать намного большие объёмы информации чем люди, они знают намного больше об процессорах, pipelines и т.п.
Простое переписывание вручную на ассемблер ничего не даст, а зачастую наоборот замедлит.
Многие верят в миф, что просто ручное написание на ассемблере даст ускорение — это bullshit. Простого переписывания не достаточно для обгона компилятора.
P>>Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort 1>Ну я то тут причем? Это вы ведь приводите исследование их сравнивающее. Причем уже во второй раз. На Си там быстрая сортировка.
я согласен, просто сравнение скорости std::sort и qsort из какой-нибудь реализации не полностью честно.
Но, идея в том, что если взять одинаковые алгоритмы, один из которых обвернуть в qsort, другой в std::sort, std::sort будет быстрее.
1>>>>>>>Если хотите скину код, состряпанный на скорую руку. P>>>>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>>>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>>>>http://ideone.com/iL6Gb 1>>>>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>>>>http://pastebin.com/QXPU0zWC P>>>>test_c2 и test_cplusplus3 по скорости примерно одинаковы. 1>>>На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199 1>>>На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20 1>>>т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы. 1>>>Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6. P>>Вы видели test_cplusplus3 ????? У вас там есть разница в скорости? 1>Опечатался. Разумеется просто "test_cplusplus". Разница в скорости есть, код у вас есть — можите сравнить.
Вы видели test_cplusplus3 (цифра три на конце) ? выделенная жирным ссылка на pastebin
P>>Кстати, сравнивать сортировку на разных наборах случайных данных не корректно, на определённых данных quicksort вообще может взрываться до N^2. 1>Но quicksort там это Си. Что на С++ как вы сами сказали — неизвестно. И что значит случайные сравнивать некорректно — да есть алгоритмы, работающие быстрей при увеличении степени упорядоченности. Но сортировка предназначенная для упорядочивания не упорядоченного массива в том числе и случайных данных (пусть это и худший случай). На чем её ещё тестировать — на возрастающем массиве? Впрочем я не имею ничего против, если вы поменяете способ наполнения массива и скинете код.
Вы не поняли меня. В ваших тестах (да и в тех что я добавил, основываясь на вашем подходе), производится сравнение скорости сортировки на разных случайных наборах. А нужно делать сравнение на одинаковых, но при это всё равно случайных наборах.
1>>>>>И? Померились? P>>>>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей... 1>>>Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. P>>я думаю при создании функции с 10 ресурсами, как минимум большинство программистов сделает ошибку, а то и не одну. P>>Зачем вообще надрываться и использовать C, когда есть C++? (естественно, кроме тех случаев когда использование C++ невозможно из-за отсутствия компилятора) 1>Как минимум у разных людей разные предпочтения. Ну действительно — зачем надрываться и сажать картошку, если можно есть саранчу, которая сама вырастит.
тут я не спорю — вкусы у всех разные.
Но, зачастую "отрекание" от C++ в сторону C, происходит на основе неправильной интерпретации опыта.
1>>>Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают. P>>далеко не все это понимают. P>>помимо компактности — это ещё и безопасность и надёжность. 1>Я об этом уже написал. Печально, что вы не захотели понять, что кто то может иметь точку зрения отличающеюся от вашей и пытаетесь убедить других в своей точке зрения.
Я помню что вы писали, я понял что вы имели ввиду, но ни один coding standard, никогда не будет лучше отсутствия технической возможности ошибиться.
P>>>>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>>>>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов. P>>>>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее. 1>>>Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней. P>>да, язык больше, я не спорю. P>>но посмотрите на это с другой стороны: какая-либо возможность языка учится один раз, а потом используется многократно, если нет этой возможности то пришлось бы постоянно писать однотипный код. 1>И при этом не все сопутствующие последствия человек удерживает в голове. Это как раз одна из причин, по которой люди иногда предпочитают чистый С.
почему в этом случае не использовать тот subset C++, который понятен, и удерживается в голове?
1>>>Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом. P>>Тут проблема в образовании, многие начинают учить C++ начиная с legacy C, приобретают вредные привычки, и часто далеко не выходят за пределы legacy C. Прочитайте статью http://www2.research.att.com/~bs/new_learning.pdf — мне понравилось. 1>Тут проблема в том что С проще и его проще учить. Ну или по крайней мере так полагает большинство авторов.
в статье как раз говорится что C++ легче учить (хотя бы до определённого уровня)
1>Насчет статьи: 1>Я не перепечатывал код полностью — но пример данный мной в прошлом сообщении взят именно из этой статьи. И он хорошо показывает, что статья не в полне объективна. Она показывает выигрыш С++ в скорости над С. Но написав сишный код чуть-чуть подругому мы получаем диаметрально противоположный результат.
сравниваются две "обобщённые"(как вы сами сказали). да, алгоритмы сортировки в реализации могут быть разные, но давайте возьмём один алгоритм, ок?
Вы написали не обобщённую C версию, при этом когда я из неё сделал на C++ обобщённую — qSortIT, её скорость была не меньше скорости не обобщённой C версии — вы это увидели?
1>Мне очень не нравиться попытка сравнить std::sort и qsort. Как я уже сказал, qsort — это нечто вроде wchar_t под unix. Да она есть — но ей в большинстве случаев не пользуются. И она априорно медленней std::sort — что там можно сравнивать, тестировать и как на основе этого теста можно говорить, что С++ быстрей. И утверждение, что более высокий уровень абстракции и защиты от ошибок при этом дает увеличение скорости не лезет ни в какие ворота.
почему, по-моему как раз таки лезет.
1) есть две обощённые(в вашем понимании функции) qsort и std::sort
2) интерфейс std::sort более безопасен и менее подвержен ошибкам чем qsort
3) при равный используемых алгоритмах сортировки std::sort будет быстрее qsort
Здравствуйте, RSATom, Вы писали:
P>>А зачем вообще может понадобится использовать C, когда есть C++ ? RSA>Существуют Open Source проекты написаные на с99, иногда хочется их портировать под винду для использования в каких либо проектах. Яркий пример ffmpeg.
да, согласен, это тоже аргумент.
но естественно в большинстве случаев ни что не мешает использовать нормальную C библиотеку из C++, в остальных нужен простой переходник написанный на C.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, RSATom, Вы писали:
P>>>А зачем вообще может понадобится использовать C, когда есть C++ ? RSA>>Существуют Open Source проекты написаные на с99, иногда хочется их портировать под винду для использования в каких либо проектах. Яркий пример ffmpeg.
P>да, согласен, это тоже аргумент. P>но естественно в большинстве случаев ни что не мешает использовать нормальную C библиотеку из C++, в остальных нужен простой переходник написанный на C.
Я немного про другое — поскольку c99 проект не собрать в студии, значит придется использовать gcc для компиляции с99 кода, а gcc не умеет создавать отладочную информацию которую умеет понимать студия. и тут вариантов несколько:
1) реализовывать весь проект на gcc (ИМХО особый род мазохизма при наличии студии);
2) использовать студию для отладки/написания с++ кода и gcc/gdb для отладки с99 кода, при таком подходе отладка на стыке компиляторов превращается в достаточно увлекательный квест;
3) портирование с99 кода в с++ — квест получаем увлекательный и итеративный, т.к. нужно отрабатывать выход новых версий и bug/security фиксы.
*) другие не очень привлекательные варианты.
Здравствуйте, RSATom, Вы писали:
P>>>>А зачем вообще может понадобится использовать C, когда есть C++ ? RSA>>>Существуют Open Source проекты написаные на с99, иногда хочется их портировать под винду для использования в каких либо проектах. Яркий пример ffmpeg. P>>да, согласен, это тоже аргумент. P>>но естественно в большинстве случаев ни что не мешает использовать нормальную C библиотеку из C++, в остальных нужен простой переходник написанный на C. RSA>Я немного про другое — поскольку c99 проект не собрать в студии,
ясно. насколько я помню microsoft не стремится реализовывать "новые фишки" стандартов C, только то что пересекается с новыми фишками C++.
как сказал Страуструп — следует смёрджить C / C++ в один язык, C is obsolete
RSA>значит придется использовать gcc для компиляции с99 кода, а gcc не умеет создавать отладочную информацию которую умеет понимать студия. и тут вариантов несколько:
RSA>1) реализовывать весь проект на gcc (ИМХО особый род мазохизма при наличии студии); RSA>2) использовать студию для отладки/написания с++ кода и gcc/gdb для отладки с99 кода, при таком подходе отладка на стыке компиляторов превращается в достаточно увлекательный квест; RSA>3) портирование с99 кода в с++ — квест получаем увлекательный и итеративный, т.к. нужно отрабатывать выход новых версий и bug/security фиксы. RSA>*) другие не очень привлекательные варианты.
ещё возможные варианты (я их не тестировал, полностью не уверен):
4) Intel C вроде понимает C99, и не плохо интегрируется со студией
5) CLang/LLVM
6) автотрансляция кода с С99 в более старую версию
:
