Системное/низкоуровневое программирование: C vs C++

← →
Cyrax © (2006-12-10 11:52) [0]

Действительно ли C++ берёт верх над C в системном программировании.

Некоторые фирмы (может, и многие), которые писали на чистом C, скажем, драйвера или программы прошивки для всяких устройств (то бишь системное низкоуровневое программирование), сейчас переходят на C++. Потому что сейчас разницы практически нет, что мы напишем прогу с использованием классов и конструкторов на C++, что с использованием переменных и инициализирующих функций (вместо конструкторов) на чистом C. А вернее, машинный код после компиляции C-программы ничуть не быстрее и не короче, чем после компиляции аналогичной C++-программы (а эти параметры - скорость и размер кода - в системном программировании играют ведущую роль). Раньше то, возможно, и была. Но сейчас компиляторы и оптимизаторы сделали своё дело.
Это о скорости выполнения кода и о его размере. Что касается простоты, удобства и эффективности, то верх берёт, однозначно, C++...

← →
Anatoly Podgoretsky © (2006-12-10 12:02) [1]

> Cyrax (10.12.2006 11:52:00) [0]

С каких это пор ООП выполняется быстрее, чем линейная программа.

← →
Cyrax © (2006-12-10 12:17) [2]

>Anatoly Podgoretsky © (10.12.06 12:02) [1]
Не быстрее, а не медленнее. Не забываем про компиляторы и оптимизаторы...

← →
Celades © (2006-12-10 12:20) [3]

> С каких это пор ООП выполняется быстрее, чем линейная программа.

А с каких пор наоборот?
Всё зависит от конкретного случая. Если взять с-style с передачей некого хендла в функцию, то чем это не указатель this?

← →
Cyrax © (2006-12-10 12:25) [4]

Любой объектной структуре соответствует линейная структура. И нативный код этой линейной структуры не будет короче и эффективнее только из-за того, что её исходный код менее высокоуровневен, чем код объектной структуры.
Если рассмотреть нативный код для двух случаев, то он, скорее, практически не будет отличаться...

← →
Германн © (2006-12-10 12:43) [5]

> Cyrax © (10.12.06 12:25) [4]

Хоть бы ИМХО ставил. Всё бы не так глупо звучало.

← →
Cyrax © (2006-12-10 12:50) [6]

>Германн © (10.12.06 12:43) [5]

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

Так ?

← →
Германн © (2006-12-10 13:02) [7]

> Cyrax © (10.12.06 12:50) [6]
>
> >Германн © (10.12.06 12:43) [5]
>
> Поставил смайлик или имхо - новейшая теория, заслуживающая
> уважения.
> Не поставил ничего - глупое высказывание, на которое стрёмно
> глядеть...
>
> Так ?
>

Нет, не так.
Но когда пишешь:
> Cyrax © (10.12.06 12:25) [4]
>
> Любой объектной структуре соответствует линейная структура.
>

то "имхо" переводит данное высказывание из разряда "бреда" в разряд "сомнение".

← →
Юрий Зотов © (2006-12-10 13:24) [8]

> Cyrax © (10.12.06 12:25) [4]

Объектной структуре, как правило, соответствует ИЗБЫТОЧНАЯ (для данной задачи) линейная структура. В силу самодостаточности объектов.

Поэтому нативный код линейной структуры будет короче и эффективнее.

← →
Cyrax © (2006-12-10 14:09) [9]

>Германн © (10.12.06 13:02) [7]
>то "имхо" переводит данное высказывание из разряда "бреда" в разряд "
>сомнение".

...а смайлик - дальше в разряд общепризнанного файкта... забавное продвижение...

И где тут бред:
"Любой объектной структуре соответствует линейная структура"

← →
Cyrax © (2006-12-10 14:15) [10]

>Юрий Зотов © (10.12.06 13:24) [8]
>Объектной структуре, как правило, соответствует ИЗБЫТОЧНАЯ (для
>данной задачи) линейная структура. В силу самодостаточности объектов.

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

