LINUX.ORG.RU

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


0

3

Всем привет!

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

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

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

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

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

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

выполни пожалуйста :)

cat /etc/passwd | wc -l

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

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

инкапсуляция гарантируется не квалификатором private, а механизмом экспорта и работой через интерфейсы. private - это не более, чем комментарий (особенно в C++)

Поддержка языком чистых абстрактных классов и множественного наследования - это и есть поддержка интерфейсов

поддержка языком чистых абстрактных классов и множественного наследования - это поддержка языком чистых абстрактных классов и множественного наследования. и всё

Это уже тонкости реализации C++

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

jtootf ★★★★★
()

В системном софте меньше абстрактных объектов и больше процедур.

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

В рантайме их нет

в рантайме есть всё, что из них было инстанцировано

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

выполни пожалуйста :)
cat /etc/passwd | wc -l

Советую то-же самое сделать в гайке (а еще cat /etc/group | wc -l). Ты будешь удивлен, увидев в там число больше единицы.

Там даже пользователь, под которым пользовательские программы вовсе не root (хоть и состоит в группе root).

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

И давайте уже прекратим этот бессмысленный спор. Даже если бы этого всего в гайке не было, это не делало бы ее плохой ОС для десктопов (тем более, поддержка многопользовательности не имеет никакого отношения к «системному программированию и С++»).

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

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

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

посмотри на реализацию объектов хотя бы в .Net

Компиляторы C++ преобразуют код именно в структуру, и при внешнем использовании с ней можно издеваться как только хочешь. Без поддержки среды исполнения это всё только бутафория. И соответственно написания библиотека на С++ тебе не даст современных возможностей ООП.

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

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

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

инкапсуляция гарантируется не квалификатором private, а механизмом экспорта и работой через интерфейсы

Видимо у меня пробел в знаниях - не знаю о каком «механизме экспорта» идет речь. По поводу работы через интерфейсы - это очевидно. Доступ к защищенным данным может осуществляться только через интерфейс. Хотя защитить сами данные («пометить» их как защищенные) все же непомешает.

private - это не более, чем комментарий (особенно в C++)

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

которые в данном случае заключаются в отсутствии интерфейсов

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

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

не знаю о каком «механизме экспорта» идет речь

о том, который ещё в C реализуется с помощью ключевых слов static и extern. в Erlang, например, приватных полей нет - у процесса есть публичный интерфейс, и иначе общаться с ним невозможно, и что там у него внутри - чёрный ящик (тот самый, о котором инкапсуляция). в Slice (язык ZeroC ICE) интерфейс серванта описывает контракт взаимодействия, а за ним может скрываться десяток серверов на физически разнесённом железе - опять же, будут ли на них какие-то локальные операции, никого не интересует

защитить сами данные («пометить» их как защищенные) все же непомешает

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

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

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

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

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

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

Инкапсуляция в твоем понимании — это то, что в крестах делается через наследование от интерфейсного класса.

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

Инкапсуляция в твоем понимании — это то, что в крестах делается через наследование от интерфейсного класса.

exactly. и не только в моём понимании, а в общем в трактовке инкапсуляции как отделения интерфейса от реализации (сокрытия реализации). в C++ это делается несколько неудачно (нет разделения понятия интерфейса и механизма диспетчеризации, что порождает паттерны вроде NVI), но вполне приемлимо

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

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

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

Ну пример от Бьеорна нашего Страуструпа с << >> для iostream я не привожу.

Оператор [] - много где актуален.

Код для числодробилок - работа с декартовыми векторами, матрицами и много чем еще.

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

оператор , вместе с макросами позволяет делать довольно забавные вещи. Хотя это уже на грани фола.

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

Ну пример от Бьеорна нашего Страуструпа с << >> для iostream я не привожу.

Да-да, использовать операцию бинарного сдвига для чтения и записи потока — очень умно. Худшего примера ты просто не мог бы сходу придумать.

И да, подучите матчасть. То, что вы упорно зовёте операторами, называется операции.

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

И да, подучите матчасть. То, что вы упорно зовёте операторами, называется операции.

