C++ в ядре Linux

> Что-то я не слышу о широком распространении kylix в мире Linux. Как-то все больше Qt да GTK+ попадаются...

Не надо путать тёплое и мягкое. Kylix - хорошая вещь. Кстати, qt. Просто при его создании ситуация ещё несколько иной была и Borland ошиблись, если бы они использовали gtk, то сейчас всё по другому было бы. Нет, ядро не писали бы на паскале, но gui прилаг много было бы...

> Винда со своими плюсами полна багов.

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

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

> В лююом случае это будет дополнительной преградой в развитии Linux.

И в чем будет заключаться преграда ?

> Что-то я не слышу о широком распространении kylix в мире Linux.

Радуйся, что ты его не видел :) А если видел, то отчего ж такие вопросы задаешь ?

> Как-то все больше Qt да GTK+ попадаются...

И то и другое приплюснутое.

> > Как-то все больше Qt да GTK+ попадаются...

> И то и другое приплюснутое.

GTK - точна. Потому и называется - CTK_+_. А Qt по-моему на паскале написана.

> Не надо путать тёплое и мягкое. Kylix - хорошая вещь.

Только глючная очень. Чего стоит одна только "фича" с плавающей точкой, когда восприятие числа, например 1.23, непосредственно в C-коде (типа, float x=1.23;) зависит от того, под какой локалью запущен этот самый Kylix.

> А Qt по-моему на паскале написана.

Угу. Если хочешь задержать выход Qt 4.0, тролям об этом еще расскажи. Они год под столами кататься будут :)

> Радуйся, что ты его не видел :) А если видел, то отчего ж такие вопросы задаешь ?

Ну, не такой он уж и страшный. Глючил не по детски - это да. Но так 90% глюков на связку CLX-qt пришлось. Собственнно... ;-)

> > А Qt по-моему на паскале написана.

> Угу. Если хочешь задержать выход Qt 4.0, тролям об этом еще расскажи. Они год под столами кататься будут :)

А ты обрадуй разработчиков GTK+. Мужики-то не знают, что их творение - приплюснутое.

> Глючил не по детски - это да.

Ну вот. Ты сам ответил на свой вопрос :)

> Но так 90% глюков на связку CLX-qt пришлось. Собственнно... ;-)

А так бы они приходились на связку CLX-GTK+ и им постоянно приходилось бы чего-нибудь править, ибо в GTK бинарная совместимость - это что-то с чем-то.

> А ты обрадуй разработчиков GTK+. Мужики-то не знают, > что их творение - приплюснутое.

Может они чего и не знают, но в ChangeLog-е проскакивают C++ компилеры. Если C-компилером они не обходятся, значит там не чистый C.

> Ну вот. Ты сам ответил на свой вопрос :)

Хех. Глючил-то на сам Kylix, глючила прослойка с qt, именно по вине того самого qt - всё ему не так и новая версия не хочет понимать старую. Но это извините! Вон, в оффтопике и сейчас без напрягов можно пустить прогу времён 9x да и даже Win31! ;-)

> А так бы они приходились на связку CLX-GTK+ и им постоянно приходилось бы чего-нибудь править, ибо в GTK бинарная совместимость - это что-то с чем-то.

Скажем так, это более интересный момент. Если я правильно помню - GTK (плюс - не плюс) - не объектная, а классическая процедурная библиотека. Тогда обнговлять привязку - максимум перекомпилировать CLX. И то, зачастую (пока имена функций или структуры не поменяют) - не надо, связывание-то динамическое.

У Borland'а сейчас BuilderX рулит. Какая-то вещь, для кросплатформенной разработки, но это только под C++ - мне не интересно. Но ходят упорные слухи, что есть ещё надежда на продолжение линейки native Delphi/Kylix. Кто знает... ;-)

> Может они чего и не знают, но в ChangeLog-е проскакивают C++ компилеры. Если C-компилером они не обходятся, значит там не чистый C.

Я и говорю: Qt на паскале написана.

