LINUX.ORG.RU

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


0

0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

unsigned ★★★★
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от unsigned

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от 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 ★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от 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

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

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

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

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

...

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

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

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

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

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

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

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

Что это?

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