А ты думал Вижуал Бэйсик?   

Я думаю C  

Гугление дало что там оба.

ООП нужно применять там, где думаешь о сущности, как об объекте. В ядре, конечно, надётся много всего, что можно представить в виде объекта, но я уверен в том, что эти сущности представлены структурами. В системном программировании чаще сталкиваются не с объектами, а чем-то типа: «Сработало прерывание, выполнить ряд действий». Не вижу большой разницы в том, чтобы использовать для инициализации функцию, которая возвращает структуру и набор функция для работы с данной структурой.  Я знаком с ядром только ооочень и очень поверхностно.
К тому же, кто сказал, что на Си нельзя писать ООП код? Наверняка в ядре не один пример ООП на Си. И я могу привести примеры ООП на Си (и не один). Даже самые крупные (да и самые крутые) проекты KDE и Qt используют во многих местах реализации Сишные приёмы ООП (шаблоны через макросы, например).
Пространства имён — другая удобная штука, появившаяся в Си. Во многих крупных проектов всего несколько пространств имён. Если ввести больше, то будет путаница. А если учесть возможность раздельной компиляции, то можно пространства имён вообще отбросить при грамотном проектировании.
Шаблоны: вполне реализуются макросами, что даёт некоторые преимущества перед С++-ными (я особо не задумывался над тем, какие, но верю разработчикам KDevelop). Да и применение шаблонов с системном программировании станет нонсансом.

Объяснение того, что ядро слишком сложно и его всё равно могут читать единицы Си программистов, вообще абсурд. Есть книги (Таненбаума, Мортона): читайте и разбирайтесь. Если переписать ядро на С++ оно станет ещё запутаннее.
У меня есть небольшой опыт работы с крупным С++ проектом (Mozilla): c многочисленными шаблонами, классами просто мозг сломаешь, разбираясь в незнакомом коде. Нужно не просто проследить вызовы функций, а
1) Найти, что это за класс.
2) Найти дефолтный конструктор.
3) Если заинтересовались методом, то нужно понять откуда этот метод взялся (а при множественном наследовании ещё и чей вызывается).
4) Многие методы перегружены. Причём типами, которые вам не знакомы и могут иметь похожие названия.
Даже c Jump To Declaration это много и много секса. В процедурном коде можно разобраться быстрее. 
А что мы видим в предложении? Кучка кодеров (пускай даже хороших) залезла в сложнючий код на Си и они жалуются, что слишком сложно всё. Конечно, хорошо юзать библиотечные абстракции и десяток своих классов. Но тут речь об очень большом проекте.

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

Кроме того, на мой взгляд, хороший системщик может писать хороший ООП код, а вот хороший программист ООП — далеко не всегда.

Добавлено через 1 минуту и 23 секунды

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

 

Зачем смотреть в код чтобы понять ядро, когда можно посмотреть на модель ?ИМХО понятнее и доступнее.

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

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

Как тот так и другой не всегда.

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

Я не извращенец, чтобы сидеть и дебажить ядро, я хочу цивилизованные диаграммы, как все это работает 

Добавлено через 7 минут и 36 секунд

В чем здесь проблема?

Это сообщение отредактировал(а) En_t_end - 16.7.2008, 22:50

ЗЫ powerfox, баггинз, я ничерта не понимаю как ядро работает. Потому что я ленивый   безумный тип. Незнаю тому кто в этой туче кода разбирается необходимо срочно сохранить днк для потомков.

Добавлено @ 23:09
И ещё не надо на меня наезжать. Я специально привел в начале темы аргументы против. Я не хочу писать ядро. Воть.

Добавлено @ 23:16
Есть мнение, что C - "портируемый" ассемблер. Интересно, если бы ядро было бы написанно на #чистом ассемблере# мне бы сейчас с таким же рвением доказывали что #...# - это удобно в больших проектах.

Это сообщение отредактировал(а) En_t_end - 16.7.2008, 23:17

Есть куча аргументов против этого мнения, но мне лень их искать и писать сюда. Первую сотню искать в причинах создания языка C++.

Это сообщение отредактировал(а) En_t_end - 16.7.2008, 23:24

на C + perl надо переписать!   

Это явно какая-то глупость, во первых, я где-то читал статью, в которой говорилось, что там 60 000 000 строк кода...
Во вторых, переписать это одно, а протестировать весь код это другое...

К тому-же, если проект написан на Си, это не значит что он не объектно ориентированный. 

Lazin, 

Разные версии ?

Насколько мне известно, это возможно, если все члены проекта будут следовать общей конвенции. Правил в которой будет больше чем кода который кто-либо захочет внести в проект единовременно.
Почему ещё ни один человек не согласился, что C - это неудобно в такого масштаба проектах?
Я не буду настаивать больше ни на чем, я согласен что это тупая затея, технически не реализуемая. Но с тем что C удобен для крупных проектов я не соглашусь никогда.
ЗЫ Я имел, хоть и скудный, опыт разработки большого проекта на C(кассовая программа). Он загнулся ещё на этапе проектирования, так как правил в конвенции оказалось настолько много, и требовали написания стольких "велосипедов", что решено было оставить эту глупую затею.
Хотя на C++ подобно TinyPIM Пабло Халперна эта задача решилась бы меньшей кровью.

К слову, хроший пример - xine 


Реализуемая. Просто это ни кому не надо. Это отдельный проект.


Речь про системное программирование?

А как же технические проблемы изложенные в начале темы?
ЗЫ Я спрашивал как раз о их правдивости.

[offtopic]

/me поперхнулся
Друже, тебя дизориентировали.
http://en.wikipedia.org/wiki/Source_lines_of_code
[/offtopic]

http://www.linux.org.ru/view-message.jsp?msgid=2529251
Решил так, пусть все умники пишут на C и ассемблере, а мы как-нибудь без велосипедов. Воть. удачи

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


ЗЫ
Как-то не заметил что тема висит в общих вопросах...

Модератор: Тема перенесена