forum.opennet.ru - "Использование С++ в ядре линукса" (27)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Использование С++ в ядре линукса"

Форумы Программирование под UNIX (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Использование С++ в ядре линукса"		+/–
Сообщение от worman (ok) on 22-Апр-09, 10:17
Здравствуйте! Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не на С. Возникла проблема линковки - линковщик не понимает объектные файлы созданные g++. В частности имены функций в объектных файлах скомпилированных gcc и g++ создаються по-разному. gcc: _funcname g++: __Z7funcnamev Если в .cpp файле функцию заключить в extern "C" { void funcname() {} }, то имена ф-ии в объектниках g++ делает как и gcc, однако по прежнему : undefined reference to `funcname'. Вопросы: 1) как сделать чтобы код С++ нормально собирался с ядром линукса? 2) какие подводные камни возможны при использовании С++ в ядре линкса?
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Использование С++ в ядре линукса, Аноним, 11:23 , 22-Апр-09, (1)

Использование С++ в ядре линукса, const86, 13:22 , 22-Апр-09, (2)

Использование С++ в ядре линукса, worman, 13:40 , 22-Апр-09, (3)

Использование С++ в ядре линукса, Аноним, 14:25 , 22-Апр-09, (4)
Использование С++ в ядре линукса, ALu, 16:35 , 22-Апр-09, (5)

Использование С++ в ядре линукса, poulch, 21:41 , 22-Апр-09, (7)

Использование С++ в ядре линукса, svn, 01:56 , 23-Апр-09, (8)

Использование С++ в ядре линукса, poulch, 07:44 , 23-Апр-09, (9)

Использование С++ в ядре линукса, poulch, 08:09 , 23-Апр-09, (11)

Использование С++ в ядре линукса, worman, 07:57 , 23-Апр-09, (10)

Использование С++ в ядре линукса, svn, 21:12 , 23-Апр-09, (13)

Использование С++ в ядре линукса, f00l, 09:33 , 23-Апр-09, (12)

2ALL, DimaG, 11:22 , 05-Май-09, (16)

2ALL, svn, 14:39 , 05-Май-09, (17)

2ALL, DimaG, 17:08 , 05-Май-09, (19)

2ALL, svn, 21:58 , 05-Май-09, (22)

2ALL, DimaG, 06:58 , 06-Май-09, (23)

2ALL, DimaG, 07:02 , 06-Май-09, (24)

2ALL, DimaG, 08:15 , 06-Май-09, (25)

2ALL, svn, 13:42 , 06-Май-09, (26)

2ALL, svn, 14:04 , 07-Май-09, (27)

2ONE, Andrey Mitrofanov, 14:51 , 05-Май-09, (18)

2ONE, DimaG, 17:11 , 05-Май-09, (20)

2ONE, poulch, 14:38 , 12-Май-09, (28)

2ONE, worman, 06:34 , 13-Май-09, (29)

2ONE, poulch, 11:11 , 13-Май-09, (30)

Использование С++ в ядре линукса, Alexander S. Salieff, 00:59 , 03-Июн-09, (31)

Сообщения по теме [Сортировка по времени | RSS]

1. "Использование С++ в ядре линукса" +/–

Сообщение от Аноним (??) on 22-Апр-09, 11:23

Для gcc для зборки с++ надо подключать -lstdc++ .

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Использование С++ в ядре линукса" +/–

Сообщение от const86 (ok) on 22-Апр-09, 13:22

>Для gcc для зборки с++ надо подключать -lstdc++ .
А вот и не надо. Так же как нельзя подключать libc для сишного кода в ядре. Вот только какой C++ получится без libstdc++... Сомневаюсь, что выйдет что-то разумное.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Использование С++ в ядре линукса" +/–

Сообщение от worman (ok) on 22-Апр-09, 13:40

Пока решил не пользовать С++ в ядре, однако разобраться все же интересно.
http://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-.../
Вкраце:
<< Мы все знаем что использовать С++ для написания модулей ядра - плохая идея...
но если всеже надо, то:
1) Most features of C++ will work, virtual functions, templates, operators, etc. But their is no default implementation of new and delete operators, so you need to write your own.

2) Stack space is very limited. In Linux kernel, default size of stack is 2 pages... Due to this constrain, you can’t use exceptions in kernel, because exception needs too much space in stack. >>
----
Почему хочу писать на С++:
1) с помощью классов и функций-членов легче структурировать и логически разделить на часть программу.
2) нужны stl-контейнеры (вектор, очередь).
использование остальных свойств языка (шаблоны, исключения, и т.д) пока не предвидиться.
Хочеться оргументированный ответ чем плох С++ для ядра линукса.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Использование С++ в ядре линукса" +/–

Сообщение от Аноним (??) on 22-Апр-09, 14:25

Философский вопрос про яйца :), что первично ядро или glibc.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Использование С++ в ядре линукса" +/–

Сообщение от ALu (ok) on 22-Апр-09, 16:35

>Хочеться оргументированный ответ чем плох С++ для ядра линукса.
Linux creator Linus Torvalds joined in to explain:
    "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
    "The fact is, C++ compilers are not trustworthy. They were even worse in
    1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Использование С++ в ядре линукса" +/–

Сообщение от poulch (??) on 22-Апр-09, 21:41

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Использование С++ в ядре линукса" +/–

Сообщение от svn (??) on 23-Апр-09, 01:56

>и были патчи для поддержки С++, но это не прижилось... упертая
>ретроградгость девелоперов ядра...
c++ в ядре на самом деле не нужен. Мне жаль тех кто этого не понимает. Подумайте почему ядро не может быть написано на интерпретируемом языке. С++ практически тоже самое.
stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Использование С++ в ядре линукса" +/–

Сообщение от poulch (??) on 23-Апр-09, 07:44

мне там не нужен stl. мне там нужны просто классы. даже эксепшен хандлинг не нужен... мне просто надо получить стабильный код драйвера через framework, учитывая постоянные мутации ядра. Кроме этого я кросс девелопер драйверов. Хочу общий код драйвера для windows и linux. Сейчас это получается только на уровне библиотек, хотя логически код дров и получается общий...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Использование С++ в ядре линукса" +/–

Сообщение от poulch (??) on 23-Апр-09, 08:09

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Использование С++ в ядре линукса" +/–

Сообщение от worman (ok) on 23-Апр-09, 07:57

>Linux creator Linus Torvalds...
Мнение Торвальдса мне известно, хотельсь мнение вменяемых людей узнать.
>В дравере!? STL контейнеры!? ... в стране нехватка дворников - меняй профессию!
Если не знаю чего-либо - буду разбираться. Менять профессию - не мой путь.
>Ты сам приводил:  << Мы все знаем чт...
Ага, сам. Понравилось?
>нифига не выйдет... ключевые слова С++ использованы как переменные и тп в коде ядра в контексте С.
Спосибо, не подумал об этом.
>Подумайте почему ядро не может быть написано на интерпретируемом языке.
Ну ты сравнил С++ с интерпретируемым языком. С++ практически не уступает С.
>stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять?
Нет не в обработчике прерываний. Минус STL вижу в том что возможны в процессе работы динамическое выделение памяти. Это надо учитывать при написании кода. Бороться с этим можно.
-----
В общем С++ как вариант для драйвера больше не рассматриваю.
Ни одного мнения за плюсы нет.
Всем большое спасибо!!!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Использование С++ в ядре линукса" +/–

Сообщение от svn (??) on 23-Апр-09, 21:12

>С++ практически не уступает С.
И java не уступает C ))
Но и java и php и c++ не могут жить без рантайм библиотек. А рантайм библиотеке с++ в ядре совсем не рады.
Реализация шаблонов вызывает рост экспортируемых имён.
А зачем нужны классы если не нужны исключения или виртуальные функции? Ты видел как пишеться объектный код на C в ядре linux?
>В общем С++ как вариант для драйвера больше не рассматриваю.
+1

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Использование С++ в ядре линукса" +/–

Сообщение от f00l (ok) on 23-Апр-09, 09:33

>Здравствуйте!
>
>Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не
>на С.
Основное препятствие использования С++ в ядре (в частности в драйвере). То что ядро оперирует такими понятиями как данные (биты и байты) и действия над ними , С++ оперирует понятиями объекты и взаимодействие объектов. Совместить ни как не получится.
То есть в лучшем случаи создашь С код и откомпилируешь его С++ компилятором.
Да и потом С++ компилятор утяжеляет исполняемый код, а для ядра скорость выполнения и размер кода имеет первоочередное значение. В силу того что делаешь драйвер для uclinux.
А данный дистрибутив в основном применяют на микроконтроллерах.
P.S. Сам ставил ucLinux на микроконтроллеры и драйвера писал, желание сделать их на С++ не возникало.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "2ALL" +/–

Сообщение от DimaG on 05-Май-09, 11:22

Народ, прежде чем наезжать на плюсы, хочется спросить - а вы с ним работали? Насколько сложные проекты? По большинству ответов видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которого через плечо заглядывал начинающему программисту на С++".
В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS. Написана на плюсах (ес-но, есть места на ассмемблере - без этого никак). Причем, эта операционка показывает одни из лучших параметров (размер кода, ресурсы, реакция на события) в своем классе.
Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си?
Теперь по делу: писать драйвера на плюсах - плохая идея, но это не из-за того, что язык плохой, а из-за того, что сама система Linux под это не заточена (причем такое ощущение - сделано все, чтобы плюсы в кернеле не использовали).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "2ALL" +/–

Сообщение от svn (??) on 05-Май-09, 14:39

>В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS.
>Написана на плюсах (ес-но, есть места на ассмемблере - без этого
>никак). Причем, эта операционка показывает одни из лучших параметров (размер кода,
>ресурсы, реакция на события) в своем классе.
И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений?
>Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си?
Что такое «ембеддед плюсы»?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "2ALL" +/–

Сообщение от DimaG on 05-Май-09, 17:08

>И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений?
>
Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме RTTI.

>Что такое «ембеддед плюсы»?
Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно, чем хуже _разумно_ писать на Си++, чем на Си?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "2ALL" +/–

Сообщение от svn (??) on 05-Май-09, 21:58

>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме
>RTTI.
Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных в другую, прекрасно пишется и на C.
Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в ядро не тривиальная, а уж если использовать шаблоны то будет вообще кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще авгиевых конюшен.
>Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно,
>чем хуже _разумно_ писать на Си++, чем на Си?
Ты читал что написано выше?
Если разумно писать на C++ по твоему, это означает не пользоваться его основными возможностями, то я считаю, лучше в таком случае чистый C.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "2ALL" +/–

Сообщение от DimaG on 06-Май-09, 06:58

>>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме
>>RTTI.
>
>Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных
>в другую, прекрасно пишется и на C.
Виртуальные методы не используются в данном проекте (scmRTOS), но активно используются в других. Кстати, а чем они вас так напрягают? В ядре линукса они тоже (в сишном виде) используются.
>Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в
>ядро не тривиальная, а уж если использовать шаблоны то будет вообще
>кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще
>авгиевых конюшен.
Шаблоны раздувают код?  Имеете в виду, что будет множество инстанцированний? Опять же - зависит от кривизны рук программиста. Кстати, а дефайны не раздувают? )))))
И в чем сложность линковки? (хотя бы - лично для вас?)
Про загаживаение пространства имен - не смешите - в сишных проектах оно загажено еще сильнее глобальными переменными. С++ как раз и задумывался как язык инкапсулирующий данные и методы их обработки

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "2ALL" +/–

Сообщение от DimaG on 06-Май-09, 07:02

В качестве примера удобства использования - напишите мне аналог на Си
class CCriticalSect
{
  inline CCriticalSect(){int_disable();}
  inline ~CCriticalSect(){int_enable();}
};

* * *
void func(int a)
{
  CCriticalSect clCS_;
  switch (a)
  {
    case (A0):
    {
      * * *
      return;
    }
    case (A1):
    {
      * * *
      return;
    }
    case (A2):
    {
      * * *
      return;
    }
    case (A3):
    {
      * * *
      return;
    }

    case (A4):
    {
      * * *
      return;
    }
  }

}

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "2ALL" +/–

Сообщение от DimaG on 06-Май-09, 08:15

Ес-но код выше прошу не обсуждать - это тупой пример функции в несколькими точками выхода. Тут главное суть - удобство факта существования конструктора / деструктора.
Или создание объекта до main()
class ClassMainWarpper
{
  ClassMainWarpper()
  {
    printf("Before main\n");
  }
  ~ClassMainWarpper()
  {
    printf("After main\n");
  }
};
ClassMainWarpper clMW;

void main()
{
  printf("main\n");
}

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "2ALL" +/–

Сообщение от svn (??) on 06-Май-09, 13:42

>Тут главное суть - удобство факта существования конструктора
>/ деструктора.
Если и удобно оно, то только для автоматических переменных. А учитывая, что автоматических переменных в ядре нет (экономить стек надо, в стеке только указатели на структуры), никакого удобства не получается. Явный new + delete ничем не лучше функций init + fini.

>Или создание объекта до main()
В ядре нет main. И порядок создание объектов в ядре linux очень чёткий, понятный и контролируемый.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "2ALL" +/–

Сообщение от svn (??) on 07-Май-09, 14:04

>Шаблоны раздувают код?  Имеете в виду, что будет множество инстанцированний? Опять
>же - зависит от кривизны рук программиста. Кстати, а дефайны не
>раздувают? )))))
Макросы раздувают, но они не вносят проблемы линковки. В последнее время всё чаще используются inline функции.
>И в чем сложность линковки? (хотя бы - лично для вас?)
В том что линковщик должен определить что это шаблон, и не нервничать встретив дубликата при линковке, а просто его потерять. Это сложность, не приемлемая во время линковки (загрузки) загружаемого модуля ядра.
>Про загаживаение пространства имен - не смешите - в сишных проектах оно
>загажено еще сильнее глобальными переменными. С++ как раз и задумывался как
>язык инкапсулирующий данные и методы их обработки
Слышал звон. Писать плохо можно и на С. Посмотри сколько глобальных переменных и функций в linux. Почти всё скрыто статиками. С шаблонами такие выкрутасы не прокатят. И классы с методами и namespace всплывут в глобальной области имён, дикими префиксами.
В ядре однозначно лучше убрать статиком, чем прятать за префиксом.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "2ONE" +/–

Сообщение от Andrey Mitrofanov on 05-Май-09, 14:51

>видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которого
А ниже - Ваш аргумент в русле "слышал от человека про реальную ос на плюсах -- сказыал всех делает по параметру чего-то там в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную перебранку, Спасибо!
>В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS.
>Написана на плюсах (ес-но, есть места на ассмемблере - без этого
>никак). Причем, эта операционка показывает одни из лучших параметров (размер кода,
>ресурсы, реакция на события) в своем классе.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "2ONE" +/–

Сообщение от DimaG on 05-Май-09, 17:11

>А ниже - Ваш аргумент в русле "слышал от человека про реальную
>ос на плюсах -- сказыал всех делает по параметру чего-то там
>в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную >перебранку,
Почему же? Не только слышал, но и использовал в своих работах. За что огромное спасибо автору. Кстати, ее многие железячники  на электрониксе пользуют..

>Спасибо!
Пожалуйста :)
Я донести пытаюсь - что и на плюсах можно писать быстрые, качественные приложения, ничем не уступающие коду на си. А то, что эта возможность зарублена в линуксе - это его минус

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "2ONE" +/–

Сообщение от poulch (??) on 12-Май-09, 14:38

Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже пока у энтузиастов хватает сил ползать по всему коду драйвероа  и патчить его под новые API...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "2ONE" +/–

Сообщение от worman (ok) on 13-Май-09, 06:34

>Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра
>посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже
>пока у энтузиастов хватает сил ползать по всему коду драйвероа
>и патчить его под новые API...
Не понял что ты имеешь ввиду. Какие фреймворки???
Исходная задача такая была:  есть микросхема для работы с потоками E1, есть  ucLinux, надо реализовать протокол канального уровня. Протокол канального уровня и реализуеться в виде драйвера. Таким образом драйвер пишеться с нуля и привязан к микросхеме.
Был вопрос в выборе языка C или С++. Я преверженец С++ вот и интересовался как обстоит дело с С++ в ядре.
Пэ.Эс. Если у тебя есть пара фреймфорков реализующих телекоммуникационные протоколы, дай плиз :-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "2ONE" +/–

Сообщение от poulch (??) on 13-Май-09, 11:11

это было общее рассуждение... я тоже C++ больше люблю. и очень не люблю править драйвера с выходом новых ядер тк функции ядра меняются. Предпочел бы что-то типа numega driver studio иметь в linux. C телекоммуникациями никак не связан... www.lcard.ru мой профиль....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

31. "Использование С++ в ядре линукса" +/–

Сообщение от Alexander S. Salieff on 03-Июн-09, 00:59

Какой вы страшный флейм устроили. При написании LKM главное что, чтобы весь экспорт ядро распознало, и чтобы весь импорт ядро предоставило. А пиши хоть на испанском, лишь бы вменяемый компилятор был. С экспортом просто, с импортом сложнее, но совсем не в плане STL, exceptions и RTTI, а в плане того, что они потащат за собой целую libstdc++ и libgcc, которые, в свою очередь, зависимы от glibc, и там начинается гемор. Но при желании это можно порешать... Только дрова жирные получатся, C транслируется в asm практически линейно, а C++ требует обширной библиотечной поддержки...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Использование С++ в ядре линукса"		+/–
Сообщение от Аноним (??) on 22-Апр-09, 11:23
Для gcc для зборки с++ надо подключать -lstdc++ .
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Использование С++ в ядре линукса"		+/–
	Сообщение от const86 (ok) on 22-Апр-09, 13:22
	>Для gcc для зборки с++ надо подключать -lstdc++ . А вот и не надо. Так же как нельзя подключать libc для сишного кода в ядре. Вот только какой C++ получится без libstdc++... Сомневаюсь, что выйдет что-то разумное.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Использование С++ в ядре линукса"		+/–
	Сообщение от worman (ok) on 22-Апр-09, 13:40
	Пока решил не пользовать С++ в ядре, однако разобраться все же интересно. http://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-.../ Вкраце: << Мы все знаем что использовать С++ для написания модулей ядра - плохая идея... но если всеже надо, то: 1) Most features of C++ will work, virtual functions, templates, operators, etc. But their is no default implementation of new and delete operators, so you need to write your own. 2) Stack space is very limited. In Linux kernel, default size of stack is 2 pages... Due to this constrain, you can’t use exceptions in kernel, because exception needs too much space in stack. >> ---- Почему хочу писать на С++: 1) с помощью классов и функций-членов легче структурировать и логически разделить на часть программу. 2) нужны stl-контейнеры (вектор, очередь). использование остальных свойств языка (шаблоны, исключения, и т.д) пока не предвидиться. Хочеться оргументированный ответ чем плох С++ для ядра линукса.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Использование С++ в ядре линукса"		+/–
	Сообщение от Аноним (??) on 22-Апр-09, 14:25
	Философский вопрос про яйца :), что первично ядро или glibc.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Использование С++ в ядре линукса"		+/–
	Сообщение от ALu (ok) on 22-Апр-09, 16:35
	>Хочеться оргументированный ответ чем плох С++ для ядра линукса. Linux creator Linus Torvalds joined in to explain: "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. "The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

7. "Использование С++ в ядре линукса"		+/–
Сообщение от poulch (??) on 22-Апр-09, 21:41
нифига не выйдет... ключевые слова С++ использованы как переменные и тп в коде ядра в контексте С. Была попытка зачистить ядро от этого и были патчи для поддержки С++, но это не прижилось... упертая ретроградгость девелоперов ядра... я покрутил эти патчи , но на последние ядра это все прикручивать и создавать свой дистрибутив ради С++ в своих драйверах это перебор...
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Использование С++ в ядре линукса"		+/–
	Сообщение от svn (??) on 23-Апр-09, 01:56
	>и были патчи для поддержки С++, но это не прижилось... упертая >ретроградгость девелоперов ядра... c++ в ядре на самом деле не нужен. Мне жаль тех кто этого не понимает. Подумайте почему ядро не может быть написано на интерпретируемом языке. С++ практически тоже самое. stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Использование С++ в ядре линукса"		+/–
	Сообщение от poulch (??) on 23-Апр-09, 07:44
	мне там не нужен stl. мне там нужны просто классы. даже эксепшен хандлинг не нужен... мне просто надо получить стабильный код драйвера через framework, учитывая постоянные мутации ядра. Кроме этого я кросс девелопер драйверов. Хочу общий код драйвера для windows и linux. Сейчас это получается только на уровне библиотек, хотя логически код дров и получается общий...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Использование С++ в ядре линукса"		+/–
	Сообщение от poulch (??) on 23-Апр-09, 08:09
	причем я не настаиваю на использовании С++ в ядре. Я хочу чтобы просто убрали искусственное ограничение на использование С++,а дальше уж как пойдет...народ сам решит.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Использование С++ в ядре линукса"		+/–
	Сообщение от worman (ok) on 23-Апр-09, 07:57
	>Linux creator Linus Torvalds... Мнение Торвальдса мне известно, хотельсь мнение вменяемых людей узнать. >В дравере!? STL контейнеры!? ... в стране нехватка дворников - меняй профессию! Если не знаю чего-либо - буду разбираться. Менять профессию - не мой путь. >Ты сам приводил: << Мы все знаем чт... Ага, сам. Понравилось? >нифига не выйдет... ключевые слова С++ использованы как переменные и тп в коде ядра в контексте С. Спосибо, не подумал об этом. >Подумайте почему ядро не может быть написано на интерпретируемом языке. Ну ты сравнил С++ с интерпретируемым языком. С++ практически не уступает С. >stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять? Нет не в обработчике прерываний. Минус STL вижу в том что возможны в процессе работы динамическое выделение памяти. Это надо учитывать при написании кода. Бороться с этим можно. ----- В общем С++ как вариант для драйвера больше не рассматриваю. Ни одного мнения за плюсы нет. Всем большое спасибо!!!
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Использование С++ в ядре линукса"		+/–
	Сообщение от svn (??) on 23-Апр-09, 21:12
	>С++ практически не уступает С. И java не уступает C )) Но и java и php и c++ не могут жить без рантайм библиотек. А рантайм библиотеке с++ в ядре совсем не рады. Реализация шаблонов вызывает рост экспортируемых имён. А зачем нужны классы если не нужны исключения или виртуальные функции? Ты видел как пишеться объектный код на C в ядре linux? >В общем С++ как вариант для драйвера больше не рассматриваю. +1
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

12. "Использование С++ в ядре линукса"		+/–
Сообщение от f00l (ok) on 23-Апр-09, 09:33
>Здравствуйте! > >Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не >на С. Основное препятствие использования С++ в ядре (в частности в драйвере). То что ядро оперирует такими понятиями как данные (биты и байты) и действия над ними , С++ оперирует понятиями объекты и взаимодействие объектов. Совместить ни как не получится. То есть в лучшем случаи создашь С код и откомпилируешь его С++ компилятором. Да и потом С++ компилятор утяжеляет исполняемый код, а для ядра скорость выполнения и размер кода имеет первоочередное значение. В силу того что делаешь драйвер для uclinux. А данный дистрибутив в основном применяют на микроконтроллерах. P.S. Сам ставил ucLinux на микроконтроллеры и драйвера писал, желание сделать их на С++ не возникало.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "2ALL"		+/–
	Сообщение от DimaG on 05-Май-09, 11:22
	Народ, прежде чем наезжать на плюсы, хочется спросить - а вы с ним работали? Насколько сложные проекты? По большинству ответов видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которого через плечо заглядывал начинающему программисту на С++". В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS. Написана на плюсах (ес-но, есть места на ассмемблере - без этого никак). Причем, эта операционка показывает одни из лучших параметров (размер кода, ресурсы, реакция на события) в своем классе. Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си? Теперь по делу: писать драйвера на плюсах - плохая идея, но это не из-за того, что язык плохой, а из-за того, что сама система Linux под это не заточена (причем такое ощущение - сделано все, чтобы плюсы в кернеле не использовали).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "2ALL"		+/–
	Сообщение от svn (??) on 05-Май-09, 14:39
	>В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS. >Написана на плюсах (ес-но, есть места на ассмемблере - без этого >никак). Причем, эта операционка показывает одни из лучших параметров (размер кода, >ресурсы, реакция на события) в своем классе. И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений? >Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си? Что такое «ембеддед плюсы»?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "2ALL"		+/–
	Сообщение от DimaG on 05-Май-09, 17:08
	>И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений? > Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме RTTI. >Что такое «ембеддед плюсы»? Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно, чем хуже _разумно_ писать на Си++, чем на Си?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "2ALL"		+/–
	Сообщение от svn (??) on 05-Май-09, 21:58
	>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме >RTTI. Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных в другую, прекрасно пишется и на C. Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в ядро не тривиальная, а уж если использовать шаблоны то будет вообще кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще авгиевых конюшен. >Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно, >чем хуже _разумно_ писать на Си++, чем на Си? Ты читал что написано выше? Если разумно писать на C++ по твоему, это означает не пользоваться его основными возможностями, то я считаю, лучше в таком случае чистый C.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "2ALL"		+/–
	Сообщение от DimaG on 06-Май-09, 06:58
	>>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме >>RTTI. > >Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных >в другую, прекрасно пишется и на C. Виртуальные методы не используются в данном проекте (scmRTOS), но активно используются в других. Кстати, а чем они вас так напрягают? В ядре линукса они тоже (в сишном виде) используются. >Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в >ядро не тривиальная, а уж если использовать шаблоны то будет вообще >кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще >авгиевых конюшен. Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять же - зависит от кривизны рук программиста. Кстати, а дефайны не раздувают? ))))) И в чем сложность линковки? (хотя бы - лично для вас?) Про загаживаение пространства имен - не смешите - в сишных проектах оно загажено еще сильнее глобальными переменными. С++ как раз и задумывался как язык инкапсулирующий данные и методы их обработки
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "2ALL"		+/–
	Сообщение от DimaG on 06-Май-09, 07:02
	В качестве примера удобства использования - напишите мне аналог на Си class CCriticalSect { inline CCriticalSect(){int_disable();} inline ~CCriticalSect(){int_enable();} }; * * * void func(int a) { CCriticalSect clCS_; switch (a) { case (A0): { * * * return; } case (A1): { * * * return; } case (A2): { * * * return; } case (A3): { * * * return; } case (A4): { * * * return; } } }
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "2ALL"		+/–
	Сообщение от DimaG on 06-Май-09, 08:15
	Ес-но код выше прошу не обсуждать - это тупой пример функции в несколькими точками выхода. Тут главное суть - удобство факта существования конструктора / деструктора. Или создание объекта до main() class ClassMainWarpper { ClassMainWarpper() { printf("Before main\n"); } ~ClassMainWarpper() { printf("After main\n"); } }; ClassMainWarpper clMW; void main() { printf("main\n"); }
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "2ALL"		+/–
	Сообщение от svn (??) on 06-Май-09, 13:42
	>Тут главное суть - удобство факта существования конструктора >/ деструктора. Если и удобно оно, то только для автоматических переменных. А учитывая, что автоматических переменных в ядре нет (экономить стек надо, в стеке только указатели на структуры), никакого удобства не получается. Явный new + delete ничем не лучше функций init + fini. >Или создание объекта до main() В ядре нет main. И порядок создание объектов в ядре linux очень чёткий, понятный и контролируемый.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "2ALL"		+/–
	Сообщение от svn (??) on 07-Май-09, 14:04
	>Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять >же - зависит от кривизны рук программиста. Кстати, а дефайны не >раздувают? ))))) Макросы раздувают, но они не вносят проблемы линковки. В последнее время всё чаще используются inline функции. >И в чем сложность линковки? (хотя бы - лично для вас?) В том что линковщик должен определить что это шаблон, и не нервничать встретив дубликата при линковке, а просто его потерять. Это сложность, не приемлемая во время линковки (загрузки) загружаемого модуля ядра. >Про загаживаение пространства имен - не смешите - в сишных проектах оно >загажено еще сильнее глобальными переменными. С++ как раз и задумывался как >язык инкапсулирующий данные и методы их обработки Слышал звон. Писать плохо можно и на С. Посмотри сколько глобальных переменных и функций в linux. Почти всё скрыто статиками. С шаблонами такие выкрутасы не прокатят. И классы с методами и namespace всплывут в глобальной области имён, дикими префиксами. В ядре однозначно лучше убрать статиком, чем прятать за префиксом.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "2ONE"		+/–
	Сообщение от Andrey Mitrofanov on 05-Май-09, 14:51
	>видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которого А ниже - Ваш аргумент в русле "слышал от человека про реальную ос на плюсах -- сказыал всех делает по параметру чего-то там в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную перебранку, Спасибо! >В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS. >Написана на плюсах (ес-но, есть места на ассмемблере - без этого >никак). Причем, эта операционка показывает одни из лучших параметров (размер кода, >ресурсы, реакция на события) в своем классе.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "2ONE"		+/–
	Сообщение от DimaG on 05-Май-09, 17:11
	>А ниже - Ваш аргумент в русле "слышал от человека про реальную >ос на плюсах -- сказыал всех делает по параметру чего-то там >в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную >перебранку, Почему же? Не только слышал, но и использовал в своих работах. За что огромное спасибо автору. Кстати, ее многие железячники на электрониксе пользуют.. >Спасибо! Пожалуйста :) Я донести пытаюсь - что и на плюсах можно писать быстрые, качественные приложения, ничем не уступающие коду на си. А то, что эта возможность зарублена в линуксе - это его минус
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "2ONE"		+/–
	Сообщение от poulch (??) on 12-Май-09, 14:38
	Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже пока у энтузиастов хватает сил ползать по всему коду драйвероа и патчить его под новые API...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "2ONE"		+/–
	Сообщение от worman (ok) on 13-Май-09, 06:34
	>Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра >посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже >пока у энтузиастов хватает сил ползать по всему коду драйвероа >и патчить его под новые API... Не понял что ты имеешь ввиду. Какие фреймворки??? Исходная задача такая была: есть микросхема для работы с потоками E1, есть ucLinux, надо реализовать протокол канального уровня. Протокол канального уровня и реализуеться в виде драйвера. Таким образом драйвер пишеться с нуля и привязан к микросхеме. Был вопрос в выборе языка C или С++. Я преверженец С++ вот и интересовался как обстоит дело с С++ в ядре. Пэ.Эс. Если у тебя есть пара фреймфорков реализующих телекоммуникационные протоколы, дай плиз :-)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "2ONE"		+/–
	Сообщение от poulch (??) on 13-Май-09, 11:11
	это было общее рассуждение... я тоже C++ больше люблю. и очень не люблю править драйвера с выходом новых ядер тк функции ядра меняются. Предпочел бы что-то типа numega driver studio иметь в linux. C телекоммуникациями никак не связан... www.lcard.ru мой профиль....
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

31. "Использование С++ в ядре линукса"		+/–
Сообщение от Alexander S. Salieff on 03-Июн-09, 00:59
Какой вы страшный флейм устроили. При написании LKM главное что, чтобы весь экспорт ядро распознало, и чтобы весь импорт ядро предоставило. А пиши хоть на испанском, лишь бы вменяемый компилятор был. С экспортом просто, с импортом сложнее, но совсем не в плане STL, exceptions и RTTI, а в плане того, что они потащат за собой целую libstdc++ и libgcc, которые, в свою очередь, зависимы от glibc, и там начинается гемор. Но при желании это можно порешать... Только дрова жирные получатся, C транслируется в asm практически линейно, а C++ требует обширной библиотечной поддержки...
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]