Поломана совместимость с С в С++11?

Не говоря уж о той мелочи, что плюсовый тормознее и тяжелее по определению

в С уже научились не сливать плюсам на такой простой операции как сортировка?

Смесь чего с чем? Все зависит от рук. Я на С++ переходил в течении нескольких лет(давно было - больше 10 лет назад), постепенно. Никто тебя за уши не тянет писать говнкод вроде boost'а.

Просто вместо того, чтобы поставить очередной префикс, ты пишешь namespace. Вместо того, чтобы заводить скрытую в .c структуру и функции работы с ней, заводишь ту же структуру(или класс) с скрытыми полями и вообще обеспечиваешь работу пользовательского типа в том же стиле, что и встроенного. Вместо того, чтобы заводить структурку с указателями на функции - заводишь класс. Вместо того, чтобы копипастить код для разных типов или заворачивать это хозяйство в макросы - пишешь простенькие шаблоны. И т.д. и т.п.

С ничем не лучше С++. Вот единственного, что не хватает - это стандартного ABI для С++.

Когда-то надо очищать свою гумно.

Чтобы не херачить костыли

Это не костыли. Это особенности языка. Шаблоны - зло потенциально еще худшее,чем макросы. И ООП на С - это вполне нормально, как доказывает множество проектов, от ядра до гнома. Без плюсового идиотизма.

он лучше С

Ни разу. Торвальдс уже все высказал по этому поводу (и, кажется, не однократно).

Как это делает плюсовый компилятор быстрее? И где сишная сортировка сливает? На специально подготовленных тестах?

В std::sort есть что-то, что нельзя написать на си?

Просто вместо того, чтобы

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

С гораздо лучше плюсов тем, что ПРОЩЕ. И код на нем более явный. благодаря отсутствию перегрузки операторов, хитрых соглашений о передаче объектов и пр. и пр.

Торвальдс уже все высказал по этому поводу (и, кажется, не однократно).

Торвальдс высказывался о всех областях применения языка или только о разработке ядра?

Его высказывания достаточно универсальны.

И ООП на С - это вполне нормально, как доказывает множество проектов, от ядра до гнома

#include <map>
#include <string>
using namespace std;

static string foo( const string& msg  ) {
    return "HTTP/1.1 200 OK\r\n\r\n" + msg;
}

int main() {
    map<int,string> m;
    for( size_t i = 0 ; i < 100 ; ++i )
        m[ rand() % 100 ] = foo( to_string( i ) ) + "`";
}

во-первых не надо гном и его ООП сравнивать с тем, что в ядре, во-вторых начнем с простого - конструкторы и деструкторы, приведи аналог на С такого, и можно будет оценить нормальность

Что бы ни думал Торвальдс, на плюсах есть хорошо написанные ядра.

И где сишная сортировка сливает? На специально подготовленных тестах?

т.е. ты даже не знаешь разницу между qsort и std::sort? намек - посмотри на параметры

В std::sort есть что-то, что нельзя написать на си?

да - эффективный алгоритм для произвольного типа и контейнеров, в С придется копипастить, копипастить и еще раз копипастить

Конструкторы и деструкторы - тоже зло. Только явная инициализация. И вместо деструкторов - сборщик мусора, явный или нет.

Посмотрите на gobject.

gobject обходится без копипасты в этом месте.

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

Костыли на макросах не считаются. И не зря gtk уходит на vala.

Что конкретно вы имеете в виду, говоря о плюсовом идиотизме?

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

Так макросы же. Конечно, код будет страшноват, но по скорости (если мы сравниваем скорость) - такой же.

Для этого на Си придется писать макрос. std::sort выигрывает за счет встраивания кода(поскольку является шаблоном).

Конструкторы и деструкторы - тоже зло. Только явная инициализация.

хорошо, а код на С будет? чтоб наглядно сравнить добро и зло

Посмотрите на gobject.

int a[ 1000000 ];
std::sort( a, a + 1000000 );

можно аналог с gobject?

Нет, как раз именно так бардак уходит. Уходит вместе с префиксами, макросами, указателями на функции на каждый чих и пр.

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

Вот показательный пример религиозного высказывания. В чем это зло? И да, вас никто не заставляет писать кострукторы и деструкторы - пишите явные методы, если так привыкли к простыням.

Вот ты тут про gobject говоришь, а тебя не запарывает анрефить ссылки руками? В С++ это делалось бы само - в деструкторе ссылки. Собственно, так в С++ и реализован подсчет ссылок в shared_ptr.

И почему же тогда его нет?

И опять же, вы можете написать этот макрос и в С++, только там это не имеет смысла, поскольку есть более развитый и простой механизм - шаблоны. Которые, на всякий случай, типобезопасны и работают не с текстом(в отличие от макросов) и в курсе всех особенностей языка.

Так макросы же.

