Обычно как раз требуется очень приличная квалификация программиста C, чтобы код работал быстро, чётко и прозрачно. Медитировать над классами можно в user-space, в ядро же засовывается очень специфичный базовый код - классы там нах не нужны, равно как и в широком классе вычислительных задач (обычно они там очень вредят).
Странно читать рассуждения о необходимой квалификации программиста плюсов в то время как ООП - это концепция быстрого и простого создания ПО.
P.S. Уважаемый сэр видел код Linux? Может даже задумывался почему в нём в большинстве случаев common case выполнения функций - это fall through до первого return? Да и вряд ли можно придумать нормальную иерархию классов, т.к. а эффективном моноядре каждая подсистема тесно связана с другими...
2Murr
> Может даже задумывался почему в нём в большинстве случаев >common case выполнения функций - это fall through до первого return? >Да и вряд ли можно придумать нормальную иерархию классов, т.к. а >эффективном моноядре каждая подсистема тесно связана с другими..
Как тут уже выше правильно заметили ООП это последняя стадия ООД - так что если переписывать (именно переписывать !!!)
ятро на C++ то нужно начинать с его перепроектирования
плюс ко всему пока что нет адекватного инструмента для работы ++
в КМ (g++ часть конструкций языка держит в UM-библиотеках)
А вот про скорость не волнуйся - благодаря тому что C++ это
гибридный язык - узкие места можно будет обойти за счет некоторой
потери абстракции
А так на ++ прекрасно пишутся дрова для NT/2K/XP так что сказка
про 100% кода ядра NT на С/ASM это только сказка ...
> Но они забывают, что C++ это полное надмножнство C ...
Нет. Не надмножество. Если б он был надмножеством, то любая верная программа на C являлась бы верной программой на C++ причем с той же семантикой. Что, очевидно, не так.
Драйвер железяки - это исключительно тривиальная вещь. Регистрирует прерывание, регистрирует диапазон ввода-вывода, ловит прерывание, делает минимальный post-processing и I/O.
Нахрена там нужен C++?
А по поводу Linux - его разработчики используют C не потому что настолько глупые, что не видят огромной ценности использования плюсов, а скорее наоборот ;)
> Это уже ближе к делу. Наверное это Эндрю имел в виду когда говорил о религиозных проблемах с C++ у теперешних разработчиков Линукс?
С теоретической точки зрения это религиозные проблемы. С практической точки зрения это попытка избежать всех проблем, _неминуемо_ последующих за использованием C++.
Зачем искать себе на попку проблемы, когда и так все хорошо?
Вообще, ничего не имею против плюсов (хотя во всех отношениях считаю Java более продвинутой), но желание некоторых пионэров засунуть плюсы всюду куда только можно уже набило оскомину. Не можешь писать нормальный код - тогда в сад, не надо лезть со своими плюсами. Типа примеров в книжке Небета, которые 1 в 1 переписываются на C, зато он гордо их называет плюсовыми... фак.
2Murr> ООП - это концепция быстрого и простого создания ПО
ну, это ты парень загнул...
я бы сказал по-другому:
сторонняя библиотека, созданная с ипользованием концепций ООП, как правило, может быть легко использована другими для быстрого создания ПО; при этом часто не требуется высокая квалификация (сколько таких программеров знаю...)
а вот создать такую библиотеку на основе ООП - это очень не хилый труд, требующий порою весьма высокой квалификации.
Драйвер железяки - это исключительно тривиальная вещь. Регистрирует прерывание, регистрирует диапазон ввода-вывода, ловит прерывание, делает минимальный post-processing и I/O.
Ну не все железяки простые, некоторые имеют на борту процессоры с
собственным фирмваре и кучей режимов/подрежимов работы.
>сторонняя библиотека, созданная с ипользованием концепций ООП, как правило, может быть легко использована другими для быстрого создания ПО; при этом часто не требуется высокая квалификация (сколько таких программеров знаю...)
Эээ... по вашему нет разницы между модульным программированием и объектно-ориентированным? ;)
Всю жизнь считал, что ООП сближает предметную область и кодирование, по сути облегчает процесс кодирования, что и является самым большим достоинством. ;)
То есть вы можете аргументированно возразить Эндрю Мортону и, в частности, вот этому его высказыванию: "I love C++. Yo can do marvellous things in it. The language can really watch your back for you. Going back to C for Linux was THE HARDEST part for the first couple of months. So crude, so bug-prone..." ?
Обычно программы управления железом реализуются в user-space (по крайней мере у душевно здоровых людей). Драйвер - это другое (его задача куда меньше).
> Эээ... по вашему нет разницы между модульным программированием и объектно-ориентированным? ;)
конечно, есть разница :-)
только я стараюсь делить программистов, как минимум, на две категории (сам прикладной математик):
1) те, кто использует;
2) те, кто создает
в прошлом посте я хотел сказать, что ООП позволяет резко снизить планку для представителей первой категории; а сложности алгоритмов и методов никто, конечно, не отменял; и ООП тут не поможет... :-(
2anonymous (*) (2003-08-13 16:50:03.981016);
"Но они забывают, что C++ это полное надмножнство C и поэтому на C++ по определению всегда можно написать то же, что и на C."
Ты обкурился и гонишь ! Нукася, забатцай мне такое на плюсатом 8)
-----------------------------------------------------------------
#include <stdlib.h>
struct flex {
int mem;
int arrayWoBoundsSpecified[];
};
struct NotAflex {
int a[]
int mem;
};
int main()
{
size_t len = sizeof(struct flex);
struct flex *p = malloc(len + 100);
p->arrayWoBoundsSpecified[49];
struct flex *p2 = malloc(len + 80);
p2->arrayWoBoundsSpecified[39];
struct flex *p3 = malloc(len + 3);
p3->arrayWoBoundsSpecified[0];
struct flex *p4 = malloc(len + 1);
}
-----------------------------------------------------------------
Плюсы это отстой и тупик программирования. Читайте Страустрапа, он честно признался что плюсы изначально через жопу делались методом (то чего нам нехватает мы воткнём, а на последствия пох..)
> То есть вы можете аргументированно возразить Эндрю Мортону и, в частности, вот этому его высказыванию: "I love C++. Yo can do marvellous things in it. The language can really watch your back for you. Going back to C for Linux was THE HARDEST part for the first couple of months. So crude, so bug-prone..." ?
Могу конечно. Коммерческая фирма может позволить себе надрочить десяток программистов и использовать C++ в каких-то проектах. При использовании волонтеров этого делать нельзя ни в коем случае.
Сейчас поднимается время от времени один вопрос - надо ли использовать С++. Вы думаете кому-то из топ-девелоперов хочется объяснять почему не надо использовать те же exception? Или переопределение операций? Или шаблоны?
Вместо одной темы (по которой есть уже фак), будут обсуждаться десятки тем. Будут присылаться сотни заведомо кривых патчей.
И все это без единого мнения за, кроме не умения программировать на С. Нет никого, кто мог бы внятно объяснить, зачем нужен C++?
"THE HARDEST part for the first couple of months."
во разорались про плюсы, хоть бы кто-то сказал чем конкретно плюснутое ядро будет лучше, а то создается впечатление, что лучше будет только некоторым личностям которые смогут сказать: "а вот ядро на ц++ написано!"
>Драйвер железяки - это исключительно тривиальная вещь. >Регистрирует прерывание, регистрирует диапазон ввода-вывода, >ловит прерывание, делает минимальный post-processing и I/O.
А драйвер FS ? ;)
>Нахрена там нужен C++?
Но ведь пишут же - а ++ как и было правильно
замечено служат для экономии рабочего времени программиста
>А по поводу Linux - его разработчики используют C не потому что >настолько глупые, что не видят огромной ценности использования >плюсов, а скорее наоборот ;)
Ну вообще периферийные устройства в PC уже десятки лет используют DMA, но для техники, не имеющей средств ввода-вывода кроме polling, может и правда имеет смысл делать кусок в ядре (it's not the common case).
Кстати, зачастую такие устройства обслуживаются специализированными процессорами без MMU. Никакого overhead при переключении на ISR на них нет.
P.S. Что такое "kernel mode"? "mode" какого компонента PC? ))
>> Но они забывают, что C++ это полное надмножнство C ...
>Нет. Не надмножество. Если б он был надмножеством,
ну почти полное надмножество... В C++ более жесткая проверка синтаксиса. Такие опасные и поощряющие разгильдяйство вещи, как вызов ф-ций без прототипов, неописание аргументов функций и.т.д. в C++ запрещены. Да и в C, похоже, все идет к ужесточению синтаксиса. K&R С уже не совсем ANSI С ;)
Murr:
>Странно читать рассуждения о необходимой квалификации программиста >плюсов в то время как ООП - это концепция быстрого и простого создания >ПО.
ООП это концепция разработки сложных и больших систем. По крайней мере при разработке C++ автор именно это имел в виду. А сложные и большие системы мало имеют общего с низкоквалифицированными програмистами. ;)
Знаете, просто есть такая вещь, как привычка. Наверное, все дело в этом.
И много бы людей можно было заставить лет так 30 писать на C? Многие, наверное, ответили бы: "какой там C, это мы напишем на Fortran, PL/I или Кобол! Зачем нам C?" ;-)
sS:
Нет кодом ядра (kernel address space code), но в параде мод он не участвует.;)
Этот термин из документации MS что ли взят? Помню у них такое чудо встречал ...
Причем тут видео? Ты ей просто даешь память под текстуры, а карточка самостоятельно их вытягивает (без всякого подсобничества процессора). Или имеется в виду кадровый буфер? Тогда зачем там драйвер? Битблиттинг можно и в user-space реализовать ...
Некоторые возможности C++ требуют специальной поддержки со стороны компилятора и run-time библиотек. То есть неявно генерируют код (причём неизвестно какой). А это ведёт к потере абсолютного контроля над кодом (имеющимся в C, за исключением setjump/longjump), что для ядра как-то не очень :)
Да и для создания эффективного кода на C++ требуется гораздо более высокая квалификация программистов. В C++ возможностей больше, поэтому наломать дров гораздо проще.
>Где начало кадрового буфера ? Адрес в студию!
Я бы тебе посоветовал что-нибудь по программированию видео-карточек, но что-то в голову ничего не приходит.
>Покажи как ты туда запишешь из юзер спейс?
Отображаешь туда диапазон шинных адресов (через MapViewOfFile или mmap или что-угодно) и пишешь.
>Учи матчасть про архитектуру x86.
Увы, боюсь ты мне ничего нового о ней рассказать не сможешь :( Как и многие другие...
>> Но они забывают, что C++ это полное надмножнство C ...
>Нет. Не надмножество. Если б он был надмножеством, то любая >верная >программа на C являлась бы верной программой на C++ причем >с той же семантикой. Что, очевидно, не так.
Пожалуйста те места С которые не являются частью С++
в студию
>Ты обкурился и гонишь ! Нукася, забатцай мне такое на плюсатом 8)
>-----------------------------------------------------------------
>#include <stdlib.h>
>struct flex {
> int mem;
> int arrayWoBoundsSpecified[];
>};
>struct NotAflex {
> int a[]
> int mem;
>};
Хорошим тоном было бы перед тем как постить код, попробовать его скомпилить самому. ;)
плюсы у Страуструпа нарисовались ОЧЕНЬ аппетитными
на это многие и запали, я тоже, грешен :)
постоянно испытываю тягу описать эдак все в одном классе, а затем красиво это дело понаследовать.. затем динамически клепать уже готовые обьекты со всеми их функциями, конструкторами и деструкторами..
но реальность - штука суровая, вся эта красота и удобство должны быть правильно описаны и реализованы, это с одной стороны, а с другой по большому счету не так уж и необходимы, да и возможность создания закрытых обьектов в опенсорсе никому не нужна
а вообще говоря в некритичных к эффективности кода приложениях выбор языка - дело вкуса
Насчет MapViewOfFile я утрирую, разумеется. Но всё же в своё время GDI жило в user-space в винде и GDI HEL вроде бы тоже был реализован в user-space. Разумеется, нормальный драйвер должен поддерживать возможности видеокарточки, но это не значит, что в нём сразу иерархия классов появится ;)
C и C++ хоть и являются родственниками исторически разошлись уже давно и являются РАЗНЫМИ языками
о надмножестве и подмоножестве возникает желание говорить разве что после чтения книженок 15 летней давности :)
Еще раз, я не говорю, что ты можешь отобразить кадровый буфер "by hand" через mmap на что-либо, это может сделать драйвер. Смысл в том, что работать с кадровым буфером ты можешь самостоятельно или через библиотеки поддержки.
>ioremap - это ядреный интерфейс. Он из user-space недоступен.
А ты из UM и не сможешь ничего сделать если нужный кусок адресного пространства не проремапить к себе
Робяты!!!
А как Иксы в усер спасе жывуть?!
А ведь живуть. И переключение в усер спасе происходит.
А как вообще ОСь работаеть. Аааа тама есть девайса MMU и дривер оный. Так он вообще каждый чих к памяти отрабатывает (че усер, че не усер) - инструкций по двести за раз. И куды производительность только тратится. На фига нам дривер, который просессор загрязняет?!