LINUX.ORG.RU

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


0

3

Всем привет!

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

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

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

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

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

В Objective-C сообщения ты можешь слать кому угодно и куда угодно, даже нулевому объекту, а сможет он ответить на твое сообщение или нет (найти нужную функцию) - это дело десятое. В Java метод - это ссылка на вполне определенную функцию и в Java следующий код

MyObject a = null;
a.foo();

бросит эксепшн, а для Objective-C такая ситуация нормальная.

Это просто две разных модели, и обе могут быть частью ООП-языка.

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

Я не это имел в виду.

Методы в cpp-подобных языках называются функциями с оглядкой на истоки C++, но, с точки зрения терминологии ООП, всё равно являются посылом сообщения.

В Жаве объекты полноценны, рефлексия, все дела. Вызов несуществующего метода эквивалентен посылу сообщения ObjC, с поиском в таблице; разница только в самом конце цепочки вызова/посыла - можно ведь и не бросать исключение, дело вкуса. Сравни с C++, где такой пример вывалится в сегфолт, потому что это настоящий вызов функции по адресу, а объект - суть POD-структура с vtable-ом.

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

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

Вот-вот. Весь вопрос в том, должен ли процесс программирования доставлять удовольствие. Я считаю — должен. Но это как-то не про С++.

Я, кстати, тоже несколько раз пытался работать с C++. Не выгорело...

Вообще-то есть Go, точнее на подходе Go1 (с некоторыми языковыми изменениями). Весьма и весьма достойный язык. Единственное, «но» которое я вижу — гугловцы слегка перемудрили с компилятором, и бесшовной интеграции с C, как это реализовано в Haskell/GHC например, там нет. Правда, Go я плотно не пользовал, так что может быть не все так и плохо.

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

Вот-вот. Весь вопрос в том, должен ли процесс программирования доставлять удовольствие. Я считаю — должен.

Без вариантов. Должен. Но я от С++ быстро устаю: и морально, и даже физически. :)

Я, кстати, тоже несколько раз пытался работать с C++. Не выгорело...

А мне, похоже, предстоит ещё одна попытка «погружения». И снова исключительно ради денег. Никакого удовольствия. :)

Вообще-то есть Go, точнее на подходе Go1 (с некоторыми языковыми изменениями). Весьма и весьма достойный язык.

А я вот до Go так и не добрался. :( Пока только в планах. И пока только «посмотреть». Но времени не хватает.

DeVliegendeHollander ★★
()
Ответ на: комментарий от vaino
$ cat test.cpp
#include <iostream>
#include <stdio.h>

struct LOL {
	virtual int WUT() { return 0; }
};
int main() {
	LOL * lol = NULL;
	return lol->WUT();
}
$ g++ test.cpp -o test
$ ./test
Ошибка сегментирования
schizoid ★★★
()
Ответ на: комментарий от vaino

это разыменование некорректного указателя, а не вызов несуществующего метода

А кто писал про несуществующий метод? Речь о нулевом объекте.

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

понятно, не прочитал сообщения выше по треду

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

Абстрактный класс в C++ вполне умеет все, что должен уметь интерфейс

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

его надмножество

нет

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

это экзотика

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

можешь посмотреть на ООП в Android HAL - всё обобщённое программирование там выполняется через opaque pointer'ы, union'ы и агрегацию структур. типонебезопасно (хотя встречаются фантастические трюки вроде макроса типобезопасного цикла по сырой памяти), но компактно и эффективно

jtootf ★★★★★
()

Согласен с ТС. Сам тоже подумываю перейти на программинг ARM-ов на C++. Си-шный код уже порядком задолбал, нет гибкости, что-ли. Чего только стоят имена функций типа XXX_YYY_XXX_foo(). Один метод только занимает пол экрана - замусоривает восприятие.

Также нет в Си проверки на типы данных и еще много чего. Не понимаю, почему так любят СИ?

Сам хочу сварганить нечто грандиозное в ООП стиле для ARM7 к примеру. Как известно, МК состоит из отдельных «модулей», будь то порты I/O (GPIO), контроллеры прерываний, UART и т.п.

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

В общем, C++ рулит и педалит (конечно, при условии отключения RTTI, exceptions и т.п). Исходный код получается более компактным, понятным и читабельным.

Я писал на C++ с использованием OpenWatcom проекты для АСУТП (под x80188) и скажу честно - получалось очень даже хорошо. (На Си - это был бы ужос).

Также еще замечу, что дрова для оффтопика некоторые пишут на C++, в ООП стиле. Получается тоже все великолепно и красиво! В отличие от СИ!

Так что все неосиляторы С++ итут лесом! :)

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

а это что за зверь такой?

hardware abstraction layer. прослойка между (проприетарными) DDK и реализацией библиотек, поверх которых работает dalvik

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

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

Haskell. Надеюсь основной смысл станет понятен и найдёшь аналоги на других ЯП

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

Эмм. А что она по-твоему должна уметь? Всё, что должна уметь ос, она умеет. Драйверов мало, да, но это количественная проблема, а не качественная.

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

Забавно слышать слова «Всё, что должна уметь ос, она умеет.» в адрес системы, в которой нет поддержки множества пользователей.

geekless ★★
()

