10 причин почему программист на С++ может выбить много денег

Справедливости ради, стоит заметить, что это лишь одна из реализаций. Давайте возьмем один алгоритм. Вчера я просто проверил стандартные средства.

Еще бы реализвать этот алгоритм на «правильных» языках и сравнить. Но вообще сортировка это не то, на чем надо сравнивать, т.к. получается результат очень далекий от реальных задач.

Все верно в посте, неужели кому-то это ещё не очевидно? Умные люди мигрируют с Си++ на Си очень часто, обратное движение происходит только от недостатка опыта или ума.

обратное движение происходит только от недостатка опыта или ума

Хорошая характеристика разработчиков GCC.

И что, много они перевели на плюсы? Вот тут я повсеместно вижу одну сишечку. Я куда-то не туда смотрю?..

Кто мигрирует с С++ на С?

Тут в посте проскакивал блог автора ZeroMQ, Пропессор вроде как уже не на Си++ ориентируется, а на Сишечку для своего HNC. Это из последнего, что я видел в публичном.

Очень спорное утверждение. Вообще-то С быстрее, а этот случай с сортировкой, один из немногих, где C++ что-то показывает. И это решается с помощью

Вообще-то примерно поровну.

C++ вообще выглядит как хорошая идея поначалу, т.к. кажется, что «это же тот же самый Си, только с плюшками, плюшки можно не использовать в крайнем случае!». И только спустя время вкорячив STL, Boost и обрастая шаблонами, начинаешь понимать, что это была плохая идея, очень плохая идея.

Вообще-то примерно поровну.

Да, конечно, поровну.

3 против 8, в пользу Pure C. :)

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

+1. Стопудово.

И только спустя время вкорячив STL, Boost и обрастая шаблонами, начинаешь понимать, что это была плохая идея, очень плохая идея.

Конечно, ведь копипаста руками или отказ от остатков статической проверки типов куда как лучше.

И что, много они перевели на плюсы?

В процессе, в 4.8 уже шаблоны используются.

«Вроде»? В общем, конкретные примеры в студию.

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

Значит, вы не знаете С++. Или не умеете программировать.

Человек, знающий С++, не может предпочесть ему С, кроме случаяв, обусловленных независящими от этого человека обстоятельствами.

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

Сходи по ссылке, приведенной аноном, в сообщении чуть выше. http://www.linux.org.ru/forum/development/9500118?cid=9518881 (комментарий)

Посмотри, там и условия теста расписаны. (Самый быстрый на С++ vs самый быстрый на C.)

Почему не стоит связываться с CL:

• Ваши программы никто не будет использовать

Чего это вдруг? Для реализации ОС или драйвера и сегодня предпочитают использовать голый Си.

Предпочитали. Новые разработки идут на многих других языках.

linux не последует примеру gcc по причине религиозных убеждений создателя.

Вы имеете в виду скорее всего достаточно старые проекты. Назовите хотя бы одну объективную причину предпочесть С. Исключения и rtti отключаются.

ABI.

Что ABI? Примеры.

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

Но вообще код немного странный. Попробую разобраться, когда будет время.

IoKit, WDF как бы говорят нам об обратном

Кто мигрирует с С++ на С?

http://github.com/250bpm/nanomsg

Точнее просто переделывает с нуля.

Где там сведения о реализации на С++? Переписывают ли?

Почему переписывают? Уж ты-то согласен, что С++ не хуже С?

Суть истории в том, что Martin Sustrik создавал ZeroMQ на (подмножестве) C++ под LGPL и трейдмарками iMatix, потом написал в своём блоге на тему «почему нужно было писать на C и под BSD-like», форкнул Crossroads I/O чтобы избавиться от трейдмарков (всё ещё C++ и LGPL), потом начал писать снова nanomsg на Си под MIT и смотреть в сторону оптимизации ядра под её нужды (при этом «nanomsg» is a trademark of 250bpm s.r.o.).

А «не хуже» — наверно просто кому-то оно «не лучше» чтобы писать какой-нибудь специфичный системный код.

З.Ы. ну, то есть, зачем nginx С++, например? Чтобы делать foo *bar = static_cast<foo*>(ngx_palloc(pool, size)); ?)

Не лучше он быть не может. Хотя бы время от времени он будет вам полезен.

ну, то есть, зачем nginx С++, например? Чтобы делать foo *bar = static_cast<foo*>(ngx_palloc(pool, size)); ?

Чтобы модули писать не так убого, хотя бы. В коде nginx столько копипасты, что диву даешься. В общем, чтобы иметь нормальный код. Впрочем, nginx писал админ и тут все простительно.

Не лучше он быть не может.

В умелых руках — я-то согласен. Но вот если кто-то хочет (оставим в стороне обоснованность такого желания) писать на таком «C++», который ровным счётом или почти == Си, тогда чисто организационно может быть лучше писать именно на си (C99 — с фичами на тему инициализации структур и «переменных»/«гибких» массивов).

