LINUX.ORG.RU

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


0

3

Всем привет!

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

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

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

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

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

Все же советую прочитать Страуструпа на английском

Если я снова и снова прочитаю Страуструпа на английском, в русском переводе внезапно изменится терминология? Хитрый ход, вероятно что-то из высокой магии.

перестать принимать википедию как истину в последней инстанции

Википедия в данном случае права, а ты — нет. Объяснять тебе, что термину operator соответствует русский термин операция — всё равно, что всерьёз объяснять арифметику тому, кро прогулял её в школе. Изволь самостоятельно ознакомиться с матчастью и не задавать наивных вопросов.

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

Удачи. Зафрендил.

Ты не просто слабак, ты еще и лжец. Как было 20 игнорастов-слабков, так и осталось.

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

«Operator» по-русски внезапно «оператор». Ну и как тогда понимать «Operator Functions» из оригинала? Как как там в твоем переводе? Не «Операторные ли функции»?

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

«Operator» по-русски внезапно «оператор».

Есть такое отклонение психики, когда человек упорно отрицает принятые обществом нормы, потому что не в состоянии их усвоить.

Какую книгу не возьми (и под книгой я имею ввиду нормальную акедемическую книгу, а не изданный в соседнем подвале «самоучитель»), везде ты найдешь правильную терминологию. И только в твоих мечтах ««Operator» по-русски внезапно «оператор»». Действительно внезапно.

Открываем, например, Ахо и Ульмана и на странице 27 читаем примечание:

«Здесь следует обратить внимание на перевод термина statement. [...] Обычно при перевод используется термин оператор, но в данной книге посвященной формальным грамматикам, этот термин имеет собственное значение. Поэтому при переводе термина statement было использовано понятие инструкция.»

Понимаешь, голова твоя деревянная, что тут написано: оператор — это statement, а никакой не operator. И так как этот термин конфликтовал с термином из теории формальных грамматик, переводчикам пришлось даже делать отдельное примечание, чтобы выкрутиться.

Так что еще раз повторяю, не читай говнокнижки, читай нормальную литературу.

Зайдём с другой стороны. Такие словосочетания как «оператор-выражение», «оператор цикла», «условный оператор» ничего не пробуждают в памяти? Ну, давай вспоминай, я в тебя верю: первый курс, злобный препод, конспект, первое знакомство с изучаемым предметом... Нет? Ничего не вспомнил? Эх ты..

Ну и как тогда понимать «Operator Functions» из оригинала? Как как там в твоем переводе? Не «Операторные ли функции»?

Ты предлагаешь мне это проверить? Ты до сих пор не скачал указанную книгу, это крайне печально.

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

С++ ещё большее УГ

Ололошеньки лоло.

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

+100500 - кексты пишут на С++ :)

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

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

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

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

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

Как говорится - работает - и не трогай :) . Поэтому все по старинке и кодят на Си. Тоже касается и микроконтроллеров.

Все дело в инерции мышления. :)

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

не осилили?

Естественно не осилил, как же иначе, но для работы моих знаний оного хватает

сочувствую

а вот этого не надо

C - почти-что-ассемблер, со всеми его достоинствами и недостатками. Всё.

С++ же - попытка прилепить к низкоуровневому (с натяжкой, конечно, но всё таки) языку высокоуровневость. Хотели как лучше, а получилось как всегда:

- многие высокоуровневые фичи реализованы хуже, чем в аналогах (сравни template-ы с теми же лиспомакросами, или например ООП с уже упомянутым выше ObjectiveC-шным). От STL, с его «ехал итератор через итератор» плакать хочется. C boost чуть получше, но всё равно, многие фичи как будто писали инопланетяне для инопланетян. Про дебаг всего этого дела я вообще молчу.

- потенциальная возможность писать низкоуровнево и высокоуровнево в одном и том же месте. И ведь пишут, же, йодоводород, мешают в одну кучу адресную арифметику и auto_ptr(утрирую, конечно, но недалеко от правды), сишный io с потоками итп! Проблема программистов? Возможно, но даже нет возможности проконтролировать это опциями компилятора.

Это лишь малая часть претензий, просто, что с ходу вспомнил.

Да, мнение быдлокодера-неосилятора, ессесна. Будет что ответить, мусьё осилятор?

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

Ололошеньки лоло.

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

Все дело в инерции мышления. :)

такой вопрос, можешь перечислить языки (кроме C/C++) с которыми ты хотя бы поверхностно знаком?

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

такой вопрос, можешь перечислить языки (кроме C/C++) с которыми ты хотя бы поверхностно знаком?

Увы, только С/С++

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

Что за простынка?

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

многие высокоуровневые фичи реализованы хуже, чем в аналогах (сравни template-ы с теми же лиспомакросами, или например ООП с уже упомянутым выше ObjectiveC-шным).

даже больше - есть много узкоспециализированных ЯП, в которых свои «высокоуровневые фичи реализованы» лучше чем в других, можешь сравнить между собой те же ObjC и лисп и покритиковать их

От STL, с его «ехал итератор через итератор» плакать хочется.

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