И вообще, цель ветки - не доказать абсолютную правоту предположения, а определить доводы, опровергающие это предположение, и опровергнуть несостоятельные контрдоводы...

← →
Юрий Зотов © (2006-12-10 14:37) [11]

> Cyrax © (10.12.06 14:15) [10]

> Не забываем про оптимизаторы...

При чем тут оптимизаторы? Они что, отменяют компиляцию служебного кода объектов?

> ... после которых как раз и получаем нативный код...

ПОСЛЕ которых?

Извините, а Вы вообще понимаете, что такое оптимизаторы и что такое нативный код?

← →
oxffff © (2006-12-10 14:43) [12]

Виртульные функции.
Call [eax+] должен выполняться дольше, чем call someAddres.

Self указатель.
а зависимости от Calling Conventions
будут либо
push self,
либо push [pself],
либо mov register,Self

Но если учитывать возможности современных процессоров.
Но разница постоянно нивилируется.

Конечно все зависит от задачи.

← →
oxffff © (2006-12-10 14:49) [13]

Под возможностями современных процессоров понимать
Возможности

Извлечение операнда из памяти и переход и т.д.

← →
Cyrax © (2006-12-10 15:10) [14]

>Юрий Зотов © (10.12.06 14:37) [11]
>При чем тут оптимизаторы?

При том, что оптимизаторы код избыточной линейной структуры оптимизируют...

>Они что, отменяют компиляцию служебного кода объектов?
При чём тут служебный код объектов ?
В нативе от него и следа не остаётся...

>ПОСЛЕ которых?

После тех, которые оптимизируют промежуточный (и не только) код.
И вообще, "после" не следует понимать как "непосредственно после". Или хочется рассмотреть все этапы компиляции от лексического до компоновочного ?

>Извините, а Вы вообще понимаете, что такое оптимизаторы и что такое
>нативный код?
А Вы понимаете, что делают оптимизаторы и как они связаны с нативным кодом ?

← →
Юрий Зотов © (2006-12-10 15:14) [15]

> Cyrax © (10.12.06 15:10) [14]

> При чём тут служебный код объектов ?
> В нативе от него и следа не остаётся...

Разговор закончен. До свидания.

← →
oxffff © (2006-12-10 15:16) [16]

> При чём тут служебный код объектов ?
> В нативе от него и следа не остаётся...

Не торипитесь.
А вы знаете почему ID Software писала на С, а не на С++.
А все потому же.
Так что следы есть и пока их полностью не избежать.

← →
Cyrax © (2006-12-10 15:22) [17]

>Юрий Зотов © (10.12.06 15:14) [15]
>Разговор закончен. До свидания.

Понятно. Видимо, под "служебным кодом" вы подразумевали что-то иное (что остаётся в нативе)...

>oxffff © (10.12.06 15:16) [16]

Что это за следы (следы служебного кода объектов), от которых невозможно избавиться с помощью компилятора C++ ?

← →
oxffff © (2006-12-10 15:28) [18]

> >oxffff © (10.12.06 15:16) [16]
>
> Что это за следы (следы служебного кода объектов), от которых
> невозможно избавиться с помощью компилятора C++ ?

см oxffff © (10.12.06 14:43) [12]

Вам бы не мешало посмотреть все под отладчиком.
Тогда все станет на свои места.

← →
atruhin © (2006-12-10 15:34) [19]

Тебе знакомо понятие RTTI? Cjdtne. jpyfrjvbnmcz vyjuj yjdjuj epyftim!

← →
atruhin © (2006-12-10 15:35) [20]

Извиняюсь. Глюк. Читать так:
Советую ознакомиться много нового узнаешь!

← →
oxffff © (2006-12-10 15:38) [21]

> atruhin © (10.12.06 15:35) [20]
> Извиняюсь. Глюк. Читать так:
> Советую ознакомиться много нового узнаешь!

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

← →
oxffff © (2006-12-10 15:39) [22]

> atruhin © (10.12.06 15:35) [20]
> Извиняюсь. Глюк. Читать так:
> Советую ознакомиться много нового узнаешь!