Дяденька, а что есть оператор? Как то во всей литературе по С++, к-ю я видел, ЭТО тоже называют операторами. Аффторы тоже небось матчасти незнают?

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

Да-да, использовать операцию бинарного сдвига для чтения и записи потока — очень умно. Худшего примера ты просто не мог бы сходу придумать.

И почему же аффторы iostream забыли проконсультироваться с таким светочем знаний как Вы?;-)

AIv ★★★★★
()

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

Читай книжки по С++, особенно по оверрайдингу. Потом приходи.

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

Дяденька, а что есть оператор?

В ВУЗе ничему не научили? Не отчаивайся, учиться никогда не поздно.

http://ru.wikipedia.org/wiki/Оператор_(программирование)

http://ru.wikipedia.org/wiki/Операция_(программирование)

Как то во всей литературе по С++, к-ю я видел, ЭТО тоже называют операторами.

Не читайте говнопереводы, читайте нормальную литературу. А лучше вообще читать на английском.

Аффторы тоже небось матчасти незнают?

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

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

А ты прав насчет операций... спасибо.

AIv ★★★★★
()

Задался я тут таким вопросом, почему системный софт (ядра ОС, драйверы, биосы) не пишут на С++ с использованием ООП?

про биосы не знаю
под все остальное пишут на С++
примеров полно под
MacOSX
Windows
FreeBSD
Linux - на уг линуксе меньше всего пишут, ибо ведро

гугл только вчера увидели? научитесь вообщем то им пользоватся

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

а смысл? незначительное сокращение кода в ущерб читабельности? Не нужно

Оператор [] - много где актуален.

функция для доступа к элементу чем хуже?

работа с декартовыми векторами, матрицами и много чем еще.

чем add_vect(A,B) хуже A+B, кроме количества символов?

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

чем add_vect(A,B) хуже A+B, кроме количества символов?

Количество переходит в качество. При вводе числ. схемы, которая в обычной то записи страницу занимает, вводить и (отлаживать!!!) ее с лишними символами... ну Вы видимо не пробовали.

Вот МАЛЕНЬКИЙ кусочек кода, и его запись полностью эквивалентна бумажному варианту (с точностью до синтаксиса типа A[0] вместо A_0 в теховской нотации), поэтому код легко набиарестя и легко отлаживается.

				M(ij,ij) = cc.C + ( cc.uG*cc.Theta + cc.G )*cc._p*cc._p 
					+cc.D[0]*( .5*_dx2*( 2*cc.A[0]+pc.A[0]+mc.A[0] ) + .5*_dy2*( 2*cc.A[0]+cp.A[0]+cm.A[0] ) )
					+cc.D[1]*( .5*_dx2*( 2*cc.A[1]+pc.A[1]+mc.A[1] ) + .5*_dy2*( 2*cc.A[1]+cp.A[1]+cm.A[1] ) )
					+cc.D[2]*( cc.A[2]*powq( cc._p, q+1 )*( -q*(_dx2+_dy2) + .5*(q+1)*cc._p*( ( mc.p+pc.p )*_dx2 + ( cm.p+cp.p )*_dx2 ) )
							   +.5*cc._p*cc._p*( ( pc.A[2]*powq( pc._p, q-1 ) + mc.A[2]*powq( mc._p, q-1 ) )*_dx2 +
												 ( cp.A[2]*powq( cp._p, q-1 ) + cm.A[2]*powq( cm._p, q-1 ) )*_dy2 ) );
Всего в файле 377 строк, из них ~300 - вот такой вот математики. Скока строк будет с Вашими add_veс, mul_vec и т.д.? И как это будет читаться?

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

Linux - на уг линуксе меньше всего пишут, ибо ведро

+100500

Поэтому Linux тормозное решето с архитектурой 30 - летней давности, окаменевшей как Г не то что мамонта - а диплодока! :)

У меня, к примеру, не вызывает положительных эмоций написаине дров для Linux на Си - УГ.

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

ты так говоришь, будто в плюсах человеческая проверка типов

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

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

MacOSX
FreeBSD

Ядра MacOSX и FreeBSD написаны на C++?

Windows

На чём написано ядро Windows знают только его создатели.

