LINUX.ORG.RU

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


0

0

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

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

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

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

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

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

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

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

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

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

>Речь о си, и NULL == 0. Тут, например:

Это частный случай поздних времён. Лично я пересекался с Си-компилятором, в котором в DOS NULL указывал на соответствующий обработчик вызова (писалась диагностика ошибки) а знакомый много писал на какой-то не-x86 архитектуре, где (void*)0 был совершенно допустимым адресом и поэтому NULL был равен 0xFFFFFFFF.

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

Конечно, NULL не обязан быть 0 и вовсе не должен быть, как я понимаю, (void *)0.

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

Хотя спор странный. Всегда лучше писать NULL, когда работаешь с поинтерами - и понятно, и надежно

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

Не зря я тебя на прошлой странице вспоминал )

Это все же отступления от стандарта, компилятор на таких архитектурах должен был 0 превращать в то самое 0xFFFFFFFF или адрес обработчика, а NULL по-прежнему был бы 0.

Из стандарта C99:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. (55)

55) The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant

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

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

Только tk-шникам не говори.

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

Это нулевой указатель не обязан быть 0, о чем и говорит Крон, а NULL обязан.

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

> Только tk-шникам не говори.

они ж прячутся вместе со своей гуйней( стыдно наверное ) - так что не скажет

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

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

Гыгы, и что бы ты потом делал на этом smalltalk? =)

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

> В Александреску был пример.

Александреску - это акробатика, а не программирование.

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

>Из стандарта C99

Вот-вот. А то, про что я говорю - это было заметно до того. В 1999-м, как бы, DOS уже умер ;)

...

Собственно, я в 1999-м уже с Си/Си++ завязывал в пользу Perl'а :)

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

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

Кстати, чуть ли не в последней редакции K&R, в комментариях, сказано, что приводить руками результат malloc-а плохо. Правда они не аргументировали почему.

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

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

Внимание! Шаблоны не базовый принцип ООП, как и множественное насоедование.

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

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

А если нужна и скорость и ООП что ты будешь делать?

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

Однако си прост как бревно

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

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

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

еще из граблей я припомню сравнение указателей на разные массивы и невозможность сравнивать указатели на функции (а в уже с++ можно, вот прикол)

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

>А что, сейчас сишные библиотеки больше нельзя использовать в Си++?

Сишные библиотеки можно использовать везде: и в питоне, и в хаскеле, и в лиспе. Что с того? А плюсовые врапперы тоже стоит называть полноценными бибилиотеками (например, gtkmm)?

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

> предположим у меня ветвь сравнений

ветвь сравнений

Что это?

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

>Сишные библиотеки можно использовать везде: и в питоне, и в хаскеле, и в лиспе. Что с того?

Насколько я понимаю, в Хаскелле и Лиспе либы также, как и в Питоне, требуют обёрток. Си++ же может (мог?) вызывать Си-шные либы прямо. Без лишних телодвижений. Как родные.

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

Нет. Основные реализации Haskell и Lisp (а также SML) в машинном коде умеют вызывать C напрямую. Нужна сигнатура (а не обертка). А вот OCaml такого, увы, не может.

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

>Только в C++ (и в D) они линкуются без костылей.

В Lisp с его FFI надо только объявить все структуры данных и функции. Костылей тоже ноль. Например, биндинг labmbda-gtk генерируется в (полу)автоматическом режиме из сишных хидеров.

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

>Си++ же может (мог?) вызывать Си-шные либы прямо. Без лишних телодвижений. Как родные.

False. Попробуй забудь extern «C» { ... } в заголовочном файле. И, вроде, если у структуры будут забавные имена полей вроде new или template, то тоже будут определенные неудобства.

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

Повесить автора за яйца и не будет больше new и template писать. А extern «C» это не проблема, так как в него можно обернуть #include

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

Не такое же. Это всего 10 символов на написание которых ты потратишь менее секунды. Кстати я знаю только одну библиотеку в .h'никах которой нет extern «C». Это ffmpeg. Но это не удивительно. Эти ушибленные на всю голову специально C99 используют, чтобы нельзя было собрать в студии.

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

>Эти ушибленные на всю голову специально C99 используют

Интересно, а о разработчиках ядра, которые гнутые расширения используют, ты тоже думаешь как об «ушибленных на всю голову»? C99 дает ряд приятных вещей по сравнению с C89, и ты предлагаешь отказаться от них, потому что у тебя дома что-то в семерочке не соберется?

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

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

Пользуюсь, конечно, особенно когда нужно какие-то параметры сохранять (mmap) или «делиться» значительными объемами информации с неродственными приложениями (тот же mmap или shared memory).

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