LINUX.ORG.RU

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


0

3

Всем привет!

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

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

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

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

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

Во-первых в С++ приватные члены это не более чем защита от дурака.

Это не только защита от дурака, это концепция. Объект - это закрытый ящик. К нему никак нельзя получить доступ внутрь, это нарушение инкапсуляции. Если этого нельзя гарантировать, значит программа небезопасна.

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

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

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

Да ну? И как же C++ мне это гарантирует?

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

Объект - это закрытый ящик

квалификатор private - не единственный (и не лучший) способ добиться инкапсуляции. строго говоря, он к ней вообше отношение имеет опосредованное - описываешь контракт (интерфейс) для работы с объектом, и всё, никаких левых методов наружу торчать не будет

jtootf ★★★★★
()

А на С

программируют под
микроконтроллерами скорее от
бедности?
суровые челябинские мужики программируют микроконтроллеры на паскале

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

Объект - это закрытый ящик. К нему никак нельзя получить доступ внутрь, это нарушение инкапсуляции. Если этого нельзя гарантировать, значит программа небезопасна.

Можно придумать защиту от дурака, но только от неизобретального. К любому приватному члену можно достучаться либо тупо по смещению от начала объекта, либо еще тупее поставив public: в соотв. хидере.

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

Если этого нельзя гарантировать, значит программа небезопасна

а для того, чтобы что-нибудь гарантировать, C++ подходит очень, очень плохо. если верифицировать сишную программу на Isabelle/HOL (например) ещё можно, то верификация C++ в лучшем случае находится на уровне Lint и Goanna

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

предполагаю, что в С ничуть не меньше возможностей

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

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

компилировать код с -Dprivate=public

Гениально! Я вот не додумался... хотя -Dfalse=true еще веселее «я давно полюбил говорящих да...» ;-)

AIv ★★★★★
()

В стиле ООП можно писать и в С. Для примера можно почитать Object-Oriented Programming with ANSI C

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

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

Да, согласен. Но в С возможностей накосячить тоже предостаточно. Уж я за много лет практики нагляделся на всякое. Иной раз даже поражался: «ну вот, как, ну как такое можно было измыслить?» :)

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

особенно оператора присваивания, дорогого стоит...

Сейчас изучаю Objective-C. По своему замечательный язык. Похоже там нет необходимости в операторе присваивания, как и в конструкторе копирования. Просто объекты редко копируются...

dave ★★★★★
()

Сегодня пишуть системный софт на С , но мало и со скрипом. Заказчики почемуто боятся его и обычно приходиться дого уговоривать на ++ . Все же приходится отказыватся от C exceptions, templates или RTTI. Но плюшки в виде абстракции, наследования, виртуал функций и т.д. никто не отменял. Лично я еще тащусь от new особенно в сравнении с malloc, а еще очень просто реалировать stl-ные шаблоны самостоятельно, так же как и smart ptr. Да и подержка кода на намного проще чем на С. Если система уже написана на С, то дописывать ее это адское дело, это как карточный домик лишнее двежение и вся система завалилась.

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

Говнокод на любом языке написать можно.

Вот про то и речь. И ООП на С можно, и совершенно небезопасный код на С++. Всё зависит от того, кто это инструменты применяет. На этом и тред можно закрыть.

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

вот, например

Хороший пример. Но это экзотика. Хотя.. может скоро будут выпускать платформы со встроенным полноценным .NET фреймворком.

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

Примеры в студию)

L4 (одна из реализаций) на C++, SqueakNOS на Squeak, Movitz на Common Lisp, Singularity на C# (подмножестве), hOp, HalVM (Galois Inc.), Kinetic, House, Lighthouse на Haskell.

quasimoto ★★★★
()

почему системный софт … не пишут … с использованием ООП?

пишут

на С++

потому, что не нужен

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

ООП - это паттерн проектирования, если можно так сказать, а не часть языка. Писать в ООП стиле на чистых сях вполне возможно, самая известная реализация - GOBject, там есть и приватные поля, и виртуальные методы и наследования. Над этим всем даже есть свой аналог «Си с классами» - Vala, препроцессор, который генерирует сишный код с использованием модели GObject.

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

