Ще одна тема про смерть С++
Всім хто так вважає, або хоче цього — раджу почитати цю розмову: www.linkedin.com/...&trk=EML_anet_ac_pst_ttle
Всім хто так вважає, або хоче цього — раджу почитати цю розмову: www.linkedin.com/...&trk=EML_anet_ac_pst_ttle
69 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівwww.systemc.org/home
Есть альтернативы?
на удивление — живет Фортан, а вы С++ уже хоронить собрались...
Да ну? Когда похороны? :).
Может окошки и веб-странички на нем сегодня никто и не рисует, но этим сегодня область информационных технологий не ограничена. Есть более серьезные задачи и там С и С++ - само то :). Может когда С++ и умрет, но уж точно не в ближайшее десятиление, а к тому времени как он начнет умирать изменится вообще концепт программирования и другие на сегодняшний день модные языки умрут вместе с ним.
ИМХО, наиболее адекватный аргумент про смерть ЦПП — это то что для «более серьезные задачи» используют чистый Ц, а для не «более серьезные задачи» — Джава/С№/Питон
для более серьезных задач подходит именно С++, так как он давно обходит С по производительности и удобству использования...
А вот про скорость надо бы пруфлинк. Только не в стиле тех в которых Java превосходит C, то есть не синтетические.
в С++ мы можем иметь удобный (классы и подобный ОО сахар), производительный(шаблонные подстановки, статическая типизация), компактный (опять таки шаблоны) и защищенный (более строгая типизация и опять шаблоны) код... в С мы можем иметь только одно из вышеперечисленного... сами подумайте почему...
а если хотите пруф, поищите сравнение одного и того же алгоритма сортировки на С и С++ (по моему было на blog.gamedeff.com), цену вызова функций по указателю (чтоб на С было удобно, их приходится использовать, в С++ заменяется шаблоном... год назад было очень актуальной темой в англоязычном инете), ну и про сахар типа RAII, SFINAE и тп, которое на С просто невозможно, а С++ помогает вырывать лишние такты при сохранении компактности и защищенности кода (хотя иногда нужно быть 7 пядей во лбу чтоб их понимать)...
2) «пруфлинк не нужен...» — если просят, то наверно таки нужен :)
3) Если не ошибаюсь, то шаблоны — это «работают» во время компиляции, а ссылки на функции, вроде как, в рантайме, посему немного не корректное сравнение, кстати ссылочку тоже хорошо было бы дать.
1 дефайны — но у них ограничен уровень вложенности
2 копипаст — без коментариев
вот цыфры assemblyrequired.crashworks.org/...nctions-really
В С++ в большинстве случаев их можно заменить шаблоном
Пруфлинк: thread.gmane.org/...643/focus=57918
Не нужно доказывать про скорость, это просто бессмысленно.
Если имелось в виду: blog.gamedeff.com/?p=84 , то я даже бы сказал, что меня откровенно это веселит. Таким образом я могу доказать, что сортировка на bash’е быстрее С++’шной. :)
что доступ по *data++=xxx; медленнее до 14 раз чем data[i]. Компилятор перезагружает указатель при каждом обращении. Поэтому без перекомпиляции системных либ, всё бессмысленно.
А все таки, можно ли на си написать библиотеку сортировки хотябы такую же быструю как С+±сный вариант?
Конечно.
Топик долго не открывался (какие то проблемы с форумом были), поэтому задам вопрос сейчас:, а можно подсказку как это сделать?
Релизовать алгоритм полностью идентичный c++ коду.
То есть копипастить каждый раз всю реализацию скажем quicksort-a попутно правя логику сравнения элементов масива? Я правильно понимаю?
Хотя наверное можно еще макросом изловчится.
Да чего копипастить? Это нормально иметь свои реализации libc’шных функций, если они критичны ко времени выполнения. Каждый раз делать не нужно;)
По скорости с и с++ равны.
Не равны за счет наличия в С++ шаблонов.
По ссылке вверху основная гипотеза торможения сортировки в С, это то что в С++ функция сравнения элементов масива инлайнится за счет шаблонов, а в С вызвается по указателю. Вот я и вижу два способа как это обойти: копипастить каждый раз код сортировок и править внутри него код сравнения элементов массива или сделать то же самое жутким макросом, все это конечно имеет минусы в виде кривого кода, раздутого финального бинаря и увеличенного времени компиляции.
А что мешает заинлайнить функцию сравнения в C? (C99 and above). Будет так же как с темплейтом, но только для одного типа.
А можно кусок кода для более предметного обсуждения?
www.opensource.apple.com/...sd/kern/qsort.c
cmp функцию не передаём параметром в qsort, а делаём её глобальной в таком виде:
inline int cmp (const void*, const void*);
Да, для каждого типа будет свой код сортировки, это минус, но код будет по скорости такой же. А по поводу раздутия финального бинарника, при использовании темплейтов будет тоже самое...
Ок, предположим, а как это реализовать?
То есть предположим у нас есть следующие файлы:
qsort.h — содержит определения cmp и qsortqsort.c — содержит реализацию qsort
в main.c — мы хотим отсортировать масив элементов, что мы должны там написать?
qsort.c — содержит и инлайновый cmp для определённого типа и сам qsort. qsort.h — только декларацию qsort. Можно и extern inline сделать. Какие-то вопросы ты задаёшь стрёмные... как для программиста.
Читать до просветления:www.open-std.org/.../docs/n1256.pdf
Отлично, и как это поможет программисту в main.c отсортировать масив структур, которые там же и определяются?
> Какие-то вопросы ты задаёшь стрёмные... как для программиста.
Потому как ты не можешь внятно описать твой подход, все какие то полунамеки.
Напиши один и тот же алгоритм на С и на С++, как умеешь. Я тебе переделаю код на С, который ты потом можешь тестировать.
Вот мой код:
sort.h:
void sort (void *a, int n, int size, int (*cmp) (void *, void *));
sort.c:
#include<string.h>#include “sort.h”
void sort (void *a, int n, int size, int (*cmp) (void *, void *)) {char buf [size];void *p1, *p2;
for (int i = 1; i < n; i ++)
for (int j = 0; j < i; j ++) {p1 = a + j * size;
p2 = a + i * size;
if (cmp (p1, p2) > 0) {memcpy (buf, p1, size);
memcpy (p1, p2, size);
memcpy (p2, buf, size);}}}
main.c:
#include<stdio.h>#include “sort.h”
typedef struct {int x, y;} point;
int cmp (void* a, void* b) {point *ap = (point*) a;point *bp = (point*) b;
if (ap -> x! = bp -> x)
return ap -> x — bp -> x;
else
return ap -> y — bp -> y;}
int main () {int n = 10000;point t [n];
sort (&t, n, sizeof (point), &cmp);
for (int i = 0; i < n; i ++)
printf (“%d %d\n”, t [i].x, t [i].y);}
К сожалению парсер отступы поел.
pastebin.com/XxT6NTQK
1) Только ещё нужно изменить параметры cmp и sort_points функций, чтобы они сразу принимали point структуру.2) Включить работу с копированием структур средствами языка вместо вызова memcpy (). *p1=*p2;... и т. д.
Я использовал gcc 4.3.4 (cygwin). Полученный код быстр и минимален. Поэтому в свете начального вопроса мы имеем, что C быстр так же как C++. То, что он не такой гибкий как C++, это уже второй вопрос.
Здесь моя ошибка, я неправильно понял один твой коммент, и думал что ты имеешь в виду что-то другое.
Коментар порушує правила спільноти і видалений модераторами.
Основное преимущество С++ перед прочей лабудой (Java, C# и т. д.) в том, что на нем сегодня можно разрабатывать как программный код так и аппаратную платформу. Мир идет именно в этом направлении и это основной тренд развития Embedded систем, когда один человек будет делать и софт и железо. В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Частично согласен. С++ будет еще жить и жить, равно как и «прочая лабуда»).
Но, с другой стороны, называть C++ монополистом в области embedded тоже неправильно:1. мощности и возможности железа постоянно растут (даже сейчас вопросы оперативной и хард памяти уже не так акуальны)
2. создаются различные платформы, под которые можно программить на более высоком уровне по сравнению с C/asm (и я говорю не только о C++);
3. java сейчас тоже движется в сторону embedded (например, en.wikipedia.org/...irtual_machine
Кстати, уже была попытка создания ОС на java — JavaOS. Но как-то заглохло оно все. Думаю, через какое-то время к этой идее опять вернутся. Так что «все профессии нужны, все профессии важны».
2. Программить что? Если мы говорим про GUI — пожалуйста, если мы говорим про системные вещи, то зачем?
3. Она всегда там крутилась.
2. GUI само собой. А почему же системные вещи нет смысла программить на джаве? Субъективно — качесвенный код на джаве чуть удобнее мейнтейнить, чем качественный код на том же С++. По скорости да, пока что С++ круче, но через какое-то время эта разница не будет заметна вообще.
3. Да, согласен.
> А почему же системные вещи нет смысла программить на джаве? Субъективно — качесвенный код на джаве чуть удобнее мейнтейнить, чем качественный код на том же С++. По скорости да, пока что С++ круче, но через какое-то время эта разница не будет заметна вообще.
Это все фантазии, есть достаточно примеров в которых джава сливает С+±у в плане производительности в несколько порядков из-за дизайна языка. Так же джава очень сильно сливает С+±у из-за прожорливости в плане памяти, что часто крайне критично для системного программирования.
Окей.
Как замечательно что ты наконец то это понял.
Как правило в этом весь смысл разработки чипа: сделать меньше и дешевле особенно для телефонов. Часто если Ваш чип на 50 центов дороже конкурента, то Вы уже вне рынка;).
Имел в виду то, что «меньше» не всегда значит «дешевле». Совсем маленькие чипы требуют большую точность при изготовлении, что напрямую влияет на себестоимость.
Верно, новые технологии обходятся очень дорого в плане NRE, но после изготовления всех масок стоимость выпуска одного чипа может стать даже ниже, чем было бы на старой технологии.
В любом случае, всегда есть ряд задач, критичных к скорости — в этом случае не умирает не то что С++, но и до сих пор некоторые извращаются на ассемблере:).
Вы несовсем меня поняли. На С++ можно проектировать не только софт, но и саму аппаратную платформу. Java такого не позволяет.
С++ — монополист в области embedded, это прикольно!
Мне очень льстит такой уровень внимания с вашей стороны. Тем не менее буду очень благодарен, если вы перестанете оставлять непонятные комментарии в ответ на мои.
А что тут непонятного, ты написал глупость, С++ никогда не был монополистом в области embedded.
Пробуйте иногда читать не только комментарии, на которые отвечаете, а полностью всю ветку: это как раз и позволит вам не писать глупости.
То есть конкретно по теме смороженной тобой глупости сказать нечего?
Denis: Основное преимущество С++ перед прочей лабудой (Java, C# и т. д.) в том, что на нем сегодня можно разрабатывать как программный код так и аппаратную платформу. Мир идет именно в этом направлении и это основной тренд развития Embedded систем... В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Me:... Но, с другой стороны, называть C++ монополистом в области embedded тоже неправильно...
reality_hacker: А что тут непонятного, ты написал глупость, С++ никогда не был монополистом в области embedded.
Извините, если я вас чем-то обидел. Всегда считал, что к представителям сексуальных меньшинств я проявляю должное уважение и терпимость. Вы такой, какой есть: это ваше решение и не мне вас судить. Но такое внимание с вашей стороны заставляет меня чувствовать себя неудобно, о чем я вам и сказал. Еще раз простите, если что не так.
Я понял, ты с высоты своего неоконченного среднего образования не понимаешь разницы между словами «тренд» и «монополист».
> Извините, если я вас чем-то обидел. Всегда считал, что к представителям сексуальных меньшинств я проявляю должное уважение и терпимость. Вы такой, какой есть: это ваше решение и не мне вас судить. Но такое внимание с вашей стороны заставляет меня чувствовать себя неудобно, о чем я вам и сказал. Еще раз простите, если что не так.
О, еще у одного butt hurt диагностировался.
Butthurt в данном контексте пишется слитно.
Глядя на поднимаемые человеком темы приходят мысли что я все правильно написал.
> В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Я, как раз, думаю напротив — развитие аппаратной части убъёт C/C++ и выживут лишь нынешние платформено-независимые языки (типа Джавы или Шарпа).
В довольно скором будущем, та же джава станет ассемблером в процессорах, с командами/инструкциями, реализованными на аппаратном уровне — после чего, надобность в C/C++ полностью отпадёт.
АРМ процы с возможностью выполнения джава байт кода (Jazelle) появились 7 лет назад, но как то мобильные оси все продолжают писать на С, может что-то не так в датском королевстве?
Когда чип выпускается только для выполнения Java инструкций — это сокращает его применение процентов на 90%, и, соотвественно, ведёт к отсутствию спроса на него. Такие чипы были и где они сейчас?
Коментар порушує правила спільноти і видалений модераторами.
Что касается Украины, то я думаю, плюсы скоро останутся только в Киеве, Львове и Харькове.
Например, в той же Одессе, учить плюсы с нуля уже не имеет смысла, несмотря на наличие вакансий.
Ну, о смерти C++ стоит говорить в первую очередь в контексте разработки enterprise-приложений под Windows, причем, как серверных, так и десктопных — в этой нише, действительно, .NET вытеснил его чуть менее чем полностью.
Впрочем, по моим наблюдениям, и под *nix (поправьте, могу ошибаться) на desktop-направлении «плюсы» теснят как Java, так и Python+PyGTK, а на Web — PHP/Python/Ruby. Да и на чисто серверном enterprise’е Java очень неплохо себя чувствует.
Вместе с тем, есть ряд ниш, в которых С++ чувствует себя замечательно и потеснить его оттуда пока весьма и весьма непросто.
P.S. Как раз сегодня утром пришла в голову мысль, что если бы под C++ под Windows существовала _человеческая_ UI-библиотека (в идеале — аналог WPF, но хотя бы на уровне Windows Forms с таким же разнообразием сторонних компонентов), то даже на Windows-десктопе у «плюсов» был бы неплохой шанс занять если не первое, то, по крайней мере, призовое место.
И еще добавить конструкций, библиотек и получился бы C# с .NET
Конструкций — вряд ли, разве что для лямбда-выражений и анонимных методов, для работы с STL контейнерами пригодились бы.
А что касается библиотек — то, собственно, что в этом плохого?. NET не в последнюю очередь заработал популярность именно благодаря доступной из коробки богатой библиотеке классов.
QT?
Ух ты, всегда думал, что она только под Linux. Спасибо!
С++ не умрёт еще очень долго, потому что на другая технология, способная занять его нишу, её и на горизонте не появилась.
Кстати, в Украине немеряно хорошо оплачиваемой работы по С++
R&D либо С++ мидлварь для тех же игр очень редкое явление в Украине...
А почему «большой геймдев умирает»?
Все оказуаливается и омобиливается... делать маленькие и дешевые игры выгоднее чем большие и дорогие, а еще и пиратство в придачу...
Ветка начинается с фразы:
If Cobol is still alive, the chic «C++ is dead» crowd may be wrong:«Approximately 5 billion new lines of Cobol code are added to live systems every year, Micro Focus said.»
As always, beware of the agenda of any source of info.
А дальше какие то праздные посты не несущие информационной нагрузки.
Мое мнение — в штатах дофига интересной работы для С+±ников, но она тяжелее аутсорсится, поэтому возможно на/в Украине не все так радужно.Я мало на С++ кодю, поэтому может из местных кто-то выскажется.
Хихи. Всё правильно, C++ занял своё место рядом с Коболом.
Ага сразу за Java :)
Нот э юзер. Можно куда-то выложить?