LINUX.ORG.RU

C vs C++ по скорости разработки


0

0

Заинтересовал меня этот вопрос.

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

Если реально посмотреть на вещи, какие фичи С++ дают возможность писать код быстрее, чем на С?

1. ООП? Базовые принципы ООП довольно легко реализовываются на чистом С. Правда, прийдется попрыгать с наследованием (не включением), хотя здесь помогут -fsm-extensions.

2. Большее число библиотек под С++? Я не программист ынтерпрайза, поэтому в _глобальных_ масштабах не мыслю, но мне показалось, что под С есть не меньшее количество либ, чем под плюсы.

3. Исключения? Везде, где я читал про них как киллер-фичу С++ по отношению к С, говорится про то, что код проверок ошибок с исключениями выглядит красивее, лучше, меньше по размеру и т.п. Здесь я также полагаю, что это чушь, ибо если код проверки написан на С (используя возвращаемый код ошибки функции), то такой же код проверки на С++ будет иметь _такой же_ размер - это если вопрос касается размера. А на счет удобочитаемости - так по мне, проверки на С гораздо читабельнее.

4. Namespaces. Это, наверное, единственное, что меня прельщает в плюсах по сравнению с С. Хотя, в С этот недостаток устраняется «писанием» префикса типа some_namespace__*. Правда, в плюсах есть using namespace, что ликвидирует потребность городить тонны имен namespac'ов. Так что, имхо, это единственный плюс С++.

5. Более точная типизация? Возможно это плюс, но никогда не сталкивался на С с ошибками подобного рода (наверное, я просто не кулхацкер).

Что я еще мог опустить, пишите в коментах. Интересно обсудить этот вопрос без срача, школоло и троллинга.

★★
Ответ на: Ликбез от different_thing

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

Ну да. Еще проверка типов.

Интересно, по какому критерию

Вроде у gcc -finline-limit, ну и вообще man gcc | grep inline.

unsigned ★★★★
()
Ответ на: комментарий от tailgunner

> Ага. Изобрести, например, объектную систему (как сделали в GTK) - как раз «чуть больше».

ССЗБ, раз хотели писать ОО проект не на ОО языке. C тут не виноват.

Да. Многословный, но простой.

Бог с ним, что многословный, но нафига мне создавать классы, чтобы напечатать строку? Лишняя перегруженность языка к добру не приведет. В C++ в этом плане чуть лучше, но проблема всё равно есть.

different_thing
()
Ответ на: комментарий от different_thing

>> Ага. Изобрести, например, объектную систему (как сделали в GTK) - как раз «чуть больше».

ССЗБ, раз хотели писать ОО проект не на ОО языке. C тут не виноват.

Бгг. Они не «ОО-проект» хотели, а GUI toolkit. Назовешь мне хоть парочку GUI toolkit,'ов, которые сделаны _не_ в ООП (только не надо Fudgets и прочую функциональщину).

Блин, даже ядро написано в значительной мере в ОО-стиле.

Да. Многословный, но простой.

Бог с ним, что многословный, но нафига мне создавать классы, чтобы напечатать строку?

Судить о языке по хелловорлду - это сильно :)

Лишняя перегруженность языка к добру не приведет. В C++ в этом плане чуть лучше, но проблема всё равно есть.

Если что, в Си++ есть весь Си. Не нравятся какие-то конструкции - не используй.

tailgunner ★★★★★
()
Ответ на: комментарий от Legioner

Ссылку в студию

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

Потому что компилятор в случае С++ понимает, что делает программист, у него больше пространства для оптимизаций.

По-моему, у программиста еще больше, причем для оптимизаций более принципиальных. Если он сам понимает, что делает ) Но, конечно, лишний труд.

unsigned ★★★★
()
Ответ на: комментарий от unsigned

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

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

Legioner ★★★★★
()
Ответ на: комментарий от tailgunner

> Бгг. Они не «ОО-проект» хотели, а GUI toolkit. Назовешь мне хоть парочку GUI toolkit,'ов, которые сделаны _не_ в ООП (только не надо Fudgets и прочую функциональщину).

Зачем мне это? Я же не говорю, что объектно ориентированный gui toolkit это плохо. Тут задача подразумевает использовать именно ООП. Также как если бы ты хотел какой-нибудь игровой движок написать. Тут по логике можно зависимость одного объекта от другого представить. Или какие-то абстрактные классы и их потомков, которые решают родительскую задачу своими методами. А в хеллоуворлде таких связей представить нельзя.

Судить о языке по хелловорлду - это сильно :)

Если что, я даже как-то какую-то прогу на яве написал. Что-то типа hex-редактора.

different_thing
()
Ответ на: комментарий от tailgunner

я практически ничего не знаю о С++, но, судя по форуму и поднимаемым вопросам это просто какой-то нереальный ппц. Даже просто сравнив объёмы faq по С и C++ сразу создаётся впечатление что C++ это какой-то мегамонстр.

