Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

на удивление — живет Фортан, а вы С++ уже хоронить собрались...

Да ну? Когда похороны? :).

Может окошки и веб-странички на нем сегодня никто и не рисует, но этим сегодня область информационных технологий не ограничена. Есть более серьезные задачи и там С и С++ - само то :). Может когда С++ и умрет, но уж точно не в ближайшее десятиление, а к тому времени как он начнет умирать изменится вообще концепт программирования и другие на сегодняшний день модные языки умрут вместе с ним.

> Есть более серьезные задачи и там С и С++ - само то :)

ИМХО, наиболее адекватный аргумент про смерть ЦПП — это то что для «более серьезные задачи» используют чистый Ц, а для не «более серьезные задачи» — Джава/С№/Питон

для более серьезных задач подходит именно С++, так как он давно обходит С по производительности и удобству использования...

Про удобство использования — это субъективный момент.

А вот про скорость надо бы пруфлинк. Только не в стиле тех в которых Java превосходит C, то есть не синтетические.

пруфлинк не нужен...
в С++ мы можем иметь удобный (классы и подобный ОО сахар), производительный(шаблонные подстановки, статическая типизация), компактный (опять таки шаблоны) и защищенный (более строгая типизация и опять шаблоны) код... в С мы можем иметь только одно из вышеперечисленного... сами подумайте почему...

а если хотите пруф, поищите сравнение одного и того же алгоритма сортировки на С и С++ (по моему было на blog.gamedeff.com), цену вызова функций по указателю (чтоб на С было удобно, их приходится использовать, в С++ заменяется шаблоном... год назад было очень актуальной темой в англоязычном инете), ну и про сахар типа RAII, SFINAE и тп, которое на С просто невозможно, а С++ помогает вырывать лишние такты при сохранении компактности и защищенности кода (хотя иногда нужно быть 7 пядей во лбу чтоб их понимать)...

1) Я не пытаюсь доказать что ЦПП не нужен.
2) «пруфлинк не нужен...» — если просят, то наверно таки нужен :)

3) Если не ошибаюсь, то шаблоны — это «работают» во время компиляции, а ссылки на функции, вроде как, в рантайме, посему немного не корректное сравнение, кстати ссылочку тоже хорошо было бы дать.

3) вот именно, но в С от вызовов функций по указателю можно уйти несколькими способами
1 дефайны — но у них ограничен уровень вложенности

2 копипаст — без коментариев

вот цыфры assemblyrequired.crashworks.org/...nctions-really

В С++ в большинстве случаев их можно заменить шаблоном

Не нужно доказывать про скорость, это просто бессмысленно.

Если имелось в виду: 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 и qsort
qsort.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. Но как-то заглохло оно все. Думаю, через какое-то время к этой идее опять вернутся. Так что «все профессии нужны, все профессии важны».

1. Какими бы не были мощность и железо, но всё ходит по кругу. Выпускают чип более компактным, меньше потребляет, соответственно частота меньше, памяти меньше. Развивают эту ветку до следующего скачка.
2. Программить что? Если мы говорим про GUI — пожалуйста, если мы говорим про системные вещи, то зачем?

3. Она всегда там крутилась.

1. Те же телефоны наоборот стараются сделать покрупнее, чтобы человеку удобно было им пользоваться. И делать чипы меньше какого-то определенного размера не имеет смыла (в том числе и в экономическом плане).
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 не в последнюю очередь заработал популярность именно благодаря доступной из коробки богатой библиотеке классов.

Ух ты, всегда думал, что она только под Linux. Спасибо!

Ничего не создает сколько флейма как очевидная глупость
С++ не умрёт еще очень долго, потому что на другая технология, способная занять его нишу, её и на горизонте не появилась.

Кстати, в Украине немеряно хорошо оплачиваемой работы по С++

либо геймдев, в котором все сильно стремятся в шарп и ObjC, так как большой геймдев медленно умирает, а в маленьком можно без С++, либо поддержка/багофикс...

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++ занял своё место рядом с Коболом.

Нот э юзер. Можно куда-то выложить?

Підписатись на коментарі