Надеюсь это не ко мне относилось

← →
atruhin © (2006-12-10 15:46) [23]

> [22] oxffff © (10.12.06 15:39)

Нет конечно! Для автора.

> Потому что можно отключить генерация RTTI

Можно, но это сужает возможности (вообще RTTI я вспомнил для примера).
Тогда да, остатется разная методика вызовов и расход памяти на таблицы
виртуальных методов.

← →
Piter © (2006-12-10 15:55) [24]

Cyrax © (10.12.06 11:52)
а эти параметры - скорость и размер кода - в системном программировании играют ведущую роль

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

Клиент хочет получить продукт сейчас и пусть эта железа будет стоить на $10 больше. А не через год и подешевле.
Критичным становятся именно ВРЕМЯ разработки для вывода на рынок. Сегодня это топовый продукт, завтра уже забытый.

Да, чем более массовое производство, тем оплата программиста принимает все меньшую долю в стоимости конкретного устройства, но практика такова, что железка сейчас стоит дешево, ОЧЕНЬ дешево. Себестоимость мобильных телефонов в китае зачастую в районе $5-$10. На выходную стоимость продукта в стократно большей степени влияет маркетинг, положение на рынке и прочее, и прочее.

Поэтому на C++ просто быстрее писать, чем на C сложные продукты, да и более надежно, легче осуществлять поддержку, модернизацию. Это и ценно.

А вычислительные возможности отходят на второй план. В мобильных телефонах вон уже повсеместно Java используется - и все ок.

← →
Sergey Masloff (2006-12-10 16:32) [25]

Piter © (10.12.06 15:55) [24]
Это на основе изучения рекламных проспектов?

← →
Piter © (2006-12-10 16:41) [26]

Sergey Masloff (10.12.06 16:32) [25]

Сергей, может не будем страдать фигней? Вы где-нибудь видели такие рекламные проспекты? Про C++, про C, про стоимость разработки?

Ну и давайте не будет бредить.

Ессли не согласен - выскажи свое мнение и что не так.

← →
Юрий Зотов © (2006-12-10 17:29) [27]

> Piter © (10.12.06 16:41) [26]

> может не будем страдать фигней?
> давайте не будет бредить.

Действительно, давайте не будем страдать фигней и бредить. Еще давайте выбирать выражения. Тоже очень неплохо было бы.

> Ессли не согласен - выскажи свое мнение

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

> что не так

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

← →
Sergey Masloff (2006-12-10 17:48) [28]

Piter © (10.12.06 15:55) [24]
>вот это уже становится неправдой. Сейчас время программистов >становится дороже,
Это точно из проспекта. Машина на которой я работаю стоит больше чем моя зарплата за 50 лет.

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

>Клиент хочет получить продукт сейчас и пусть эта железа будет стоить на >$10 больше. А не через год и подешевле.
Она может стоить подороже на $10 000 000

>Критичным становятся именно ВРЕМЯ разработки для вывода на рынок. >Сегодня это топовый продукт, завтра уже забытый.
Lotus, OFSA, Discovery, Siebel и другим тяжеловесам далеко за 10 лет. Все еще топовые.

>Да, чем более массовое производство, тем оплата программиста принимает >все меньшую долю в стоимости конкретного устройства, но практика >такова, что железка сейчас стоит дешево, ОЧЕНЬ дешево.
Мы про микроконтроллеры или вообще?

>Поэтому на C++ просто быстрее писать, чем на C сложные продукты, да и >более надежно, легче осуществлять поддержку, модернизацию. Это и >ценно.
Сложные быстрее писать на VB :-)

>А вычислительные возможности отходят на второй план.
Не отходят. И давно понятно почему. Если алгоритм неэффективный любую железяку на колени поставить легко.

Что касается C, С++ то если с алгортмическим решением все в порядке то язык почти по фиг. Но если 10% играют роль то специалисты занятые конкретной проблемой могут пробовать и искать как эти 10% получить. А сказать что одно лучше другого заранее нельзя.