Linux - на уг линуксе меньше всего пишут, ибо ведро

Личная неприязнь к Linux?

гугл только вчера увидели? научитесь вообщем то им пользоватся

Научитесь внимательно читать. В своём начальном сообщении я не прошу привести мне примеры системного софта на С++, а ставлю вопрос шире. Потому что факт остаётся фактом - мэйнстрим системного софта в данный момент пишется на чистом Си.

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

ну Вы видимо не пробовали.

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

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

Ядра MacOSX и FreeBSD написаны на C++?

- есть кернель модули FreeBSD, написаны на С++
и успешно работают
гугл в помощь

- ядро MacOSX открыто, потрудитесь скачать и изучить

На чём написано ядро Windows знают только его создатели.

а так же все кто не гудносит а качает исходники и изучает
Win32k - GUI система на С++
Syser - ядерный отладчик тоже на чистом C++
итд - гугл в помощь

Личная неприязнь к Linux?

ничего личного, пишу под все ОС кроме MacOS
линукс среди них самая УГ
достаточно почитать феерические вбросы тупого торвальдса
который в жизни мало чего достиг
даже трансмету завалил как проц
но это все офф

Потому что факт остаётся фактом - мэйнстрим системного софта в данный момент пишется на чистом Си.

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

anonymous
()

Ну ядро Haiku немного использует Си++. Но вот в Plan 9 ядро спроектировано так, что особой необходимости в Си++ просто нет.
OpenBSD также написана на Си, а ядро линукс просто слишком huge'n'bloated.

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

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

Так и в джава интерфейсов нет. Interface в расчет не берем. Problems?

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

есть кернель модули FreeBSD, написаны на С++

и успешно работают Это скорее исключение. БОльшая часть системы написана на Си.

- ядро MacOSX открыто, потрудитесь скачать и изучить

Прошу здесь не указывать, что мне делать.

а так же все кто не гудносит а качает исходники и изучает

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

линукс среди них самая УГ

Это ваше сугубо личное и неправильное мнение.

PS. Вы так часто упоминаете гугл, наверно там работаете?

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

На чём написано ядро Windows знают только его создатели.

Исходники ядра от NT 4.0 «утекли» в сеть и их можно посмотреть и вроде даже скомпилировать. Исходники от NT 5.0 (Windows 2000) тоже «утекли» и если немножко погуглить - то можно посмотреть ;)

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

и успешно работают Это скорее исключение. БОльшая часть системы написана на Си

какая разница какая часть? вы исходный свой вопрос в начале темы почитайте, да?

Прошу здесь не указывать, что мне делать.

не осилили изучить предметную область но очень ходите о ней потроллить? тогда с вами общатся не интересно

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

ЛОР такой ЛОР, здесь никому ничего не интересно это форум фанатиков троллистов

Это ваше сугубо личное и неправильное мнение.

мое мнение как программиста очевидно вы не программист и даже не приближенны к ним ничего не писали, ничего не видели, но очень нравится разговаривать? этакий столлман?

PS. Вы так часто упоминаете гугл, наверно там работаете?

очевидно нет но есть у вас храмают знания впредметной области подтяние их для начала потом продолжим

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

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

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

Только вот постоянно приведение типов (иначе куча Warning'ов) + структуры наследоваться не умеют (вот сделали бы хотя бы наследование структур и C++ был бы вообще не нужен).

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

Ладно, пусть ты прогуливал информатику в школе и пусть не учился в ВУЗе по соответствующей специальности. Но сейчас-то ты уже сходил по ссылкам в википедию? Ты уже скачал по ссылке перевод Страуструпа и посмотрел, как там переведено слово operator? Нет, не сходил и не скачал.

Как ознакомишься, возвращайся.

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

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

Куда же нам без лучшей книги по ООП всех времён и народов)

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

Не читайте говнопереводы, читайте нормальную литературу. А лучше вообще читать на английском.

Ты уже скачал по ссылке перевод Страуструпа и посмотрел, как там переведено слово operator?

/0

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

P.S. Все же советую прочитать Страуструпа на английском, перестать принимать википедию как истину в последней инстанции. Ну и man «Вежливость».

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