@Undisputed

В первую очередь интересует с точки зрения потребления ресурсов программы а так же быстродействие
Ещё интересно, есть ли операции, которые быстрее в плюсах чем на Си?
Мне нравятся плюсы, но многие пишут что плюсы медленнее в целом чем Си а так же у плюсов есть существенный оверхед потребления ресурсов а у Си он меньше
В каких ситуациях плюсы в целом по скорости и производительности могут быть лучше Си (и могут ли вообще?)
На простых тестах на быстродействие в принципе почти одно и то же (цифры времени исполнения бегают то в пользу си то в пользу плюсов)
Понимаю что одним словом все не опишешь но хотелось бы получить хоть какую то картину

0

@nonedark2008

Все, что написано на C, можно написать и на C++ без каких-либо потерь производительности.
К тому же, на C++ можно написать менее оптимальную программу (которую к тому же может "затащить" компилятор), но напишешь ты ее намного быстрее.

Короче, как научишься, такой код и будешь писать.

1

@Undisputed

А что скажете насчет иерархических структур для классов? Например, такой код более понятный(если же конечно использовать осмысленные имена), и имеет некоторый уровень абстракции что является плюсом.
Но работая в Си пришлось бы тупо написать простую функцию. Если использовать иерархические возможности плюсов, он будет уступать по скорости Си?

Добавлено через 2 минуты
конкретно: наследование, протитопы классов, области видимости
ведь кода получается больше чем в Си

Добавлено через 43 секунды
Но получается хорошая структура

0

MrGluck

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

Остались ниши, где еще используют С, например программирование микроконтроллеров. В остальном же, предпочитают С++, вдобавок язык динамично развивается.
Выполнение программ на этапе компиляции, к примеру.
Это все сказки сишных эльфов. Не переходите на сторону зла.
А еще, Главное - это алгоритм работы программы. С помощью любого языка можно написать в 100500 раз медленнее, чем на другом, даже если изначально первый "быстрее и лучше" второго.

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

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

2

@Undisputed

А что именно вы подразумеваете под безопасностью? Атаки на приложение или что то иное?

А если оба алгоритма условно идеальны на каждом из языков(с/с++), что в этом случае можете сказать?

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

Добавлено через 1 минуту
В первую очередь меня интересует использование всех возможностей ООП без потери производительности в сравнении с Си (с учетом того что алгоритмы написаны максимально эффективно независимо от языка)

Добавлено через 26 секунд
И конечно же использование template-ов

0

@Renji

Медленнее плюсовые потоки, потому что ради универсальности собраны на виртуальных функциях. Причем, метод сборки явно придумывали упоровшись веществами. Можно было эти самые виртуальные методы сунуть в std::istream/std::ostream, от которых отнаследованы все потоки. Но это же для слабаков, мы сунем в std::istream только указатель на std::streambuf, в котором уже и будут лежать виртуальные методы. Потому что это позволяет взять std::streambuf от файлового потока и сунуть его в потом std::cin. Ну круто же, ты вроде данные с консоли читаешь, а они на самом деле из файла идут. Потом вызывается деструктор файлового потока, прибивает этот самый std::streambuf (право владения то мы передать забыли) и угадайте, что после этого происходит при попытке чтения из cin?

Но вам вроде бы никто не мешает пользоваться плюшками даваемыми синтаксисом плюсов (хоть той же перегрузкой имен), избегая не очень быстрых плюсовых потоков.
К примеру, у сишных строк размер фиксирован, а значит есть риск что этот самый размер внезапно кончится. С непредсказуемым для программы эффектом. А плюсовому std::string то что, он резиновый.

1

@GbaLog-

В Си нет встроенного ООП, а если его эмулировать, то смотрится это, мягко говоря, не очень.
Виртуальные функции требуют хранить указатель на базовый класс и вызов виртуальной функции базового класса обходится дороже, чем вызов обычного метода класса, т.к. приходится переходить ещё и по указателю, чтобы вызвать эту функцию.

0

@Undisputed

наоборот же virtual нужен для того что бы вызывать метод именно того класса объект которого используется(а не базового)

0

@Renji

Ну так реализуется то это все равно через указатель на метод. Просто, этот указатель упрятан под капот.

0

@Undisputed

Т.е работы с потоками использовать сишные функции вместо std::что-то там? Есть же malloc/realloc

Раз уж мы заговорили про строки, то как работает тот момент когда используется резиновая строка в С++? Выделяется какой то кусок памяти который по необходимости расширяется выделением доп. памяти?

