LINUX.ORG.RU

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


0

0

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

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

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

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

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

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

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

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

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

★★

Забыл шаблоны, перегрузку функций, операторов, STL, автоматический вызов деструкторов при выходе из области видимости. А при использовании Glib::RefPtr получается почти сборка мусора.

vertexua ★★★★★
()

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

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

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

Неправильно полагаешь. Hint: попробуй, поймай неправильный return-code у функции не на месте вызова, а выше по колл-стеку.

Что я еще мог опустить, пишите в коментах.

Шаблоны и иже с ними. Смарт-поинтеры. STL. Буст

yoghurt ★★★★★
()

Можно также сравнить гусеничный трактор и подводную лодку по скорости доставки грузов. Оценить все «за» и «против».

anonymous
()

И, да

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

Fixed

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

Во-первых ты уже написал.

Во-вторых срач начинается когда один или два языка рекомендуют для всех целей.

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

Про «один или два языка для всех целей» топикстартер вбросил ещё в оригинальном посте.

При всей моей нелюбви к пистону, я считаю [Python + C] универсальным выбором, который покрывает 80% задач - прикладных и не очень.

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

Кто-то прийдет и скажет Ruby, кто-то C#. Я почти все пишу на Java. Ну и обязательно лисперы подтянутся. В итоге срач.

vertexua ★★★★★
()

на Си надо совершать слишком много возни, которая может быть автоматизирована средствами Си++

Reset ★★★★★
()

Был бы у С++ стандарт ABI (и главное хороший и простой стандарт), то можно было бы смело выбрасывать С.

vertexua ★★★★★
()

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

Автоматические вызовы деструкторов (позволяют устранить большинство проблем с утечками ресурсов), параметризованные типы (особенно для контейнеров).

3. Исключения?

Начет исключений: черт его знает, как насчет красивостей, а вот гарантированный вызов деструкторов при их использовании замечательно страхует от утечек ресурсов.

2. Большее число библиотек под С++?

Очень спорный момент. Мне почему-то кажется, что число библиотек примерно одинаково, а то и с перевесом в сторону C, но у меня лично создалось впечатление, что сишные библиотеки более вылизанные чтоли.

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

Ну бывает при смене интерфейса функции struct foo* заменяется на struct bar* — такой варнинг на C можно и проморгать.

Я лично использую C++, когда надо сделать что-то очень быстро, а C — когда качественно. Качественно на C++ писать сложнее.

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

> Я лично использую C++, когда надо сделать что-то очень быстро, а C — когда качественно. Качественно на C++ писать сложнее.

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

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

> Знатоки ITT.

Поясни

Простых ABI не бывает.

Я и не говорил что он будет. Итог: С еще долго не выбросят. В отличии от С++.

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

Ну идея неплохая, просто кастует срач

vertexua ★★★★★
()

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

зачем «легко реализовывать», если это уже есть в С++? некоторые вещи к тому же ни фига не просто реализовываются (шаблоны и др)

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


почти все библиотеки С можно использовать в С++. Явный extern «C» спасёт от авторов библиотек-плюсофобов

3. Исключения?


Используются мало

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

>>> Был бы у С++ стандарт ABI

Знатоки ITT.

Поясни

У Си++ есть стандарт ABI.

Простых ABI не бывает.

Я и не говорил что он будет.

Ты хотел простой ABI. Больше не хочешь?

Итог: С еще долго не выбросят. В отличии от С++.

Ахренеть логика. «Скажи мне, кудесник, любимец богов» (с) - за сколько лет до Си выбросят Си++?

tailgunner ★★★★★
()

на С как-то пишется быстрее (если без ООП), но что-то относительно небольшое. когда здоровое - на С++. дольше, пока продумаются объекты, связи. зато потом всё вмиг по кубикам собирается. и легко разобраться в коде (для решения конкретной задачи на готовом чужом коде), особенно если не документирован (и нормально написан :) ). С++ легче поддерживать, легче передавать-принимать проекты. всё это ИМХО :)

anonymous
()

На С++ разрабатывать быстрее, чем на С. На многих языках быстрее, чем на С++.

По скорости хорошо написанная программа на С++ такая же или быстрее, чем на С.

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

> У Си++ есть стандарт ABI.

Так что, можна уже сейчас собирать на GCC, MSVS, Intel и Sun компиляторах разные модули одного и того же приложения? Можно компилировать С++ библиотеки разными компиляторами и они вместе заработают? Не знал, не знал...

Ты хотел простой ABI. Больше не хочешь?

Могу ли я хотеть и знать что этого не будет? Простой - это ABI языка С, который сам нереально простой. А вот С++ достаточно сложный сам по себе, потому...

за сколько лет до Си выбросят Си++?

Откуда я знаю, кудесник, еще больший любимец богов.

vertexua ★★★★★
()

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

Больше не читай. Я серьёзно.

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

>> У Си++ есть стандарт ABI.

Так что, можна уже сейчас собирать на GCC, MSVS, Intel и Sun компиляторах разные модули одного и того же приложения?

А собрать в одном приложении модули, использующие POSIX, Carbon и WinAPI ты не хочешь?

Простой - это ABI языка С, который сам нереально простой.