Про дебаг всего этого дела я вообще молчу.

расскажи, не стесняйся

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

отличная возможность, есть кстати во многих ЯП, в том числе в любимом многими C#

сишный io с потоками итп!

я тебя удивлю - но во многих ЯП есть разные подходы для решения одних и тех же задач, даже в «сишном io», про набор разномастных библиотек и говорить нечего

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

Нет аргументов - т.к. в простынке бред.

Не отходи от темы ТС-а. :)

- причем тут STL и Boost при написании драйверов и ядра ОС? Там STL и Boost не используется (если не в курсе) - так что мимо.

- что за хрень с «низкоуровнево и высокоуровнево в одном и том же месте» ? я не распарсил,честно. Поясни.

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

ТС спрашивает, почему не пишут на С++ядра, дрова, кодят для МК..

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

Исходный код, написанный на C++ лучше читается, воспринимается, он короче и т.п. Да и просто - он красивше! :)

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

Так что - кто хочет использовать С++ при написании ядер, дров, МК - тот использует - и доволен по уши.

Кто не хочет - ну, использует Си для поднятия своего ЧСВ. :)

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

даже больше - есть много узкоспециализированных ЯП, в которых свои «высокоуровневые фичи реализованы» лучше чем в других, можешь сравнить между собой те же ObjC и лисп и покритиковать их

могу, но фигня в том, что и (коммон) лисп и ObjC - язвки не узкоспециализированные, а вполне себе общего назначения

в С++11 добавили сахарку

- далеко не всегда и не везде есть возможность использовать компиляторы с его поддержкой

- шёл 2011й год, угу.

расскажи, не стесняйся

Instantiated from 'static OI std::_copy<<anonymous>, <template-parameter-1-2> >::copy(_II, _II, _OI) [with _II = std::_Rb_tree_iterator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::serialization::compat_ver_3::Cfg::DataBase> >, _OI = std::insert_iterator<std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Cfg::Database, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Cfg::Database> > > >, bool <anonymous> = false, <template-parameter-1-2> = std::bidirectional_iterator_tag]'

как-то (вроде бы на rsdn) даже пробегала картинка со скрином VS с подобной хренью

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

Исходный код, написанный на C++ лучше читается

ха-ха-ха

он короче

раскажи про «короче» хаскелистам

lazyklimm ★★★★★
()

почему системный софт (ядра ОС, драйверы, биосы) не пишут на С++

И будет ядро весить полгига, а coreutils работать только на восьмиядерном процессоре…

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

Там STL и Boost не используется

без темплейтов C++ - вообще инвалид

lazyklimm ★★★★★
()

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

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

Взял с полки томик Страутрупа, а там: «перегрузка операторов». Вот так вот. А за перевод statement как оператор, надо бить лейкой по голове.

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

Что за книга, кто переводчик, кто издатель?

А за перевод statement как оператор, надо бить лейкой по голове.

Мнения анонимуса-то ученые люди и забыли спросить.

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

могу, но фигня в том, что и (коммон) лисп и ObjC - язвки не узкоспециализированные, а вполне себе общего назначения

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

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

тоже самое можно сказать про C, fortran, ObjC и другие «промышленные» ЯП

шёл 2011й год, угу.

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

Instantiated from

во-первых это не дебаг, во-вторых это не проблема ЯП, тот же clang дает вменяемые сообщения об ошибках

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

Что за книга, кто переводчик, кто издатель?

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

Мнения анонимуса-то ученые люди и забыли спросить.

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

Кстати, а почему никто не упомянул ABI плюсов с его instant satisfucktion при попытке использовать плюсовый код из другого языка?

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

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

Бьерн Страуструп. Язык программирования С++. Специальное Издание. Перевод с английского под редакцией Н. Н. Мартынова. Москва, издательство Бином, 2011.

Глава 11. Перегрузка операций.

geekless ★★
()

Oleg already did it!

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

во-первых это не дебаг

что нашёл, это к читабельности внутреннего представления шаблонов

тот же clang дает вменяемые сообщения об ошибках

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

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

а сейчас код ломаться не будет, что ли?

тоже самое можно сказать про C, fortran, ObjC и другие «промышленные» ЯП

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

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

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

ABI плюсов с его instant satisfucktion при попытке использовать плюсовый код из другого языка?

да, есть такая фигня, приходится пейсать сишные врапперы (tripple facepalm)

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

а сейчас код ломаться не будет, что ли?

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

ну и опять же, не всегда есть возможность его использовать

и опять же это для практически любого ЯП, будешь писать на CL, например, и в случае чего тебе сходу предложат купить ListWorks за полтора килобакса, т.к. sbcl кривой, батареек нужных нет и пр., про ObjC и говорить не стоит


фортран я бы вычеркнул

его как раз точно нельзя вычеркивать - на нем очень много legacy

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

а в прошлом ответе ты упрекал плюсы, что они медленно развиваются ;) да и про «кровь из носу» вопрос не стоит, использовать новые возможности никто не заставляет

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

да, есть такая фигня, приходится пейсать сишные врапперы (tripple facepalm)

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

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

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

