C++ в ядре Linux

>C++ runtime support for 2.6.9 (Last update 27 october 2004)

хоть убейте, но слова 'рантайм' и 'ядро ос' для меня не совместимы...

посмотрим во что это выльется, мож чё толковое получится

И даже в софт прокрались террористы ... Другим словом их не назовешь.

А для ocaml когда патч напишут?

Мдэ, нет чтоб в сторону асма двигаться, визуал васика скоро всунут 8)

Все, не собрать его теперь TCC-ой

А почему не для Java? Круто будет!

M$ нам падлит, как пить дать M$ !

наконец-то я смогу использовать coutk вместо обрыдлого printk!

Батенька, вы сурьёзно? Вы хотите, чтобы разработка велась в 5 раз медленнее, код был непортируемым
и каждый баг было поймать в Х раз труднее? Флаг вам в руки. Напишите, только юзайте это сами.
Не хотел бы спровоцировать флейм, но ИМХО писать все подряд на АСМЕ это было ОК 30 лет назад.
АСМА в ядре должен быть разумный минимум, только там, где ведется низкоуровневая
работа с железом + некоторые оптимизации. Вон есть супернаворочанный и "суперстабильный" MenuetOS,
естественно само собой на АСМЕ. Там критических багов хватит лет на 10.
По теме: ОК!

Как грицца, что делает кот когда ему нехрен делать: яйца лижет.

На кой фиг с++ в ядре нужно. Что там других проблем нет?

ну во! теперь можно и гуйню туда засунуть будет!

Это да... qt туды, а затем и kde

C++ заметно упрощает понимание и сопровождение системы. В коде C++ проще разобраться и его проще модифицировать.

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

Для тех что считает, что концепция - говно. Рекомендую почитать литературу по ОО и наконец-то понять, что такое инкапсуляция & etc. Не трудно увидеть, что подобие этих приемов присутствует в хорошо спроектированной программе на C. Так что С++ - это просто более удобный инструмент.

Да чё там C++... Давайте на LISP-е перепишем. На нём Бог прогмает, значит одно авторитетное мнение у нас уже есть!

> Для тех кто считает (до сих пор), что объекты - это тормоза, предлагаю изучить как они выглядят на низком уровне. Тест прост - заведите класс, сделайте вызов, потом транслируйте этот код в ASM и посмотрите что собой представляет объект и собственно вызов его метода. Затем попробуйте это для наследника и вызова виртуальной функции.

Действительно, и что это все пишут на c? c++ же удобнее и быстрее. Наверное все дураки просто..

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

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

даешь php в ядро!

нихрена.. тока питон! потом можна будет пальцы топырить "вишь эти пробелы перед строчками!? это я их вставлял!!! я кул кернелхацкер!"

>> В коде C++ проще разобраться и его проще модифицировать Разбираться проще в коде, который хорошо написан. А это (умение качественно писать программы) не зависит от языка программирования. Ты, если пишешь, добавляй "имхо". Вот знаешь, мне например проще разбираться в проге на C, чем её аналоге на C++. Из всех проектов на C++ (относительно больших) лишь про некоторые я могу сказать - вот, действительно, здорово написано. Такие, пожалуй, можно пересчитать по пальцам. А вот почему-то действительно хороших программ на C куда больше.

php - для ламирофф. perl - вот енто для риел хакиров

make CC=perlcc bzImage

c++ по любому более сложный инструмент, чем с. :) Так что... Лучше не рисковать. ;) А то, нахакают. %))

Sledushim shagom budet jadro na Haskelu :) Nu ili nakrajniak CLisp!

>И почему-то (дураки наверное потомучто, а иначе как?) от этих идей очень быстро отказывались.

Буш смеятся но именно по этому (что дураки) ;) . Как-то Линус уже отвечал на это вопрос.

PS: На самом деле (ImHO) проблема в наличае адекватных плюсовых инструментов (в основном это то, что у g++ живет в libstd++) для писания кода ядра и топик как раз про попытку такой инструментарий создать.

PS2: Не приведи господь если народу понравится ;)... опять начнут курочить дизайн ядра, но на этот раз под плюсы ;)

Хорошо было бы если бы Линус все-таки включил этот патч в ядро. Еще лучше, если бы как опцию. С портированием виндовых драйверов было бы значительно меньше проблем. (По крайней мере у меня :))

писец, развели флейма... форк как форк... нАрмАльные пАцАны будут юзать... а мы, красноглазые, и vanilla'й обОйдемся...

Ур-ра-аа! Даешь метапрограммирование в ядре!

Маразм крепчал, деревья гнулись...

"мы с не знаем, зато умеем с++, и нам очень хочется засунуть что-нибудь в ядро линуха. вот такие мы извращенцы"