Sergey Masloff (10.12.06 17:48) [28]
Мы про микроконтроллеры или вообще?

я лично про микроконтроллеры. Где ты нашел их стоимостью в 50 лет зарплаты - я не знаю.

Собственно, ты офигенно все расписал насчет миллионов долларов, наращиваемости и прочее. А теперь вопрос - ты что, на C кодишь? Я не понимаю почему ты в низкоуровневое программирование вписал примеры из энтерпрайз.

Поясню еще раз, возможно непонятно выразился. Допустим, мы имеем некую задачу - нужен некий функционал. У нас есть альтернатива - или через полгода написать все на C++, или через два года тоже самое оптимальнейшим образом получить в ассемблере.

Первый вариант требует более крутых чипов, немного больше памяти и прочее. Но современное железо развилось настолько, что зачастую куда проще купить более современную железную платформу, прибавив буквально копейки в РАЗНИЦЕ (а не полную стоимость) между одной платформой и другой.

Поэтому выбор того или иного средства разработки сейчас на 90% зависит от скорости разработки / поддержки. А вовсе не от выдаваемой производительности кода.

Конечно, везде есть оптимум, криво писать не надо. Но думаю справедливо предположить, что хороший код на ассемблере с ручной оптимизацией профи будет работать быстрее хорошего кода на C++, но время и сложность разработки увеличится в разы. А то, что код C++ будет немного медленнее - пофигу, мы просто купит чуть более быстрое железо.

Гм... а где же это: извини, Сергей, погорячился в пылу спора... ?

просто на рынке прикладного обеспечения это стало уже стандартом де-факто. Никто не пишет на ассемблере, если есть Delphi / C++ / Java.

На рынке embedded это просто потихонечку приходит, от ассемблера уже отказываются. Самый показательный пример - мобильные телефоны. Туда встроили java - и все ок. Да, это тормозно, но зато это быстрая разработка + кроссплатформенность (а кроссплатформенность по сути это опять же уменьшение времени разработки на портирование под нужные платформы).

Юрий Зотов © (10.12.06 21:33) [30]
Гм... а где же это: извини, Сергей, погорячился в пылу спора... ?

а я что-то обидное очень сказал. Тогда искренне прошу прощения у Сергея. Просто эти подколки в стиле "начитался рекламных проспектов" немного надоедают. Ни в одном рекламном проспекте такого нет, это очевидно :)

> Piter © (10.12.06 21:37) [32]

> а я что-то обидное очень сказал.

Да ну, сущие пустяки. Просто сказал, что Сергей страдает фигней и бредит. Что здесь обидного? Ничего, все ОК.

Юрий Зотов © (10.12.06 21:43) [33]

не знаю даже, я думал, что Сергей не обидется. Ведь разве в [25] был сформулирован вопрос, дядь Юр? По-моему, там сформулирована подколка, мол "нихрена ты не понимаешь, начитался рекламных буклетов". Я и призвал отбросить подколки, а начать вести более конструктивный диалог.

Возможно, выразил это черезчур резко, извиняюсь.

> Piter © (10.12.06 21:50) [34]

Миш, 25 было вызвано 24, очевидно. А теперь перечитай 24, спокойно и внимательно. Одни декларации и никакого серьезного анализа, и ни одной ссылки на такой анализ. Именно как в рекламных буклетах.

Чему же удивляться? Это и было сказано в 25.

>oxffff и atruhin
>Не торипитесь.
>А вы знаете почему ID Software писала на С, а не на С++.
>А все потому же.
>Так что следы есть и пока их полностью не избежать.

Немного поясню ситуацию. Я говорил о "следах, от которых невозможно избавиться". Это значит, что эти следы имеют место в C++-коде, но отсутствуют в аналогичном C-коде. Таких "следов" нет. Если какие-то "следы объектов" присутствуют в C++-коде и от них невозможно избавиться при сохранении работоспособности кода, то аналогичные "следы" (но уже в собственном исполнении) будут присутствовать и в аналогичном C-коде.
Т.е. не избежать "следов", если они нужны и используются в программе. Но в этом случае и в аналогичном C-коде придётся реализовывать (уже самостоятельно) аналоги RTTI, vtbl и прочее.

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

>Piter © (10.12.06 15:55) [24]
>>Cyrax © (10.12.06 11:52)
>>а эти параметры - скорость и размер кода - в системном программировании
>>играют ведущую роль

>вот это уже становится неправдой. Сейчас время программистов
>становится дороже, чем немного нарастить память или вычислительные возможности.

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

public class IntHolder { private Integer contents = null; public Integer getContents() { return contents; } public void setContents(Integer contents) { this.contents = contents; } public String asString() { return getContents().toString; } --------------- intHolder = new IntHolder(); intHolder.setContents(2); String var_S = intHolder.asString(); // Неявный вызов конструктора и сеттера. // Где-то далее: код уничтожения var_S и объекта intHolder.

Сравним это с:
var_S = IntToStr(2); // Где-то далее: код финализации var_S

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

А можно и не говорить.

← →
Sergey Masloff (2006-12-10 23:51) [39]

Piter © (10.12.06 16:41) [26]
> Про C++, про C, про стоимость разработки?
Никаких обид.
Не то что видел - вижу постоянно.
Я, честно говоря ветку не читал практически. Глянул с конца там в очередной раз про "на фиг правильно писать купим железа помощнее... оптимизаторы опять же..."
Ну и...

Просто пример я уже раз 100 приводил. Была задача - массив данных (ну пусть таблица) одно из полей которой - строка которая по идее является датой. Но заполняли ее как придется - и 01.02.2000 и 02/03/2001 и 03-04-2002 и так далее. Нужно было отбирать записи в которых даты реальные.

Первоначальный вариант использовал перебор в цикле а алгоритм проверки дат был как раз с твоим любимым пустым блоком except ;-) Сказать что это работало долго - не сказать ничего. За рабочий день не отрабатывало.

Затем алгоритм проверки был переписан на C (собственно чтобы в Oracle внедрить поближе к данным). Не скажу что стало сильно быстрее.

Потом пересмотрели подход. Возникла идея нагенерить таблицу со всеми реальными датами за последние 20 лет в строковом формате (во всех допустимых вариантах) и соединить эту таблицу закрытым джойном с исходной.

Время работы сократилось на три порядка. То есть вместо десяти часов стало измеряться в секундах. Прикинь сколько бы стоило получить тот же результат за счет наращивания железяк.

Я в своей практике не раз сталкивался с подобными проблемами хотя никакими особо сложными рассчетами не занимаюсь. Так что наверное проблемы и поострее стоят в других областях?

> Cyrax © (10.12.06 22:04) [36]
> >oxffff и atruhin
> >Не торипитесь.
> >А вы знаете почему ID Software писала на С, а не на С++.
>
> >А все потому же.
> >Так что следы есть и пока их полностью не избежать.
>
> Немного поясню ситуацию. Я говорил о "следах, от которых
> невозможно избавиться". Это значит, что эти следы имеют
> место в C++-коде, но отсутствуют в аналогичном C-коде. Таких
> "следов" нет. Если какие-то "следы объектов" присутствуют
> в C++-коде и от них невозможно избавиться при сохранении
> работоспособности кода, то аналогичные "следы" (но уже в
> собственном исполнении) будут присутствовать и в аналогичном
> C-коде.
> Т.е. не избежать "следов", если они нужны и используются
> в программе. Но в этом случае и в аналогичном C-коде придётся
> реализовывать (уже самостоятельно) аналоги RTTI, vtbl и
> прочее.
>
> Допустим, нас не устраивает наличие RTTI-информации. Мы
> переходим с C++ на C, поскольку там её нет. Но в этом случае
> нам придётся перестраивать C-программу для устранения необходимости
> самостоятельной реализации аналога RTTI. Но почему бы нам
> не перестроить С++-программу для устранения необходимости
> использования RTTI. Мы же рассматриваем аналогичный код
> на C и C++...

О как.

Системное/низкоуровневое программирование: C vs C++ Найти похожие ветки