ну вот, спрашивается, кто мешал сделать это раньше?

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

упрекал, и продолжаю упрекать. Потому что quod licet iovi...

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

будешь писать на CL, например, и в случае чего тебе сходу предложат купить ListWorks за полтора килобакса, т.к. sbcl кривой, батареек нужных нет и пр.

для серьезного коммерческого софта эти пара килобаксов - тьфу, а помимо sbcl есть, например, Clozure.

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

в случае С++ это как раз не проблема

то-то на Qt ни одной толковой обёртки (окромя PyQt/Pyside) нет

легко ли использовать код на CL из питона

зависит от реализации, но в общем случае, я думаю, решабельно. Но зачем?

код из Java в ObjC

JNI ?

но сравнивать CL/Java с C++ в общем случае неспортивно, последний же многими декларируется как надмножество(ололо) C.

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

ну вот, спрашивается, кто мешал сделать это раньше?

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

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

я сначала сам пробую, перед тем как на работу тащить что-то, а для личного бюджета пара килобаксов хоть и не критическая цифра, но ей можно найти более другое применение чем на пробу новой IDE

а помимо sbcl есть, например, Clozure.

тоже ведь не идеальное решение на все случаи жизни

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

то-то на Qt ни одной толковой обёртки (окромя PyQt/Pyside) нет

http://en.wikipedia.org/wiki/Qt_(framework)#Bindings

а качество обертки зависит от рук ее автора и желания максимально подогнать ее под целевой ЯП

зависит от реализации, но в общем случае, я думаю, решабельно. Но зачем?

пока на CL не родят что-то, что захотят использовать с другими ЯП, наверное и не зачем, а так - по том же причинам, что и для С++

сравнивать CL/Java с C++ в общем случае неспортивно

а ты вот сравнил ;)

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

а для личного бюджета пара килобаксов хоть и не критическая цифра, но ей можно найти более другое применение чем на пробу новой IDE

так там же есть пробная версия, для дома для семьи вполне достаточно

тоже ведь не идеальное решение на все случаи жизни

ну да, у него свои проблемы

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

так там же есть пробная версия, для дома для семьи вполне достаточно

и она пригодна для решения домашних же задач

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

Но, хотя ты и формально прав насчет операторов/операций, скажем у Вундервуда и Джосаттиса тоже используется оператор вместо операции (причем оператор ПРИСВОЕНИЯ вместо присваивания как я привык). Это конечно к переводчику вопрос, но все же ИМНО речь идет о каких то совершенно тонких тонкостях русского язЫка. Человек, употребляющий слово оператор всегда может сказать что юзает кальку с английского слова, как напр слово «тред». Т.е. ты зануда;-)

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

http://en.wikipedia.org/wiki/Qt_(framework)#Bindings

да, видел. Чуть менее чем все реализованы через SMOKE, если я правильно понял? Оно может быть и юзабельно, но что-то я не вижу сотен программ, реализованных на.

а так - по том же причинам, что и для С++

на CL не пишут низкоуровневые библиотеки. На C++ - очень даже.

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

Бггг... у меня «Перегрузка операторов», но издание 2006-го. Что и требовалось доказать — разброд и шатание в терминологии.

P.S. Ничего против перевода operator как операция не имею. Хороший, разумный перевод.

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

будто что-то плохое

Отнюдь нет. Я тоже зануда.

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

Это лишь малая часть претензий, просто, что с ходу вспомнил.

Да, мнение быдлокодера-неосилятора, ессесна. Будет что ответить, мусьё осилятор?

дети плачутся и едят кактус?
я не использую STL boost итд
приват лайбрери которые работают и в ядрёном режиме

если вы не осилили написать аналог string/vector/list самостоятельно
тогда вы очевидный неосилятор

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

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

если вы не осилили написать аналог string/vector/list самостоятельно тогда вы очевидный неосилятор

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

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

Чуть менее чем все реализованы через SMOKE, если я правильно понял?

нет, таковых четыре из всего списка

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

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

на CL не пишут низкоуровневые библиотеки.

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

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

если вы не осилили написать аналог string/vector/list самостоятельно

А нафига мне язык, в котором нужно велосипедить?

нечего валить на его библиотеки

STL же вроде часть стандарта, нэ?

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

хреновый программист может выучиться, дурак - навсегда

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

Давай ты сначала школу/техникум/универ закончишь, пойдешь работать, а потом мы с тобой поговорим, ок?

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

Где его взять в моём уютненьком арчике? Уже интересно :-)

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

Почитал на википедии статью... не понял как структуры наследуются то... расскажи подробнее.

Допустим я описал структуру A. Как мне описать структуру B, чтобы она взяла в себя все поля от A (и они оказались в начале её определения). И чтобы если я подставлю указатель на B в то место, где требуется указатель на A без приведения типа, то у меня не будет Warning о несовместимом типе.

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

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

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

Ну так не интересно))

А как описываешь так структуру? Я по статье на википедии не очень-то понял. Понял только что там как-то используются «анонимные структуры».

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