Популярные современные ОС (Windows, Linux, *BSD, Solaris и т.д.) родились тогда, когда ситуацию с C++ сложно было назвать нормальной.

А многие менее популярные проекты (L4, например) вполне себе используют C++.

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

Шаблоны инстанцируются во время компиляции. В рантайме их нет.

А что не так с stl, конструкторами копирования, возвратом объектов из функции и передачей по const reference?

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

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

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

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

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

Сила линукс именно в универсальности. Отмазки вида 95% процентов пользователей использует только 20% возможностей системы не катят. Потому что у всех эти 20% вмещают разный набор фич.

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

Так что всерьёз сравнивать производительность Гайки с другими десктопными ОС можно только тогда, когда по набору фич она хотя бы сравняется с Windows XP, не говоря уж про GNU/Linux.

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

Я уже сказал, поддержка есть, в виде расширения. С правами, группами и т.д. (это все есть на уровне ос, расширение добавляет только пользовательский интерфейс)

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

Напомню, что совсем недавно линукс был еще более гиковым, чем гайка сейчас. Тем не менее, большинство его пользователей всерьез сравнивали его с виндой, и с пеной у рта доказывали (часто небезуспешно) его превосходство над последней. И еще, гайка - это все-таки единственная десктопная ос общего назначения, написанная в основном на с++. Это хотел узнать ТС?

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

C++ is a crap, известно же

единственное, что точно известно из этого поста, дак это то, что язык Шэкспира Вам сильно не родной.

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

Частичная совместимость с posix тоже есть, в виде оберток над родным api. Много програм из линукса портировано на гайку не в последнюю очередь благодаря этой совместимости.

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

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

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

дрова для принтеров - это настоящие дрова в степени, чуть в меньшей чем в никакой.

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

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

POSIX жизненно необходим на данный момент. Поэтому ИМХО любая ОС должна поддерживать POSIX и, возможно, свой собственный API (пока мы знаем только одну хоть немного успешную несовместимую с POSIX OS (и то имеется слой совместимости для нее)).

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

дрова для принтеров - это настоящие дрова

В цитатник.

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

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

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

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

Кстати, кто-нибудь вообще пытался использовать Гайку в качестве десктопной системы? Реквестирую истории хотя бы частичного успеха, с поправкой на альфа-статус.

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

Никакого «к сожалению». Совместимость с posix даёт туеву хучу софта для платформы

потому и к сожалению, что туева хуча софта только на кривых посикс и винапи.

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

а на чём она должна быть? На BeOS API, чтоб во второй раз загнуться вместе с операционкой? Первого раза то многие не пережили, а тут некрофилы требуют добавки.

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

Я когда-то давно несколько месяцев использовал BeOS в качестве основной системы, но в конце концов моя сила воли не выдержала. Гайку даже и не пытался, потому как хачить ядро линукса под гайкой вовсе не айс.

Может бытт когда нибудь фо фан помогу им, чем смогу. А сейчас лень.

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

1. Допустим, я разработчик прикладного ПО, который хочет сделать свой продукт доступным на нескольких платформах.
2. Для этого я использую Qt, а там, где его не достаточно, юзаю напрямую POSIX.
3. Никто и никогда не заставит меня писать программу на каком-то левом тулките, работающем на одной платформе, если от этого нет экономической выгоды. А её нет.
4. Таким образом, портирование моей программы на Гайку (условно; на самом деле это применимо к любой альтернативной ОС) сводится к обеспечению Гайкой POSIX-совместимости и портированию туда тулкита. (Это мы рассматриваем сферический случай, когда программа не требует ничего, кроме Qt и POSIX.)
5. Так зачем нужна эта Гайка, если её распрекрасный API всё равно никто не станет использовать?

Резюмируя: Гайка должна иметь возможность работать как тулкит/фреймворк в GNU/Linux и Windows, иначе её ничего не светит.

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

Если бы палм отдал исходники беос, она бы развивалась (народ петиции писал, помницо). Вот у гайки есть будущее, хотт она и потеряла 10 лет. Такой объем кода просто неможет взятт и пропасть.

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

3. Никто и никогда не заставит меня писать программу на каком-то левом тулките, работающем на одной платформе, если от этого нет экономической выгоды. А её нет.

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

5. Так зачем нужна эта Гайка, если её распрекрасный API всё равно никто не станет использовать?

отучаемся говорить за всех.

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

Резюмируя: Гайка должна иметь возможность работать как тулкит/фреймворк в GNU/Linux и Windows, иначе её ничего не светит.

Согласен, было бы неплохо.

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

Линукс просто продолжил традицию: Unix -> BSD -> GNU/Linux. Это была платформа, развитие которой было выгодно очень многим. Прежде всего, на серверах и рабочих станциях, а затем и десктопе тоже.

Если бы Торвальдс делал POSIX-несовместимую поделку, всё бы закончилось фейлом еще в прошлом веке.

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

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

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

И повторю, гайка поддерживает бОльшую часть стандарта posix.

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

Перестань спорить с обезьяной! У нее линукс головного мозга!

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

не умеет

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

не гарантирует отсутствия реализации

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

требует виртуального наследования в случае сложной иерархии

Это уже тонкости реализации C++. В том, что она местами страшна я согласен.

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