> Вон, в оффтопике и сейчас без напрягов можно пустить прогу времён 9x да и даже Win31! ;-)

Во-первых - это неправда :), а во-вторых почему "даже"? "Ядра" Windows95 и win3.1 (vmm32.vxd и krnl386.exe соответственно) практически идентичны (добавлены только ядерные треды) - курите Шульмана :)

Не понимаю почему никто ни видит развития этой мысли. Неужели только я? Ругать и злобствовать все мастаки. Наконец то можно ядро на С++ переписать с использованием шаблонов template <class Arc>!!Код котрый зависит от разных процессоров (а такого много) можно сделать как специализацию шаблонов template <Intel_P3>, template <Intel_P4>, AMD и так д. Paging (как память ложится на реальную память) на виртуальных функциях написать. В программе то память виртуальная, значит наиболее правильно и естествено написать ее обработку используя виртуальные функции!!! И эта идея лежала на поверхности и только эти парни ее заметили!!! ТОлько главное - не останавливаться на полпути. Если все идеи OO - инкапсуляцию и переиспользование кода по полному перенести в ядро Linux, то Linux станет еще круче -меньше и быстрее. Только че за маразм - почему Линус не хочет это добавлять в ядро - это слухи или уже точно??? Если так то его надо отстранять от руководства Linux - писать на старом C в 21 веке это маразм!!!

> Во-первых - это неправда :)

Во первых - это правда. Не для всех прог, но для многих. У меня в дипломном проекте прога на Delphi под Win2k работала, а графики (по требованию) строила в Grapher для Win3.11. И отлично работала! ;-)

> "Ядра" Windows95 и win3.1 (vmm32.vxd и krnl386.exe соответственно)

Ну да... Только часть функция в обсолете ушла, 3.11 - 16 битное, ещё вытесняющая многозадачность добавилась и т.д. А так - правда, ну просто один в один... ;-)

> В программе то память виртуальная, значит наиболее правильно и естествено написать ее обработку используя виртуальные функции!!!

И сделать это должны виртуальные разработчики.

> Ну да... Только часть функция в обсолете ушла, 3.11 - 16 битное,

Еще раз говорю - курите Шульмана. VMM и там и там - 32-битный. А окружение мало кого волнует, в том же USER32: 80% функций - это заглушки, дергающие USER16.

> ещё вытесняющая многозадачность добавилась и т.д.

Ерунда - сменили шедулер :) Большой лок при этом никуда не делся.

> А так - правда, ну просто один в один... ;-)

Самое интересное, что да.

> именно по вине того самого qt - всё ему не так и новая версия не хочет понимать старую.

Это в каком году было ? При переходе с 1.44 на 2.0 ? :)

> Тогда обнговлять привязку - максимум перекомпилировать CLX.

Ядро - оно тоже не объектное, а дрова постоянно подправлять нужно под новую миноруню версию. И это только API. Так что язык, на котором написана программа, особой роли не играет.

> Я и говорю: Qt на паскале написана.

Возьми исходники и посмотри :)

> "Ядра" Windows95 и win3.1 (vmm32.vxd и krnl386.exe соответственно) практически идентичны

Может еще и ядро Win 2k/XP/2003 "практически идентично" ядру Win 3.1 ? А ведь старые программы пускаются и работают.

Зачем? Я лучше какой-нибудь changelog почитаю.

> Может еще и ядро Win 2k/XP/2003 "практически идентично" ядру Win 3.1 ?

Нет, это другая ветка.

> А ведь старые программы пускаются и работают.

Возьми ISBN 1-56884-169-8 (5-7707-8336-2, 5-85225-043-0) и прочитай сам. А то меня уже задолбало спорить с крутыми специалистами по дельфи десятилетней выдержки.

> А то меня уже задолбало спорить с крутыми специалистами по дельфи десятилетней выдержки.

В жизни не был спецом по Delphi. Только по досовому Borland Pascal, но это было так давно, что уже всё позабывал :)