Добавлено через 2 минуты
Так и в си вроде через указатели
http://rextester.com/VVL13734
В примере создан указатель на функцию, которому присваивается имя функции без взятия явного адреса и ошибок не происходит

0

@Renji

Для файловых потоков - да, использовать сишные аналоги. Правда, там уже не будет плюсовой универсальности "хоть std::ifstream, хоть std::stringstream, функция любой текстовый поток скушает".
В теории - есть. На практике scanf никаких malloc/realloc вызывать не будет, надеясь что принимающего буфера хватит и так. В принципе, у std::string под капотом все те же malloc/realloc, но фокус в том что std::string то как раз malloc/realloc вызовет сам. А не будет по сишной привычке надеяться "авось и так места хватит".
Ну да, в Си виртуальность достигается через указатели. Но их надо явно объявить и явно заполнить. А в плюсах все это упрятано под капот. Просто приписал virtual и все объявления и заполнения берет на себя компилятор.

1

@Undisputed

Renji,
Ясно. Спасибо!

Добавлено через 6 минут
Renji,
Кстати в Си тоже можно сделать универсальность в работе с потоками приводя их явно к FILE (не уверен, что для всех потоков). Видимо это тоже несет какой то оверхед?

0

MrGluck

Например, в С++ есть средства, соответствующих идиоме RAII. Таким образом, меньше вероятность утечки данных. И есть много средств, заменяющих магию с побитовыми операциями или работе с сырой памятью. И более жесткая проверка типов.
Взять тот же банальный пример, когда в printf/scanf передаётся переменная не того типа, что ожидалось в первом параметре функции. Или разновидности кастов типа переменных, заместо Сишного "заткнись и сделай как я сказал".

Я не говорю, что Си - плохой язык. Но у него своя специфика.

Добавлено через 1 минуту
Что мешает написать такой же код и в С++? Он вполне себе будет работать. Вы просто решили выбрать парадигму ООП. Но обсуждать выбор без конкретной задачи бессмысленно, однако стоит заметить, что у плюсов есть выбор.

Добавлено через 1 минуту
Тогда стоит смотреть на другие характеристики кода. Это опять же, зависит от задачи. Кто-то пишет программы запуска ракет, а кто-то курсач сдаёт.

1

@Undisputed

Ну тут скорее всего все основано в страховании от ошибок при разработке и многое сделано уже за разработчика и очень эффективно, да?
Не пойму, зачем нужна конкретная задача, если мы обсуждаем эффективность инструментов. Ведь программа не знает чем она является, запускателем ракет или чем то другим. А если бы и знала, она бы не "испугалась и начала работать быстрее только потому что запускает ракеты"

0

@Renji

Если вы про "приведение" вида FILE(str), то это трюк серии "возьмем зайца и запишем в документы как медведя". Даже если Си позволяет записать зайца как в медведя, этот заяц ульи с медом разорять не начнет.
И вообще, сишный аналог stringstream, это обычная сишная строка, которую заполняют snprintf. Понятное дело, к файлам она никакого отношения не имеет.

1

MrGluck

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

Можно с таким же успехом обсуждать эффективность молотка и отвёртки.

1

@Undisputed

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

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

0

@DrOffset

Зачем вот так сравнивать? Зачем тут наследование? Просто, чтобы было? Это похоже на утверждение, что обязательным атрибутом программы на С++ является наследование и классы - это совсем не так. Из непонимания этого идут дальнейшие ошибочные выводы.
И если нужно в сравнении использовать классы С++, т.е. ООП-подход, то уж, будьте добры, сранивайте его с ООП-подходом на С. Иначе в итоге сравнение выльется в ООП vs Процедурное программирование. И выше уже сказали, С++ дает выбор, если в какой-то задаче процедурный подход более эффективен, то С++ даст его использовать без проблем.
В конечном счете все сводится к тому, понимает ли программист что он делает.

0

@Undisputed

А чем не сравнение?
http://rextester.com/ZOM40340 вариант на Си
http://rextester.com/ALE79455 плюсовый вариант

Понятное дело что на hello world тестах ничего особого не будет выявлено. Просто хочу знать, если использовать тупо си с классами (только ради архитектурных решений), будет ли такой подход уступать по скорости Си если тестировать алгоритмы большого объема на двух языках просто в одном случае будут обертки в классы.
Это было бы некорректно. Мы же не обсуждаем эффективность парадигм, а эффективность работы программы.

0

MrGluck

По аналоги: что лучше - вбить гвоздь молотком или ввинтить саморез отвёрткой, если нужно повесить картину.
Разные инструменты с разными подходами.

Почему, если С++, то сразу ООП? Степанов бы очень огорчился...

0