сишный код программ, которые быстрее плюсовых, является кодом и на С++ тоже.

Конечно, можно написать на C и откомпилировать это «плюсатым» компилятором. Но ведь это все равно будет код на C. :)

Если сравнивать по-честному, необходимо использовать в «плюсатом» варианте все сладкие плюшки, которые даёт C++, а не избегать их применения.

А никто и не говорит о том, чтобы избегать код в стиле С++. Вопрос же в оптимизациях. Мест, которые нужно оптимизировать в реальных программах не так много и они легко локализуются. И тут С++ позволяет использовать все средства С + свои особенности. В остальном С++ не медленнее С, а в шаблонном коде почти так же быстр, как в случае макросов С(что используется не часто). Если сравнивать с другими языками, то между С и С++ в плане производительности разницы нет.

чисто организационно

Вот с этим согласен.

Нужен новый язык для замены С/С++...

Тенденции есть - D, Go, Rust. Но результат пока не очень.

Если сравнивать с другими языками, то между С и С++ в плане производительности разницы нет.

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

Какое такое тормозное позднее связывание?

В удалённых. Меня забанили по ойпи, а мой ответ удалили, потому что на ЛОР должно рассуждать о ЯП, ничего о них не зная. Как и о других вещах впрочем. Но правду не скроешь! Позднее связывание ЕСТЬ!

по vtbl чтоли? в каком месте оно тормозное то?

Короче, C++ говно в любом случае. Присоединяйтесь лучше к моему стартапу Scalable Dynamic Cloud Lisp Enterprise Application Server

Читай по ссылке. Там в конце написано. Я специально самый простой текст по этой тематике привёл. Или поисковиком найди попонятнее, мне недосуг ужо. Буду себе новый ник выдумывать.

Присоединяйтесь лучше к моему стартапу

... нас не заманишь лиспом борщистым. :D

В С++ позднее связывания быстрое. Покажите на сишечке более быстрое позднее связывание.

Покажите на сишечке более быстрое позднее связывание.

Это какое-такое позднее связывание в сишечке? Просвети что-ли.

Присоединяйтесь лучше к моему стартапу Scalable Dynamic Cloud Lisp Enterprise Application Server

Чем UCW не угодил?

Короче, C++ говно в любом случае.

Я бы всё равно не стал бы присоединяться к столь подверженному эмоциям существу, делающему столь смелые суждения в области, в которой оно не разбирается, ни в каком деле.

Покажите на сишечке более быстрое позднее связывание.

Давай, я лучше покажу тебе толстотролля. Погляди в зеркало, и вот, он там!

Это какое-такое позднее связывание в сишечке?

Это типа http://fuse.sourceforge.net/doxygen/structfuse__operations.html.

Это типа http://fuse.sourceforge.net/doxygen/structfuse__operations.html.

Так это и не совсем сишечка как-бы.

Педивикия: http://en.wikipedia.org/wiki/Late_binding

Late binding, or dynamic binding,[1] is a computer programming mechanism in which the method being called upon an object is looked up by name at runtime.

Нет такого в сишечке. (здесь вообще о Pure C)

Это сишечка. Ещё — http://lwn.net/Articles/444910. Если совсем просто, то

struct iface {
    result_t(*method)(void* ctx, ...);
    // ...
};

struct a_impl {
    // ...
    struct iface *method_table;
};

result_t a_impl_method(void* ctx, ...)
{
    struct a_impl *this = ctx;
    // ...
}

// ...

struct iface a_default_method_table = {
    .method = a_impl_method,
    // ...
};

    struct a_impl a = { ..., &a_default_method_table };
    a.method_table->method(&a, ...);

вместо

struct IFace {
    virtual Result method(...) = 0;
    // ...
};

struct AImpl : public IFace {
    // ...
    Result method(...) {
        // ...
    }
};

    AImpl a(...);
    a.method(...);

компилируются они различно, но примерно одинаково — call *%reg / call *(%reg), то есть в вызов по указателю на конкретный метод.

Нет такого в сишечке.

В примере method_table настраивается во время выполнения, так что выбор производится во время него же.

З.Ы. Более точная ссылка — http://en.wikipedia.org/wiki/Late_binding#Late_binding_in_C.2B.2B, «name» тут это адрес (изначально с символом).

то есть в вызов по указателю на конкретный метод.

Ну так это же издревле известный метод. И реализовать его можно по-разному.

В ручную то, на сишечке, много чего можно сделать, язык то низкоуровневый, по большому счету. Тут, вроде, речь шла о автоматическом связывании.

Ну да ладно, это лишь о терминологии.

ээээ ниже вроде уже показали , но .

у каждой струкруры тэг -( ну или адресса в динамике нарезаны на регионы , главное есть способ классифицировать в рантайме по переменной её «тип»)

и всё - получаем выбор конкретного метода по типу.

именно , что позднее связывание.