чтоб было удобно дебагить и искать ошибки в коде?

Я и не спорю, что шаблоны лучше. Правда, типобезопасность в макросы тоже можно зашить, но читаемости это не прибавит.

Я пробовал переписать STL на си - это фактически можно сделать с сохранением функциональности, но пользоваться этим невозможно. Правда, больше из-за нехватки других средств, особенно перегрузки функций и операторов.

Не хочешь ли ты сказать, что шаблоны в этом отношении лучше? =)

Правда, больше из-за нехватки других средств, особенно перегрузки функций и операторов.

макросы в С сами по себе ущербны и не пригодны для серьезного использования, наглядный пример:

MAX( FOLD(MERGE(a,b)) + FOLD(b), FOLD(c) )

выдаст не рабочий код, а мусор

Не хочешь ли ты сказать, что шаблоны в этом отношении лучше? =)

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

Может ты приведешь простенький пример нормального(как ты говоришь) ООП на нем(или не на нем, а просто на С - сам решай). Ну там иерархия из двух классов(писал из головы, ничего полезного тут не происходит):

class A
{
public:
    virtual size_t f() const
    {
        return str.size();
    }

    virtual std::string g(const std::string &s)
    {
        std::string res = str;
        str = s;
        return res;
    }
private:
    std::string str;
};

class B : public A
{
public:
    size_t f() const override
    {
        return i;
    }

    std::string g(const std::string &s) override
    {
        i = 2 * s.size();
        return A::g(s + s);
    }

private:
    size_t i = 0;
};

А потом честно скажи мне, что проще...

Конечно лучше. Жаль еще концептов пока нет(только в буст, через одно место сделанные). С ними вообще все красиво.

Нет, это невозможно сделать.

наглядный пример

Возможно, он был бы нагляден, если бы я знал, что такое MAX, FOLD, MERGE. Но да, на макросах лучше не делать что-то сложное.

их можно дебагить в отличие от

Про дебагер не знаю, я мало им пользуюсь, а что касается хитрых статических ошибок - в макросах они находятся чтением выхлопа препроцессора, а в шаблонах - никак (а что иногда пишет на это компилятор - мы все видели).

Что именно из STL нельзя сделать? Можно небольшой пример кода.

макросы в С сами по себе ущербны и не пригодны для серьезного использования

Замени «макросы» на «шаблоны» и «С» на «С++», получишь истинное утверждение.

gtk не УХОДИТ ни на какую vala. Остается gtk, остается vala. И это как раз нормальный подход - не пытаться скрестить С и ООП, а делать отдельные языки (даже ОбжС - намного адекватнее плюсов).

Курите gobject.

Сомневаюсь. Человек не может одинаково хорошо разбираться в нескольких областях.

И как Вы относитесь к тому, что llvm написан на c++ и его разрешено использовать в gcc.

Возможно, он был бы нагляден, если бы я знал, что такое MAX, FOLD, MERGE

да без разницы на самом деле, препроцессор просто подставит выражения, а не их результат, что а) сделает код очень неэффективным б) результат будет совсем не тот, что ожидался, и это если считать, что никаких ошибок в самом коде мы не получим и программа благополучно соберется

что касается хитрых статических ошибок - в макросах они находятся чтением выхлопа препроцессора, а в шаблонах - никак (а что иногда пишет на это компилятор - мы все видели).

не понял о чем речь, можно простой пример с такой ошибкой?

Конечно, С не ОО язык, поэтому ОО на нем всегда будет многословным. Это очевидно. Но если хочется НАСТОЯЩЕГО ОО - тогда и плюсы мимо кассы, у них ОО убогий. Плюсы плохи именно тем, что это язык компромиссов - поэтому получается нечеловеческая сложность (спросите у писавших плюсовый компилятор), при этом совместимость с С все равно теряется.

Курите gobject.

курил уже, потому и знаю, что код с glib будет значительно более раздутый и нечитабельный

Замени «макросы» на «шаблоны» и «С» на «С++», получишь истинное утверждение.

в отличие от вас я привел пример, вы пока только высказали голословное утверждение

спросите у писавших плюсовый компилятор

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

Никак не отношусь. Бывают хорошие программисты на плюсах, да.

Плюсовый код сделать нечитаемым куда проще.

Плюсы НЕНУЖНО сложные. Без этой сложности можно обойтись. Сделать ядро линуха проще сложно. Ну... если не влезть в споры о микроядрах

Плюсовый код сделать нечитаемым куда проще.

я предпочитаю поступать наоборот, потому и не пользуюсь glib

Вопрос не в хороших/плохих программистах. А в том, что создатели по крайней мере двух компиляторов, поддерживающих C/C++ выбрали C++. Разработчики компиляторов приведены в качестве примера потому, что они разбираются в обоих языках.

Плюсы НЕНУЖНО сложные. Без этой сложности можно обойтись.

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