А что в C сложного? Есть там непростые платформозависимые вопросы типа endianess и битовые операции или рфзмер int, а так сложного не припомню(это не значит что нельзя сделать сложный код).Я говорил с разработчиками ядра ауриги(на собеседование ходил :)), они сказали K&R достаточно для понимания языка и что C они считают простым :). K&R я осилил, могу ли я считать себя человеком понимающим что такое C?

true_admin ★★★★★
()

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

Неправильно. По уму, C надо использовать при более-менее низкоуровневом программировании, а C++ не использовать вообще.

ООП? Базовые принципы ООП довольно легко реализовываются на чистом С.

Во-1, это фигня, во-2, не надо этого делать.

мне показалось, что под С есть не меньшее количество либ, чем под плюсы.

Ну, вопрос не только в количестве. К сожалению, например, Хавок есть только под C++.

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

Ты вообще в курсе, что такое исключения? Исключения - способ НЕ возвращать код ошибки вообще.

Более точная типизация?

Хреновая в плюсах типизация. Впрочем, в C не лучше.

Miguel ★★★★★
()
Ответ на: комментарий от unsigned

Я читал faq, по сравнению с faq C++ он простой и короткий :). Ты не поверишь но, например, тот же python ох уж как не прост. Я вообще не верю что бывают простые языки программирования.

true_admin ★★★★★
()
Ответ на: комментарий от linuxfan

имитация параметризованных типов (особенно для контейнеров).

Fixed.

Miguel ★★★★★
()
Ответ на: комментарий от KRoN73

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

Значит, у тебя не было ни одной серьёзной задачи.

Miguel ★★★★★
()
Ответ на: комментарий от Reset

C++ тоже, ибо альтернатив пока не видно. Точнее есть, Ди называется, но оно пока в зачаточном состоянии.

Вообще, правильно сделанный C++ - это OCaml.

Miguel ★★★★★
()
Ответ на: комментарий от Eddy_Em

И я не считаю комбинации calloc - free траханьем, по сравнению с описанием ненужных классов и их конструкторов/деструкторов

Гм. То есть, в C ты не пользуешься структурами?

Miguel ★★★★★
()
Ответ на: комментарий от tailgunner

1. Для решения моих задач он не нужен.

2. Было бы мне нужно ООП, я бы изучил, например, smalltalk) Потом бы уже выбирал, что лучше. C++ как-то слишком «тяжеловесный», в том же питоне по-моему ООП реализованно лучше.

different_thing
()
Ответ на: комментарий от true_admin

А что в C сложного?

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

Есть там непростые платформозависимые вопросы типа endianess и битовые операции или рфзмер int

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

Сложность Си в том, что, для понимания программы, ты должен понимать, что пишешь почти на ассемблере. Я припоминаю прикольный тред на ЛОРе про конкатенацию строк, который показал, что люди этого не понимают :)

K&R я осилил, могу ли я считать себя человеком понимающим что такое C?

Да.

tailgunner ★★★★★
()
Ответ на: комментарий от different_thing

> в том же питоне по-моему ООП реализованно лучше.

Собственно влияние smalltalk'а

different_thing
()
Ответ на: комментарий от different_thing

> 1. Для решения моих задач он не нужен.

Я, конечно, не знаю, что за задачи ты решаешь, но фраза «не нужен» как бы намекает на неправильный подход к выбору.

2. Было бы мне нужно ООП, я бы изучил, например, smalltalk)

Сравнение Си++ со Смоллтоком и Питоном доставляет :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Блин, даже ядро написано в значительной мере в ОО-стиле.

Ты про драйверы устройств ? Так природа у них такая а не потому что ядро в ООП стиле написано :)

bengan
()
Ответ на: комментарий от Miguel

> Ты вообще в курсе, что такое исключения? Исключения - способ НЕ возвращать код ошибки вообще.

Значит, у тебя не было ни одной серьёзной задачи.


Гм. То есть, в C ты не пользуешься структурами?


Вот и специалисты заявились.

bk_ ★★
() автор топика
Ответ на: комментарий от true_admin

по сравнению с faq C++

В сравнении с плюсами - конечно, C прост и красив. Но все равно он коварнее, чем это видно по K&R и другим книгам, где вообще любят нарушать стандарт в нюансах. Только недавно, например, читал кодинг-стандарт, где утверждалось, что некорректно/непереносимо писать «if(p)», а нужно «if(p != NULL)». Мелочь, конечно, но стандарт не осилен.

Я вообще не верю что бывают простые языки программирования.

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

unsigned ★★★★
()
Ответ на: комментарий от tailgunner

Я ж не целиком их сравниваю.

Я, конечно, не знаю, что за задачи ты решаешь, но фраза «не нужен» как бы намекает на неправильный подход к выбору.

http://www.linux.org.ru/forum/development/4968593/page1#comment-4970725

Вот это, отчасти, и моя проблема. Дай, что почитать, чтобы знать, как решить её в C++

different_thing
()
Ответ на: комментарий от bengan

>> Блин, даже ядро написано в значительной мере в ОО-стиле.

Ты про драйверы устройств ?

Не только.

Так природа у них такая

У всего природа такая - у файлов, инодов, адресных пространств, протоколов, и даже у ftrace. В общем, grep -h -E «^struct .*_(ops|operations) {» *.h в linux/include поможет.

а не потому что ядро в ООП стиле написано :)

Как скажешь.

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

> то некорректно/непереносимо писать «if(p)», а нужно «if(p != NULL)»

Всегда так делаю. Быдлокодерство, конечно, но привычка. Что поделать)

Ещё пишу всегда

struct foo *bar = (struct foo*) malloc (sizeof (struct foo));

Хотя можно

struct foo *bar = malloc (sizeof (struct foo));

Хоть malloc возвращает void*, но тип вроде как сам преобразуется в struct foo*. Но тут опять привычка делать это явно.

different_thing
()
Ответ на: комментарий от different_thing

> http://www.linux.org.ru/forum/development/4968593/page1#comment-4970725

Вот это, отчасти, и моя проблема. Дай, что почитать, чтобы знать, как решить её в C++

Речь шла о сравнении Си и Си++ для решения некой задачи. Я правильно понимаю, что этой задачей оказалась реализация мультиметода?

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

> читал кодинг-стандарт, где утверждалось, что некорректно/непереносимо писать «if(p)», а нужно «if(p != NULL)».

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

tailgunner ★★★★★
()
Ответ на: комментарий от different_thing

Я не знаю, как реализовать мультиметоды в Си++. Но, если бы встала такая задача, я бы начал с ассоциативного массива функторов. Как ты думаешь, на Си или Си++ это было бы удобнее реализовать?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Тут ты конечно победил)

Блин, что-то не о том я спорил, когда тот пост писал. Кажется, о том, что ООП не всегда бывает полезным. А ща о чём? Всё, мозги надо пойти проветрить)

different_thing
()
Ответ на: комментарий от tailgunner

Я и имею в виду, что это (а также «if(p != 0)») ровно одно и то же, но автор стандарта этого не знал. Один из устойчивых мифов «простого» языка.

unsigned ★★★★
()
Ответ на: комментарий от unsigned

> а также «if(p != 0)»

А вот так писать не следует по вполне очевидным причинам :) Запретить _такое_ в стандарте кодирования - вполне разумно.

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

Может компиляторы есть, которые этого не знают?

Кстати, а uint8_t uint16_t итд. входят в стандарт C++? А то слышал, что якобы поделия от MS (visual studio) и знать не знают о таких типах

different_thing
()
Ответ на: Ликбез от different_thing

> Хм, правильно я понимаю, что inline функции - те же макросы, только их аргументы вычисляются прежде, чем передаться этой функции.

Неправильно понимаешь. Ты с inline-функцией не сделаешь ##, например.

anonymous
()
Ответ на: комментарий от true_admin

>> Ассемблер как язык тоже прост до неприличия )

тут не поспоришь :)

Можно поспорить... представь себе RISC ассемблер для процессора с delay slots и несколькими исполняющими устройствами (например, Itanium). Простота ассемблера - это простота brainfuck.

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

> Ээ... А каковы эти очевидные причины?

В «if (p == 0)» начинаешь думать, является p указателем или целым числом.

tailgunner ★★★★★
()
Ответ на: комментарий от Miguel

>Значит, у тебя не было ни одной серьёзной задачи.

Возможно. Но столь же вероятно и то, что ты не пытался хорошо подумать в задачах своих :)

KRoN73 ★★★★★
()
Ответ на: комментарий от different_thing

Может компиляторы есть, которые этого не знают?

Может конечно, вроде Крон что-то такое вспоминал, но они, я надеюсь, вымерли.

uint8_t uint16_t

Википедия говорит, stdint.h появился в C99, не знаю, что с C++. Оттуда же:

stdint.h (for C), and stdint.h and cstdint (for C++) can be downloaded or quickly created if they are not provided on a given system.

unsigned ★★★★
()
Ответ на: комментарий от Miguel

> Вообще, правильно сделанный C++ - это OCaml.

Тоже иногда так думаю.

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

> if(p == 0) - указатель. if(i == 0) - число.

Называть p указатели, а i - счетчики - это тоже кодинг стандарт. Кстати, if (v) с целочисленной переменной - это некрасиво.

tailgunner ★★★★★
()
Ответ на: комментарий от unsigned

Да. Обычно все c хидеры есть в C++ было foo.h стало cfoo.

Вот только стандарт это или нет - хз.

different_thing
()
Ответ на: комментарий от tailgunner

Насчет целочисленной переменной соглашусь, я только по первости так старался писать. У меня было ощущение, что это и работать будет быстрее ) Еще в чьем-то коде видел if(a - b).

А с указателями мне нравится краткая форма. Но это дело вкуса.

unsigned ★★★★
()
Ответ на: комментарий от unsigned

>if(p == 0) - указатель. if(i == 0) - число.

А какой смысл проверять p == 0 для указателя? NULL в Си != 0 в общем случае. Или (мне лениво вверх по ветке читать) речь о Си++?

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.