>Кстати, способ использования исключения и RTTI (что взаимосвязано) в NT было найдено народом очень давно, но вряд ли кто-нить это активно юзает, это как раз стремно. Да и MS не рекомендует, официально плюсы так и не поддерживаются в ядре :( Хотя сама MS уже давно пишет часть драйверов на плюсах. Я бы от официальной поддержки исключений в ядре не отказался бы, хотя бы код портировать было бы легче :)

Ну почему ж никто не использует ? ;)

Один мой знакомый написал (для себя но AFAIK под LGPL) небольшой плюсовый framework для kernel-программинга в NT и вполне активно его использует лет несколько. Кроме того есть такие фирменные фреймворки (за деньги) и народ иногда на них пишет.

> Если я правильно помню - GTK (плюс - не плюс) - не объектная, а классическая процедурная библиотека.

Вообще-то, оно вполне себе объектное =) Только все ОО там ручками сделано...

>GTK - точна. Потому и называется - CTK_+_. А Qt по-моему на паскале написана.

мальчик чего курил то? gtk+ написан на C , QT на C++, на паскале пишут только идиоты или люди которые изучают программирование и пишут они далеко не тулкиты.

Дядя можешь купить себе медаль. Тебе присвоено звание почетного эстонца ЛОР.

а что вы скажите про ocaml?

Наступил 2004 год, перфокарты уже отменили, но линуксоиды еще не готовы видеть плюсовый код в ядре. И это правильно, ядро это не место, где можно эксперементировать...

Читаю *ЭТО* всего 5 минут, уже блевать тянет.

> Не понимаю почему никто ни видит развития этой мысли. не у всех такая хорошая трава

> Если все идеи OO - инкапсуляцию и переиспользование кода по полному перенести в ядро Linux то это во-первых будет уже не ядро Linux во-вторых хотите объектного ядра -- посмотрите в сторону BeOS. Там ядро на C++ написано, afaik.

> Только че за маразм - почему Линус не хочет это добавлять в ядро опять же afaik, априори Линус ничего нового не хочет добавлять в ядро. а эти товарищи из исландии, что, они это уже достаточно все протестировали чтобы предлагать свои патчи в официальную ветку?

> писать на старом C в 21 веке это маразм!!! правда? а на фортране тоже наверное маразм?

> Не понимаю почему никто ни видит развития этой мысли.
не у всех такая хорошая трава

> Если все идеи OO - инкапсуляцию и переиспользование кода по полному перенести в ядро Linux
то это во-первых будет уже не ядро Linux
во-вторых хотите объектного ядра -- посмотрите в сторону BeOS. Там ядро на C++ написано, afaik.

> Только че за маразм - почему Линус не хочет это добавлять в ядро
опять же afaik, априори Линус ничего нового не хочет добавлять в ядро.
а эти товарищи из исландии, что, они это уже достаточно все протестировали чтобы предлагать свои патчи в официальную ветку?

> писать на старом C в 21 веке это маразм!!!
правда? а на фортране тоже наверное маразм?

> Paging (как память ложится на реальную память) на виртуальных функциях
> написать.
Вот хоть убей связи не вижу.

> Если так то его надо отстранять от руководства Linux - писать на
> старом C в 21 веке это маразм!!!
Проблема решается легко. Делаешь fork и разрабатываешь свою параллельную ветку ядра. Если тебя поддержит достаточное число разработчиков, если разработка станет действительно проще и быстрее - то через некоторое время ты сам по себе станешь руководителем проекта, а старое ядро к вам приjoin'ится.

Ну вы даёте
Человек (anonymous 28.10.2004 22:17:41) просто стебался.
Не надо так серьёзно относиться к его посту

