Ще одна тема про смерть С++
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.
Всім хто так вважає, або хоче цього — раджу почитати цю розмову: www.linkedin.com/...&trk=EML_anet_ac_pst_ttle
Володимир Яджак, C/C++ developer в SoftServe
Facebook
Twitter
LinkedIn
Denis Muratov
anonymous
на удивление — живет Фортан, а вы С++ уже хоронить собрались...
Да ну? Когда похороны? :).
Может окошки и веб-странички на нем сегодня никто и не рисует, но этим сегодня область информационных технологий не ограничена. Есть более серьезные задачи и там С и С++ - само то :). Может когда С++ и умрет, но уж точно не в ближайшее десятиление, а к тому времени как он начнет умирать изменится вообще концепт программирования и другие на сегодняшний день модные языки умрут вместе с ним.
Bogdan Shyiak
> Есть более серьезные задачи и там С и С++ - само то :)
ИМХО, наиболее адекватный аргумент про смерть ЦПП — это то что для «более серьезные задачи» используют чистый Ц, а для не «более серьезные задачи» — Джава/С№/Питон
Антон Пушков
для более серьезных задач подходит именно С++, так как он давно обходит С по производительности и удобству использования...
Про удобство использования — это субъективный момент.
А вот про скорость надо бы пруфлинк. Только не в стиле тех в которых Java превосходит C, то есть не синтетические.
пруфлинк не нужен...
в С++ мы можем иметь удобный (классы и подобный ОО сахар), производительный(шаблонные подстановки, статическая типизация), компактный (опять таки шаблоны) и защищенный (более строгая типизация и опять шаблоны) код... в С мы можем иметь только одно из вышеперечисленного... сами подумайте почему...
в С++ мы можем иметь удобный (классы и подобный ОО сахар), производительный(шаблонные подстановки, статическая типизация), компактный (опять таки шаблоны) и защищенный (более строгая типизация и опять шаблоны) код... в С мы можем иметь только одно из вышеперечисленного... сами подумайте почему...
а если хотите пруф, поищите сравнение одного и того же алгоритма сортировки на С и С++ (по моему было на blog.gamedeff.com), цену вызова функций по указателю (чтоб на С было удобно, их приходится использовать, в С++ заменяется шаблоном... год назад было очень актуальной темой в англоязычном инете), ну и про сахар типа RAII, SFINAE и тп, которое на С просто невозможно, а С++ помогает вырывать лишние такты при сохранении компактности и защищенности кода (хотя иногда нужно быть 7 пядей во лбу чтоб их понимать)...
1) Я не пытаюсь доказать что ЦПП не нужен.
2) «пруфлинк не нужен...» — если просят, то наверно таки нужен :)
2) «пруфлинк не нужен...» — если просят, то наверно таки нужен :)
3) Если не ошибаюсь, то шаблоны — это «работают» во время компиляции, а ссылки на функции, вроде как, в рантайме, посему немного не корректное сравнение, кстати ссылочку тоже хорошо было бы дать.
3) вот именно, но в С от вызовов функций по указателю можно уйти несколькими способами
1 дефайны — но у них ограничен уровень вложенности
1 дефайны — но у них ограничен уровень вложенности
2 копипаст — без коментариев
вот цыфры assemblyrequired.crashworks.org/...nctions-really
В С++ в большинстве случаев их можно заменить шаблоном
reality_hacker
Mike Gorchak
Не нужно доказывать про скорость, это просто бессмысленно.
Если имелось в виду: blog.gamedeff.com/?p=84 , то я даже бы сказал, что меня откровенно это веселит. Таким образом я могу доказать, что сортировка на bash’е быстрее С++’шной. :)
Да, кстати, в MSVC 2005 существует жестокая бага в оптимизаторе. Я им репортил, и получил подтверждение,
что доступ по *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 сделать. Какие-то вопросы ты задаёшь стрёмные... как для программиста.
Читать до просветления:Отлично, и как это поможет программисту в main.c отсортировать масив структур, которые там же и определяются?
> Какие-то вопросы ты задаёшь стрёмные... как для программиста.
Потому как ты не можешь внятно описать твой подход, все какие то полунамеки.
Напиши один и тот же алгоритм на С и на С++, как умеешь. Я тебе переделаю код на С, который ты потом можешь тестировать.
Я не совсем понимаю причем тут С++, если проблема которую мы обсуждаем — заинлайнить функцию сравнения в С сортировке.
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);
point *bp = (point*) b;
if (ap -> x! = bp -> x)
return ap -> x — bp -> x;
else
point t [n];
sort (&t, n, sizeof (point), &cmp);
for (int i = 0; i < n; i ++)
Вот мой код:
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);}
1) Только ещё нужно изменить параметры cmp и sort_points функций, чтобы они сразу принимали point структуру.
2) Включить работу с копированием структур средствами языка вместо вызова memcpy (). *p1=*p2;... и т. д.
Я использовал gcc 4.3.4 (cygwin). Полученный код быстр и минимален. Поэтому в свете начального вопроса мы имеем, что C быстр так же как C++. То, что он не такой гибкий как C++, это уже второй вопрос.
Ок, это то о чем и говорили Антон и я, для каждого нового типа данных обьявленного в программе прийдется руками копипастить весь алгоритм сортировки, что как уже отмечалось можно автоматизировать с помощью макроса.
Здесь моя ошибка, я неправильно понял один твой коммент, и думал что ты имеешь в виду что-то другое.
Denis Muratov
Коментар порушує правила спільноти і видалений модераторами.
Основное преимущество С++ перед прочей лабудой (Java, C# и т. д.) в том, что на нем сегодня можно разрабатывать как программный код так и аппаратную платформу. Мир идет именно в этом направлении и это основной тренд развития Embedded систем, когда один человек будет делать и софт и железо. В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Константин Чапюк
Частично согласен. С++ будет еще жить и жить, равно как и «прочая лабуда»).
Но, с другой стороны, называть C++ монополистом в области embedded тоже неправильно:1. мощности и возможности железа постоянно растут (даже сейчас вопросы оперативной и хард памяти уже не так акуальны)
2. создаются различные платформы, под которые можно программить на более высоком уровне по сравнению с C/asm (и я говорю не только о C++);
3. java сейчас тоже движется в сторону embedded (например, en.wikipedia.org/...irtual_machine
Кстати, уже была попытка создания ОС на java — JavaOS. Но как-то заглохло оно все. Думаю, через какое-то время к этой идее опять вернутся. Так что «все профессии нужны, все профессии важны».
1. Какими бы не были мощность и железо, но всё ходит по кругу. Выпускают чип более компактным, меньше потребляет, соответственно частота меньше, памяти меньше. Развивают эту ветку до следующего скачка.
2. Программить что? Если мы говорим про GUI — пожалуйста, если мы говорим про системные вещи, то зачем?
2. Программить что? Если мы говорим про GUI — пожалуйста, если мы говорим про системные вещи, то зачем?
3. Она всегда там крутилась.
1. Те же телефоны наоборот стараются сделать покрупнее, чтобы человеку удобно было им пользоваться. И делать чипы меньше какого-то определенного размера не имеет смыла (в том числе и в экономическом плане).
2. GUI само собой. А почему же системные вещи нет смысла программить на джаве? Субъективно — качесвенный код на джаве чуть удобнее мейнтейнить, чем качественный код на том же С++. По скорости да, пока что С++ круче, но через какое-то время эта разница не будет заметна вообще.
2. GUI само собой. А почему же системные вещи нет смысла программить на джаве? Субъективно — качесвенный код на джаве чуть удобнее мейнтейнить, чем качественный код на том же С++. По скорости да, пока что С++ круче, но через какое-то время эта разница не будет заметна вообще.
3. Да, согласен.
> А почему же системные вещи нет смысла программить на джаве? Субъективно — качесвенный код на джаве чуть удобнее мейнтейнить, чем качественный код на том же С++. По скорости да, пока что С++ круче, но через какое-то время эта разница не будет заметна вообще.
Это все фантазии, есть достаточно примеров в которых джава сливает С+±у в плане производительности в несколько порядков из-за дизайна языка. Так же джава очень сильно сливает С+±у из-за прожорливости в плане памяти, что часто крайне критично для системного программирования.
> > И делать чипы меньше какого-то определенного размера не имеет смыла
Как правило в этом весь смысл разработки чипа: сделать меньше и дешевле особенно для телефонов. Часто если Ваш чип на 50 центов дороже конкурента, то Вы уже вне рынка;).
Имел в виду то, что «меньше» не всегда значит «дешевле». Совсем маленькие чипы требуют большую точность при изготовлении, что напрямую влияет на себестоимость.
Верно, новые технологии обходятся очень дорого в плане NRE, но после изготовления всех масок стоимость выпуска одного чипа может стать даже ниже, чем было бы на старой технологии.
В любом случае, всегда есть ряд задач, критичных к скорости — в этом случае не умирает не то что С++, но и до сих пор некоторые извращаются на ассемблере:).
Вы несовсем меня поняли. На С++ можно проектировать не только софт, но и саму аппаратную платформу. Java такого не позволяет.
С++ — монополист в области embedded, это прикольно!
Мне очень льстит такой уровень внимания с вашей стороны. Тем не менее буду очень благодарен, если вы перестанете оставлять непонятные комментарии в ответ на мои.
А что тут непонятного, ты написал глупость, С++ никогда не был монополистом в области embedded.
Пробуйте иногда читать не только комментарии, на которые отвечаете, а полностью всю ветку: это как раз и позволит вам не писать глупости.
То есть конкретно по теме смороженной тобой глупости сказать нечего?
Denis: Основное преимущество С++ перед прочей лабудой (Java, C# и т. д.) в том, что на нем сегодня можно разрабатывать как программный код так и аппаратную платформу. Мир идет именно в этом направлении и это основной тренд развития Embedded систем... В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Me:... Но, с другой стороны, называть C++ монополистом в области embedded тоже неправильно...
reality_hacker: А что тут непонятного, ты написал глупость, С++ никогда не был монополистом в области embedded.
Извините, если я вас чем-то обидел. Всегда считал, что к представителям сексуальных меньшинств я проявляю должное уважение и терпимость. Вы такой, какой есть: это ваше решение и не мне вас судить. Но такое внимание с вашей стороны заставляет меня чувствовать себя неудобно, о чем я вам и сказал. Еще раз простите, если что не так.
Я понял, ты с высоты своего неоконченного среднего образования не понимаешь разницы между словами «тренд» и «монополист».
> Извините, если я вас чем-то обидел. Всегда считал, что к представителям сексуальных меньшинств я проявляю должное уважение и терпимость. Вы такой, какой есть: это ваше решение и не мне вас судить. Но такое внимание с вашей стороны заставляет меня чувствовать себя неудобно, о чем я вам и сказал. Еще раз простите, если что не так.
О, еще у одного butt hurt диагностировался.
Andrii Mishkovskyi
Butthurt в данном контексте пишется слитно.
Глядя на поднимаемые человеком темы приходят мысли что я все правильно написал.
maxdz
> В основе этих технологий лежит именно С++, а не деревянный С или через чур абстрактный Java.
Я, как раз, думаю напротив — развитие аппаратной части убъёт C/C++ и выживут лишь нынешние платформено-независимые языки (типа Джавы или Шарпа).
В довольно скором будущем, та же джава станет ассемблером в процессорах, с командами/инструкциями, реализованными на аппаратном уровне — после чего, надобность в C/C++ полностью отпадёт.
АРМ процы с возможностью выполнения джава байт кода (Jazelle) появились 7 лет назад, но как то мобильные оси все продолжают писать на С, может что-то не так в датском королевстве?
Когда чип выпускается только для выполнения Java инструкций — это сокращает его применение процентов на 90%, и, соотвественно, ведёт к отсутствию спроса на него. Такие чипы были и где они сейчас?
Коментар порушує правила спільноти і видалений модераторами.
Oleksandr Sakharov
Про смерть можно говорить только тогда, когда исчезнут вакансии за приемлемые деньги. На счет перспектив, все зависит от политики заказчиков и особенности фирм в конкретном регионе.
Что касается Украины, то я думаю, плюсы скоро останутся только в Киеве, Львове и Харькове.
Что касается Украины, то я думаю, плюсы скоро останутся только в Киеве, Львове и Харькове.
Например, в той же Одессе, учить плюсы с нуля уже не имеет смысла, несмотря на наличие вакансий.
Dmytro Lapshyn
Ну, о смерти C++ стоит говорить в первую очередь в контексте разработки enterprise-приложений под Windows, причем, как серверных, так и десктопных — в этой нише, действительно, .NET вытеснил его чуть менее чем полностью.
Впрочем, по моим наблюдениям, и под *nix (поправьте, могу ошибаться) на desktop-направлении «плюсы» теснят как Java, так и Python+PyGTK, а на Web — PHP/Python/Ruby. Да и на чисто серверном enterprise’е Java очень неплохо себя чувствует.
Вместе с тем, есть ряд ниш, в которых С++ чувствует себя замечательно и потеснить его оттуда пока весьма и весьма непросто.
P.S. Как раз сегодня утром пришла в голову мысль, что если бы под C++ под Windows существовала _человеческая_ UI-библиотека (в идеале — аналог WPF, но хотя бы на уровне Windows Forms с таким же разнообразием сторонних компонентов), то даже на Windows-десктопе у «плюсов» был бы неплохой шанс занять если не первое, то, по крайней мере, призовое место.
Developer256
И еще добавить конструкций, библиотек и получился бы C# с .NET
Dmytro Lapshyn
Конструкций — вряд ли, разве что для лямбда-выражений и анонимных методов, для работы с STL контейнерами пригодились бы.
А что касается библиотек — то, собственно, что в этом плохого?. NET не в последнюю очередь заработал популярность именно благодаря доступной из коробки богатой библиотеке классов.
Ух ты, всегда думал, что она только под Linux. Спасибо!
Васисуалий Лоханкин
Ничего не создает сколько флейма как очевидная глупость
С++ не умрёт еще очень долго, потому что на другая технология, способная занять его нишу, её и на горизонте не появилась.
С++ не умрёт еще очень долго, потому что на другая технология, способная занять его нишу, её и на горизонте не появилась.
Кстати, в Украине немеряно хорошо оплачиваемой работы по С++
либо геймдев, в котором все сильно стремятся в шарп и ObjC, так как большой геймдев медленно умирает, а в маленьком можно без С++, либо поддержка/багофикс...
R&D либо С++ мидлварь для тех же игр очень редкое явление в Украине...
Ivan M
А почему «большой геймдев умирает»?
Все оказуаливается и омобиливается... делать маленькие и дешевые игры выгоднее чем большие и дорогие, а еще и пиратство в придачу...
reality_hacker
Ветка начинается с фразы:
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.
А дальше какие то праздные посты не несущие информационной нагрузки.
Мое мнение — в штатах дофига интересной работы для С+±ников, но она тяжелее аутсорсится, поэтому возможно на/в Украине не все так радужно.Я мало на С++ кодю, поэтому может из местных кто-то выскажется.
Victor Sergienko
Хихи. Всё правильно, C++ занял своё место рядом с Коболом.
Ага сразу за Java :)
69 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів