LINUX.ORG.RU

Системный софт и ООП


0

3

Всем привет!

Задался я тут таким вопросом, почему системный софт (ядра ОС, драйверы, биосы) не пишут на С++ с использованием ООП? Казалось бы, преимущества налицо. C++ близок к Си, поэтому потери производительности должны быть незначительны. Расход памяти тоже не должен заметно возрасти. Зато ООП позволяет программам быть безопасными, программер лучше концентрируется на предметной области, а компилятор это преобразует в код. С++ ничего не добавляет непредсказуемого в рантайме.

Можно писать весь каркас объектно ориентированным, а в точках где требуется скорость писать на С, можно использовать любые возможности С и ООП и безопасность С++ (например операторы static_cast, auto, namespace и многое другое). Обернутые в классы, можно использовать шаблоны, которые на этапе выполнения ничего не добавляют, но помогают настраивать объекты.

Например объект таймера, у него статический метод который обрабатывает прерывание, никто к нему не имеет доступа, он приватный и оповещает все подсоединенные таймеры.

Или может я ошибаюсь и системный софт сейчас пишут на С++? А на С программируют под микроконтроллерами скорее от бедности? Есть ли примеры такого софта?

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

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

Зато ООП позволяет программам быть безопасными

Тоже далеко идущее заявление (независимо от того, это ООП в целом или ООП в C++).

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

Заблуждение.

которые на этапе выполнения ничего не добавляют

Тоже очень большое заблуждение.

dmitry_vk ★★★
()

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Linus Torvalds

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

Это понятно. В ядре Linux тоже есть элементы ООП, реализованниые на Си. Я имею ввиду, использование ООП-языка для написания системного софта.

x-signal ★★
() автор топика

Сам пишу на С и С++, но честно скажу: «С++ must die!» Ничего личного. Просто вижу, как его используют малоопытные коллеги

velikS
()

Налицо тот случай, когда ошибки в предпосылках приводят к ошибкам в выводах.

PS: Ошибки в предпосылках верно указаны здесь.

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

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

Далеко идущее заявление. Это не так.

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

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

Сейчас вроде есть такая поддержка, даже стандарт embedded C++.

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

Заблуждение.

А если не использовать виртуальные функции?

которые на этапе выполнения ничего не добавляют

Тоже очень большое заблуждение.

Всегда думал, что шаблоны полностью обрабатываются на этаме компиляции.

x-signal ★★
() автор топика
Ответ на: комментарий от x-signal

Я имею ввиду, использование ООП-языка для написания системного софта.

Ну так и вбрасывал бы ООП-язык, а не C++.

schizoid ★★★
()

Вроде бы как-то на ЛОРе была новость про опенсорс драйвер для семейства каких-то принтеров, так он был написан на плюсах, ибо на чистосях разрабам писать ваще не улыбало.

dismal_faun ★★
()

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

Я думаю все зарыто здесь. Си создавался для системного программировния. Это DSL по сути. И никакое ООП уже тут не улучшит.

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

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

Windows user detected.

Драйвера для принтера - это совсем другая опера.

r2d2
()
Ответ на: комментарий от x-signal

А если не использовать виртуальные функции?

А также шаблоны, RTTI, исключения, stl, конструкторы копирования, возврат объектов из функции, передачу объектов по const reference. И вы хотите сказать, что в итоге у нас останется C++, а не C с несколькими плюшками?

dmitry_vk ★★★
()

Our experience was not unique. All around, early adopters of C++ had difficulties with the resulting performance of their C++ code. Instead of attributing the difficulties to the steep learning curve of the new object-oriented software development paradigm, we blamed it on C++, the dominant language for the expression of the paradigm. Even though C++ compilers were still essentially in their infancy, the language was branded as inherently slow. This belief spread quickly and is now widely accepted as fact. Software organizations that passed on C++ frequently pointed to performance as their key concern. That concern was rooted in the perception that C++ cannot match the performance delivered by its C counterpart. Consequently, C++ has had little success penetrating software domains that view performance as top priority: operating system kernels, device drivers, networking systems (routers, gateways, protocol stacks), and more.

Efficient C++ Performance Programming Techniques By Dov Bulka, David Mayhew, 1999

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

А также шаблоны, RTTI, исключения, stl, конструкторы копирования, возврат объектов из функции, передачу объектов по const reference. И вы хотите сказать, что в итоге у нас останется C++, а не C с несколькими плюшками?

Шаблоны, классы, конструкторы копирования останутся и не помешают. А rtti, исключения, stl не обязательно. Они и добавляют в рантайм, а все остальное вполне можно использовать для улучшения на этапе компиляции.

x-signal ★★
() автор топика

почему системный софт не пишут на С++

Тут перевод слов Линуса с матерного: http://msdn.microsoft.com/en-us/windows/hardware/gg487420

с использованием ООП

Полезно только в больших проектах, ну так в ядре используют.

потери производительности должны быть незначительны

У C++ нет потерь производительности в сравнении с C, они могут быть у программиста.

Например объект таймера...

Это ничем не хуже делается на C.

unsigned ★★★★
()

в точках где требуется скорость писать на С

С++ при правильном использовании ничуть не медленней С.

ООП позволяет программам быть безопасными

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

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

В отличии от С - там гораздо сложнее написать небезопасную и неэффективную программу

Ооочень спорное суждение. Всё зависит от квалификации. Сужу по своим многочисленным коллегам.

Что несколько раздражает в С++ - обилие инструментов, которые часто без надобности суются где попало, что в итоге сильно влияет на структуру и читаемость кода. В С с этим как-то проще. ИМХО, конечно

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

В отличии от С - там гораздо сложнее написать небезопасную и неэффективную программу

А как же необдуманное применение указателей и ляпы в «арифметике» с ними? А многочисленные выходы за границы массива по недосмотру пишущего? А слишком вольное преобразование типов?

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

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

madcore

ООП != C++

schizoid

Ну так и вбрасывал бы ООП-язык, а не C++.

Я сам совсем не в восторге от многих вещей в C++, но всегда поражаюсь, как личное отношение может переходить в утверждения с претензией на объективность. Можно много спорить о поддержке языком кокнретных фич и об удобстве применеия (прямости реализации) этих фич, но все черты ООП языка у C++ присутсвуют: объекты, абстракции, инкапсуляция, наследование, полиморфизм.

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

Дополнение

И ещё - почему-то не сразу вспомнил главный источник «небезопасности» - выделение и освобождение динамической памяти. Вот уж где простор для «опасностей».

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

У людей тоже хвост есть.

Все эти черты есть попытка прикрутить с хорошему низкоуровневому языку черты высокого уровня и (!) оставить совместимость (читай «низкоуровневость»).

Язык объективно строен, конечно, только пользуются им люди. Чисто-ОО-программы на нём писать никто не умеет, не предназначен он для этого. Хотя 11 стандарт долю удобства добавил.

// Добврольный C++/ООП программист.

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

ООП на Си:

struct XXX_t;

xxx_init(XXX_t **);
xxx_do_something(XXX_t *);
xxx_do_other(XXX_t *);
...

Вполне удобно и без заморочек. Переносимо со страшной силой (архитектуры и компиляторы).

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

системный софт пишут в ООП стиле, но на Си

Но тогда теряется одно из основных преимуществ ООП - безопасность. Насколько я понял из обсуждения, основная причина написания системного софта на Си - это высокая сложность С++.

x-signal ★★
() автор топика
Ответ на: комментарий от schizoid

Подсознание, очевидно, этому факту сопротивляется активно :)

Вот я и засомневался... :)

PS: Меня пару раз жизнь «втаскивала в С++» (на год и на полтора). Но я сбегал. :) Типичный неосилятор. :)

DeVliegendeHollander ★★
()
Ответ на: комментарий от x-signal

А если не использовать виртуальные функции?

Ну и нафига такое ООП?

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

Скастуйте йогурта, пусть он вам расскажет про ООП.

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

в каком месте теряется безопасность?

Нет приватных членов, вся программа имеет доступ ко всему и может нарушить целостность всего, нет шаблонов для конфигурирования объектов разными параметрами, такой объект - это модуль, а не первоклассная сущность, его нельзя множить переконфигурировать, подключать к другим пинам/портам налету, сложно внести взаимодействие на уровне компонентов, все слишком становится зависимо, там где я мог работать с абстрактным объектом, я вынужден работать с голым жестко заданными названиями функций в конкретном модуле. Нельзя подавать в другие объекты как объект и параметр шаблона, нельзя делать обобщенные методы и контейнеры для работы с такими объектами, генерики и так далее и тому подобное. И переносить в новые проекты тоже сложнее, он корнями привязан к текущему потому что не абстрактный.

x-signal ★★
() автор топика

Или может я ошибаюсь и системный софт сейчас пишут на С++?

Я тебя ошарашу, системный код пишут и на C# и на Haskell.

AlexVR ★★★★★
()
Ответ на: комментарий от x-signal

Во-первых в С++ приватные члены это не более чем защита от дурака. Во-вторых структура может быть объявлена как struct MyClass (что в 99% случаев и делают) и ты вообще никаких членов не увидишь. Шаблоны к ООП и безопасности никакого отношения не имеют.

В общем, всё о чем ты говоришь лишь вносит неудобства при программировании, но не имеет ни малейшего отношения к ООП и безопасности.

Reset ★★★★★
()

Зато ООП позволяет программам быть безопасными

Признавайся, Бучем со товарищи обчитался?

а в точках где требуется скорость писать на С

Эта светлая «идея» загубила не один и не два проекта.

ЗЫ: А вообще, у тебя сущая каша в голове. Но это нормально, на самом деле, ибо ООП - недетерминированное понятие.

Почитай самллтолковский Blue Book. Это одна из немногих книжек по ООП, где термин «ООП» не употребляется. Еще можно почитать PARC'овских бумажек по CLOS, но это уже перебор, я считаю.

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

Macil ★★★★★
()
Ответ на: комментарий от x-signal

вся программа имеет доступ ко всему и может нарушить целостность всего

Как мне кажется, здесь проблема в программисте, а не в парадигме программирования. И само по себе ООП не является ни непробиваемой защитой, ни «серебряной пулей».

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

С++ же, как концепция, не стоит изучения,

После двух, не слишком удачных погружений в С++, пришёл к такому же выводу.

И подчеркну: именно как концепция. О С++, как инструменте, - это вопрос другой, отдельный.

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

Я именно деньги зарабатывал (с этой целью и «погружался»). Но...

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

Алан Кей сказал, что в C++ нет поддержки ООП. Как человеку, который придумал это самое ООП в принципе, ему можно верить.

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

А ты прямо раз и стал сразу опытным? Все через это проходят.

hope13 ★★★
()

насколько помню, US DoD разрешает для системного софта использовать три язычка: Ada, C и C++. При этом в C++ запрещено использовать шаблоны, виртуальные фукнции, RTTI, блах-блах. Короче остаётся только C с классами.

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