А что такое метапрограммирование, почему оно будет именно в ядре, и с чего ты взял, что С++ удобен для этого метапрограммирования?

>>Действительно, и что это все пишут на c? c++ же удобнее и быстрее. Наверное все дураки просто.

Ну допустим не все QNX например писан на C++ тормозом не считается

Ну и что вы тут раскудахтались ?
C++ и ООП хорошо знаете ? Много ядреного кода написали ?

Люди полезную вещь делают, в отличии от вас.
Лиш бы обосрать, одним словом LOR :|

Лучше б ADA прикрутили... там и типизация и рандеву ... надёжность.

>Для тех что считает, что концепция - говно.

Кстати, о концепциях. Алан Кокс считает, что потоками пользуются те, кто не умеет программировать конечные автоматы.

Как насчет многопоточной концепции?

Линус против С++ в ядре - для меня это достаточный аргумент.

Вспоминается случай с Торвальдсом, который божился перед Тененбаумом переписать Linux на C++. :-)))

>А что такое метапрограммирование, почему оно будет именно в ядре, и >с чего ты взял, что С++ удобен для этого метапрограммирования? Ты слишком часто задаешь вопросы. Попробуй найди ответ на первый и возможно остальные два тебя перестанут интересовать.

Это просто ни к чему ИМХО.

Винда со своими плюсами полна багов. Не хватало нам еще путанного, но "объектно-ориентированного" проектирования ядра.

В топку!

P.S. C -- это язык для системного программирования, а C++ -- для прикладного.

А я на bsd перешел, мне пох ;))

Именно, думаю, что с С++ делать ось Just for Fun не получится, и может уменьшится число контрибуторов. Хотя это все равно решать тем, кто больше всех участвует в разработке. В лююом случае это будет дополнительной преградой в развитии Linux.

Оч полезная штука. Жалко что в основную ветвь это дело не внесут.

Есть такая конторка, OSR (www.osr.com). Одна из авторитетнейших в области kernel-mode программирования для NT. Дык вот они грят, что скармливают весь свой сишный код компилятору C++, и он _всегда_ находит ошибки, которые пропускает сишный компилятор. Это они рекомендуют делать всем. Крутость с++ как раз в том, что у него офигенная обратная совместимость с си. Можно писать на с++ и без RTTI, исключений, полиморфизма и даже без классов и даже при этом иметь более качественный код, хотя бы благодаря более жесткой типизации плюсов. Для меня с++ - это прежде всего, жесткая типизация, автоматическое освобождение ресурсов через деструкторы локальных объектов и хороший коэфициент повторно используемого кода. Кстати, способ использования исключения и RTTI (что взаимосвязано) в NT было найдено народом очень давно, но вряд ли кто-нить это активно юзает, это как раз стремно. Да и MS не рекомендует, официально плюсы так и не поддерживаются в ядре :( Хотя сама MS уже давно пишет часть драйверов на плюсах. Я бы от официальной поддержки исключений в ядре не отказался бы, хотя бы код портировать было бы легче :) Кстати STL от SGI прекрасно работает, только что аллокатор свой прикрутил.

Угу. Только меня этот гемор с типизированием как-то раз порядком подз**бал. Компилил libxml++ и несколько раз огребал ошибки из-за того, что ф-ция требовала char*, а std::string::c_str() возвращал const char*.

Каждый язык хорош для тех целей, для которых изначально создавался. Что-то я не слышу о широком распространении kylix в мире Linux. Как-то все больше Qt да GTK+ попадаются...

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

Чу. Смотри bagtraq. Сплошь buffer overrun. Ошибка, которая при правильном программировании на плюсах в принципе невозможна. А на си сплошь и рядом. Ты скажи, сколько MS код чистили, сколько фиксов за пятнадцать лет? Если бы C++ стандартизировали бы в 80-х, ядро NT было бы менее глючное.

Пожет, ещё и иксы на 40-е прерывание пустить, как в Menuet? Или на Бейсике написать?

http://forum.exler.ru/uploads/post-77-1098963667.jpg :)

> Ошибка, которая при правильном программировании на плюсах в принципе невозможна

При правильном программировании она невозможна нигде. А в С++ она возможна при неправильном программировании. С и С++ в этом отношении - близецы-братья.

абсолютно ненужная вещь - не должно быть в ядре плюсов - не нужны они там;

в топку данное изделие;

В сторону асма двигаться тоже не надо - бред. Лучше просто С.

может С++ в ярде и не надо (что интересно на это скажет Линус?), а вот забэкпортить эти их оптимизации обратно в g++ было бы недурно. Все-таки сокращение времени типовой операции с 18 до 2.1 мс это не хрен собачий.

Статью на их странице кто-нибудь читал? я имею в виду ту что в PDF