Хоть я и любитель C++ (в основном за то, что за незнание некоторых существенных его тонкостей большим количеством людей считающих себя спецами на С++, их можно легко и с успехом "опустить" настоящему въедливому изучателю C++), но против C++ в ядре Linux. Для С такой манец невозможен в силу его относительной простоты. Смысл использования С++ был бы, если бы все разделяли некую идеологию мышления, которая будет заложена в С++ объекты. Но это сейчас видиться невозможным. Язык ядра и стиль программирования это еще и способ общения между людьми - разработчиками. Это надо беречь. Также С++ гораздо сложнее в изучении и написать просто уродскую и нечитаемую другими программу на нем в 10 раз легче,чем на простом С именно потому, что код на С++ более зависим от образа мышления пишущего. Таким образом я против С++ в ядре.

AlexxZ

Без С++ в ядре не будет обстракции, инкапсуляции и полиморфизма. Поэтому в современных ядрах всегда должно быть немного С++.

>Без С++ в ядре не будет обстракции, инкапсуляции и полиморфизма. Поэтому в современных ядрах всегда должно быть немного С++.

И в микроядрах тоже?
"обстрауция" - это абстракция, не так ли?
И что всё это будет делать в ядре?

> И в микроядрах тоже?

Даже в экзоядрах.

> "обстрауция" - это абстракция, не так ли?

Читать - Б.Штерн "Записки динозавра".

> И что всё это будет делать в ядре?

Обстрагировать, енкапсулировать и полиморфиться.

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

Очень просто, даже великие люди ошибаются.

Примеры:

"корабли без парусов - это нелепость" - Ответ Наполеона изобретателю парохода Фултону

"никакие камни с неба падать не могут" - Заключение Французской академии наук во главе с Лавуазье по поводу метеоритов.

"сегодня смело можно сказать, что почти все законы физики уже открыты, осталось лишь отшлифовать некоторые мелкие детали" - Лорд Кальвин, изобретатель гальванометра

"атомом для практических целей овладеть невозможно" - Э. Резерфорд

"я не верю в возможность использования атомной энергии в ближайшие сто лет" - А. Эйнштейн

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

> Очень просто, даже великие люди ошибаются.

Всегда ошибаются?

Ответ для AlexxZ:

Ну почему все С++ считают сложным? Это похоже на фобию повсеместно распространненую в России. Да прочитайте хорошую книгу по нему, выучите наконец язык.

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

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

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

Есть два примера написания ядра на C++ - Windows и AIX. И то и другое было дерьмо, пока не начали писать вставки на асме.

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

Несколько конечных автоматов :) Встречный вопрос: что дает многопоточность для одного процессора?

> Есть два примера написания ядра на C++ - Windows

А свистишь ли ты? :) И какая windows имеется в виду - под этим именем существовало несколько разных ОС.

> Ну почему все С++ считают сложным?

Из-за его нелогичности. Как в анекдоте - "понять нельзя, нужно запомнить". Хотя уже лет через пять привыкаешь, конечно, и думаешь, что по-другому нельзя.

> Несколько конечных автоматов :) Встречный вопрос: что дает
> многопоточность для одного процессора?

Известно, что ввод/вывод, например отрисовка, запись на IDE или SCSI устройство, вывод данных через сетевой интерфейс, идут без участия CPU, он в это время стоит (почему не объясняю ... лениво). Значит в ожидании конца операции и поток программы стоит, а если у нее есть другой поток, то он может поработать.

> Из-за его нелогичности. Как в анекдоте - "понять нельзя, нужно
> запомнить". Хотя уже лет через пять привыкаешь, конечно, и думаешь,
> что по-другому нельзя.

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

Конечно, если "anonymous (*) (29.10.2004 11:12:43)" не специализируется на нем, то конечно С++ будет ему не понятен. Как например мне непонятен SmallTalk, потому что я его не знаю.

> вывод данных через сетевой интерфейс, идут без участия CPU, он в это время стоит (почему не объясняю ... лениво).

Ну объясни, пожалуйста.

> Значит в ожидании конца операции и поток программы стоит,

Почему "значит"?

> а если у нее есть другой поток, то он может поработать.

Если есть "другой поток", значит эта программа - гибрид ужа с ежам.