«Тот, кто думает, что у Си простой ABI, просто не видел varargs.h на RISC-платформах» (c) Ну и насчет нереальной простоты Си - стандарт почитай. Он толстый, помимо всего прочего.

за сколько лет до Си выбросят Си++?

Откуда я знаю, кудесник, еще больший любимец богов.

Тогда перестань пророчествовать о том, что Си++ выбросят раньше Си.

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

На С++ разрабатывать быстрее, чем на С.

Если в проекте нельзя выделить четко разделенные объекты, имеющие однозначную иерархию, на сях разрабатывать будет быстрее ;)

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

> Неправильно полагаешь. Hint: попробуй, поймай неправильный return-code у функции не на месте вызова, а выше по колл-стеку.

Чушь

anonymous
()

Все, что хотел для себя узнать, узнал. Спасибо.

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

>А вот с тем же множественным наследованием придется повозиться.

А его уже принуждают использовать? :)

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

>Если в проекте нельзя выделить четко разделенные объекты, имеющие однозначную иерархию ...

... то при разработке проекта была где-то допущена ошибка в дизайне. Скорее всего нужен рефакторинг.

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

>>2. Большее число библиотек под С++?

Очень спорный момент. Мне почему-то кажется, что число библиотек примерно одинаково


А что, сейчас сишные библиотеки больше нельзя использовать в Си++? Я, понимаю, что уже лет 10 не программировал на Си++, но неужели всё изменилось так сильно? :)

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

>Можно также сравнить гусеничный трактор и подводную лодку по скорости доставки грузов. Оценить все «за» и «против».

Я бы предложил сравнить, скажем, «Девятку» и «Газель». Это ближе к истине. Гусеничный трактор и подлодка - это, скорее, Си против Пролога :)

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

... то при разработке проекта была где-то допущена ошибка в дизайне. Скорее всего нужен рефакторинг.

У меня нет ни одной задачи, где можно было бы выделить объекты с четко разграниченной иерархией. А если нет возможности использовать перегрузку операций, наследование и прочие прелести С++, то лучше, ИМХО, пользоваться чистым С.

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

>У меня нет ни одной задачи, где можно было бы выделить объекты с четко разграниченной иерархией.

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

А если нет возможности использовать перегрузку операций


Удивительно, но в массе популярных и мощных языков перегрузки нет вообще :)

наследование


Я, вот, совсем недавно не представлял, как без множественного наследования обойтись: http://www.linux.org.ru/forum/development/2041488

Но потом, после ряда раздумий и размышлений, на меня сошло просветление и я понял, что наследование вообще вещь в ООП не обязательная :) Хотя не стал фанатствовать и использую его местами для облегчения жизни. Хотя и весьма ограниченно теперь.

и прочие прелести С++, то лучше, ИМХО, пользоваться чистым С.


Ну да. Тем более, что на чистом Си можно писать в ООП-стиле :) Но зачем, когда есть Си++, подходящий для этого лучше?

KRoN73 ★★★★★
()

Шаблоны в C++ довольно нужная вещь, предотвращает дублирование кода, на С нет ничего подобного...да и обширная STL помогает не плохо.

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

>на С нет ничего подобного

Частично макросы. На ЛОРе даже как-то ходила ссылка на реализацию аналога std::map на макросах

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

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

Тем не менее ООП хорош не везде. Единственная книга на русском по питону, которая у меня есть - книга Романа Сузи «Язык программирования Python».

Там написанно:

Также спорна большая гибкость объектных программ к изменениям. Она зависит от того, вносится ли новый метод (для серии объектов) или новый тип объекта.

Жаль, не могу найти в интернете. Смысл таков - что при внесении нового метода, который работает с несколькими классами придется изменять код каждого класса, когда как в том же C можно написать 1 функцию для работы с разными типами данных (передавая например указатель на них типа void* и указывая как-то тип её поведения).

Бред я написал? Что радует, в том же common lisp - этой проблемы нет, там есть обобщенные функции

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

Но потом, после ряда раздумий и размышлений, на меня сошло просветление и я понял, что наследование вообще вещь в ООП не обязательная :)

О, это как это необязательная?

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

Гвидо ван Россум, бывает, тоже всякую фигню пишет. Что с того, что кто-то что-то там написал? Сочинить и на хаскеле можно кривой неизменяемый код. Здесь дело не столько в инструменте, сколько в мастере.

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

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

different_thing
()

Вообще, на C++ нельзя писать. Ну, физически. Можно писать на частичной реализации плюсов в gcc, например. на _частичной_. Т.е. на херне, вот.

Алсо, жду няшку-r в тред

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

>Я даже дозрел до их использования в PHP :)

Помнится, ты утверждал что они не нужны, причем упорно. Что таки поменялось?:)

anonymous
()

Я вот никогда не понимал таких вопросов. Пиши на С++, так как С почти подмножество С++. Если ты пишешь на С++, то тебя никто не заставляет весь код обкладывать тоннами шаблонов, классов и исключений. Когда возникнет необходимость в этих возможностях, тогда ими и воспользуешься. Есть лишь отдельные, особые случаи, когда лучше писать именно на С. ИМХО весь этот тред только ради троллинга.

pathfinder ★★★★
()

Думаю по скорости плюсы будут однозначно быстрее, но проще писать полюбому на С.

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