Это не только защита от дурака, это концепция. Объект - это закрытый ящик. К нему никак нельзя получить доступ внутрь, это нарушение инкапсуляции.

дык таких приватных членов в С++ нет. Все равно можно доступиться ко всему

Waterlaz ★★★★★
()

Как-то довелось работать с одной RTOS, основанной на FreeBSD кстати, у которой низкоуровневый API (реализация таймеров и всего прочего) была на С++ и для сборки софта под это дело использовался С++-компилятор. Была задача портировать под эту ОС отдельные модули на чистом Си, изначально написанные для Solaris, но кроссплатформенно, а так как C++ и C - это разные языки и не совместимы между собой имели много гемороя.

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

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

Все эти фичи были и в синтаксесе turboAssembler.

В нем отсутствуют базовые понятия ООП. Безусловно при большом желании на турбо ассемблере (как и на чистом C) можно имитировать ООП, но имитация != поддержка языком парадигмы программирования.

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

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

В C++ отсутствует понятие объекта? C++ не поддерживает основные принципы ООП? Это всего лишь личное отношение к языку, возможно вполне заслуженное, учитывая «особенности» C++. Но менее ООП'шным он от этого не становится.

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

дык таких приватных членов в С++ нет. Все равно можно доступиться ко всему

хаком, в С и С++ так можно что угодно получить, ЯП такие

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

в C++ отсутствует понятие объекта. Сишная структура и таблица методов, которые можно дёргать - нифига не объект.

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

в C++ отсутствует понятие объекта. Сишная структура и таблица методов, которые можно дёргать - нифига не объект.

а что ещё надо объекту?

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

объекту ничего не надо, а программисту могут потребоваться такие вещи, как рефлексия или обработка сообщений. В Obj-C это есть, в C++ нет и не будет.

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

в C++ отсутствует понятие объекта. Сишная структура и таблица методов, которые можно дёргать - нифига не объект.

Конечно раскрыть понятие «объект» в своем понимании ты не удосужился, поэтому пока что голословное утверждения. Кстати почему из под анонимуса, боишься скор порежут за обсуждение скользкой темы?

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

рефлексия или обработка сообщений

С каких пор вышеперечисленное является неотъемлимой частью ООП-языка?

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

боишься скор порежут за обсуждение скользкой темы?

Странно, чем же это тема про С++ в системном программировании так уж «скользка», что за неё могут резать скор? Я в недоумении.

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

с тех самых пор, как само ООП появилось, болван.

Как всегда нет никаких подтверждений своих слов - голословное утверждение.

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

Понятие ООП очень размыто, если считать, что ООП - это любой язык, в котором есть слово «class», то да, С++ - это ООП язык.

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

Так же, если оглянуться в историю, один из первых ООП-языков - это Smalltalk, в котором все фишки, упоминаемые анонимусом уже были, и Objective-C имеет ООП-модель Smalltalk-like.

В итоге, С++ может называться объекно-ориентированным весьма условно. Это мультипарадигменный язык с элементами ООП и функционального программирования (лямбды же есть).

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

голословное утверждение - это то, что в C++ есть поддержка ООП.

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

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

рефлексия или обработка сообщений

С каких пор вышеперечисленное является неотъемлимой частью ООП-языка?

Анон спутал «обработку» и «обмен». Обмен сообщениями (messages, не events) - суть и цель ООП. Тут он прав.

Рефлексия тоже появилась в Smalltalk, но неотъемлемой не является. Рефлексивное программирование - подмножество ООП.

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

Эмуляцию интерфейса за счет множественного наследования абстрактных классов в расчет не берем

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

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

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

И все же, это не интерфейс, с точки зрения определений. Если ставить такие допущения, Си + GObject тоже ООП язык ;)

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

Анон спутал «обработку» и «обмен». Обмен сообщениями (messages, не events) - суть и цель ООП. Тут он прав.

Почему? Кто сказал, что метод - это обязательно посылка сообщения? Java - ООП язык, при этом там метод - это простой вызов функции.

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