VPF::Почему не переписать ядро на C++ ?

En_t_end

Дата 15.7.2008, 18:52 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

http://www.tux.org/lkml/#s15-3 :

Цитата

Why don't we rewrite the Linux kernel in C++?

    * (ADB) Again, this has to do with practical and theoretical reasons. On the practical side, when Linux got started gcc didn't have an efficient C++ implementation, and some people would argue that even today it doesn't. Also there are many more C programmers than C++ programmers around. On theoretical grounds, examples of OS's implemented in Object Oriented languages are rare (Java-OS and Oberon System 3 come to mind), and the advantages of this approach are not quite clear cut (for OS design, that is; for GUI implementation KDE is a good example that C++ beats plain C any day).
    * (REW) In the dark old days, in the time that most of you hadn't even heard of the word "Linux", the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that.
    * (REG) Today (Nov-2000), people claim that compiler technology has improved so that g++ is not longer a worse compiler than gcc, and so feel this issue should be revisited. In fact, there are five issues. These are:
#
    * Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C. What's important about object-oriented programming is the techniques, not the languages used.
    * Should the kernel be rewritten in C++? This is likely to be a very bad idea. It would require a very large amount of work to rewrite the kernel (it's a large piece of code). There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.
      To justify the enormous effort in rewriting the kernel in C++, significant gains would need to be demonstrated. The onus is clearly on whoever wants to push the rewrite to C++ to show such gains.
    * Is it a good idea to write a new driver in C++? The short answer is no, because there isn't any support for C++ drivers in the kernel.
    * Why not add a C++ interface layer to the kernel to support C++ drivers? The short answer is why bother, since there aren't any C++ drivers for Linux. However, if you are bold enough to consider writing a driver in C++ and a support layer, be aware that this is unlikely to be well received in the community. Most of the kernel developers are unconvinced of the merits of C++ in general, and consider C++ to generate bloated code. Also, it would result in a confusing mix of C and C++ code in the kernel. Any C++ code in the kernel would be a second-class citizen, as it would be ignored by most kernel developers when changes to internal interfaces are made. A C++ support layer would be frequently be broken by such changes (as whoever is making the changes would probably not bother fixing the C++ code to match), and thus would require a strong commitment from someone to regularly maintain it.
    * Can we make the kernel headers C++-friendly? This is the first step required for supporting C++ drivers, and on the face seems quite reasonable (it is not a C++ support layer). This has the problem that C++ reserves keywords which are valid variable or field names in C (such as private and new). Thus, C++ is not 100% backwards compatible with C. In effect, the C++ standards bodies would be dictating what variable names we're allowed to have. From past behaviour, the C++ standards people have not shown a commitment to 100% backwards compatibility. The fear is that C++ will continue to expand its claim on the namespace. This would generate an ongoing maintenance burden on the kernel developers.
      Note that someone once submitted a patch which performed this "cleaning up". It was ~250 kB in size, and was quite invasive. The patch did not generate much enthusiasm.
      Apparently, someone has had the temerity to label the above paragraph as "a bit fuddy". So Erik Mouw did a short back-of-the-envelope calculation to show that searching the kernel sources for possible C++ keywords is a nightmare. Here is his calculation and comments (dates April, 2002):

      % find /usr/src/linux-2.4.19-pre3-rmap12h -name "*.[chS]" |\
          xargs cat | wc -l
        4078662

      So there's over 4 million lines of kernel source. Let's assume 10% is
      comments, so there's about 3.6 million lines left. Each of those lines
      has to be checked for C++ keywords. Assume that you can do about 5
      seconds per line (very optimistic), work 24 hours per day, and 7 days
      a week:
                        5 s   1 hour     1 day   1 week
      3600000 lines * ------ * -------- * ---------- * -------- = 29.8 weeks
                       line     3600 s     24 hours     7 days

      Sounds like a nightmare to me. You can automate large parts of this,
      but you'll need to write a *very* intelligent search-and-replace tool
      for that. Better use that time in a more efficient way by learning C.

      Note that this is the time required to do a proper manual audit of the code. You could cheat and forgo the auditing process, and instead just compile with C++ and fix all compiler errors, figuring that the compiler can do most of the work. This would still be a major effort, and has the problem that there may be uses of some C++ keywords which don't generate a compiler error, but do generate unintended code. In other words, introduced bugs. That is not a risk the kernel development community is prepared to take.

My personal view is that C++ has its merits, and makes object-oriented programming easier. However, it is a more complex language and is less mature than C. The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware. The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat. I think it is fair to say that it takes more skill to write efficient C++ code than C code. Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code.
# (REG) Finally, while Linus maintains the development kernel, he is the one who makes the final call. In case there are any doubts on what his opinion is, here is what he said in 2004:

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:

    * the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
    * any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
    * you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

    * (a) looking for problems
    * (b) a C++ bigot that can't see what he is writing is really just C anyway
    * © was given an assignment in CS class to do so.

Feel free to make up (d).

Кто что думает по этому поводу? По мне аргументы типа : "Also there are many more C programmers than C++ programmers around" кажутся смешными, ибо совсем не много из тех людей что знают C могут продуктивно изменять ядро, однако Object-Oriented реализация позволит раздробить ядро на осмысленные части, которые будет проще модифицировать. ИМХО.

Добавлено через 8 минут и 52 секунды
Как решение многих проблем, которыми аргументируют против авторы ответа в FAQе, можно предложить заново написать ядро на C++(возможно альтернативное), тем более новый стандарт уже близко.

Добавлено через 11 минут и 41 секунду
К тому же под C++ есть STL, boost и прочие очень полезные вещи, которые существенно помогут сократить количество строк кода, а приминение стандартных алгоритмов позволит избавиться от многих тривиальных циклов.

smartov

Дата 15.7.2008, 20:06 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

En_t_end, какой смысл?

Добавлено через 12 секунд
К тому же Торвальдс против

Добавлено через 26 секунд
Он не любит плюсы в системной программировании

kemiisto

Дата 15.7.2008, 20:57 (ссылка)

(нет голосов)

Загрузка ...

Дикий Кот. =^.^=

Награды: 1

Профиль
Группа: Участник Клуба
Сообщений: 3292
Регистрация: 29.7.2007

Репутация: 4
Всего: 160

En_t_end, Ответ Торвальдса.

Добавлено @ 21:01
http://oberoncore.ru/download/articles/oberontech.pdf

Цитата(И. Е. Ермаков @ Оберон-технологии: что это такое?)

Как известно, системщики недолюбливают С++, предпочитая чистый С (Танненбаум, Торвальдс и другие разработчики ОС критически выссказывались о возможности применения С++ для написания ядра ОС). Одна из причин этого в том, что для системного программирования с применением ООП характерно наличие групп мелких классов, которым необходимо тесно взаимодействовать между собой без дополнительных накладных расходов. Это требует либо чрезмерно открытых интерфейсов классов, при которых инкапсуляция практически сводится на нет, либо использования для связанных групп классов каких-либо средств обхода инкапсуляции.

Это сообщение отредактировал(а) kemiisto - 15.7.2008, 21:02

--------------------

XMPP-канал.

Unit testing isn't enough. You need static typing.

Пей, кури, пиши на си! smile

JackYF

Дата 15.7.2008, 23:12 (ссылка)

(нет голосов)

Загрузка ...

полуавантюрист

Профиль
Группа: Участник
Сообщений: 5814
Регистрация: 28.8.2004
Где: страна тысячи озё р

Репутация: 8
Всего: 162

Цитата(En_t_end @ 15.7.2008, 17:52

)

К тому же под C++ есть STL, boost и прочие очень полезные вещи, которые существенно помогут сократить количество строк кода, а приминение стандартных алгоритмов позволит избавиться от многих тривиальных циклов.

Ты представляешь себе, сколько кода тебе придётся переписать? Лично я - нет. Кроме того, для ядра важен каждый такт процессора, так что STL и boost идут лесом.

--------------------

Пожаловаться на меня как модератора можно здесь.

En_t_end

Дата 16.7.2008, 10:01 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Цитата(JackYF @ 16.7.2008, 03:12

)

Ты представляешь себе, сколько кода тебе придётся переписать

ИМХО это рано или поздно придется сделать. Помоему любая система такого масштаба как ядро ОС нуждается в полном пересмотре через некоторое время. Ибо ряд проблем уже будет нельзя решить патчами.

Цитата(smartov @ 16.7.2008, 00:06

)

К тому же Торвальдс против

Цитата(smartov @ 16.7.2008, 00:06

)

Он не любит плюсы в системной программировании

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

Мне интересно по тем пунктам что выше, чисто технически решение такой задачи действительно невыполнимо ?

Цитата(smartov @ 16.7.2008, 00:06

)

En_t_end, какой смысл?

Не думаю что C - язык удобный для совместной разработки.

En_t_end

Дата 16.7.2008, 10:18 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Цитата(kemiisto @ 16.7.2008, 00:57

)

En_t_end, Ответ Торвальдса.

После прочтения сложилось впечатление, что Торвальдс просто боится составить ОО-модель.

Цитата

inefficient abstracted programming models where two years down the road
   you notice that some abstraction wasn't very efficient, but now all
   your code depends on all the nice object models around it, and you
   cannot fix it without rewriting your app.

Если я правильно понял, Линус говорит о том что однажды составив модель и написав приложение ты можешь в итоге понять что модель не эффективна и придется переписывать уже все приложение полностью. Это верно, но вероятность такой ошибки близится к нулю если к отнестись к моделированию как к основной задаче. Помоему грамотная модель стоит дороже даже самых гениальных отдельно реализованных методов.

Добавлено @ 10:21
Аргумент:

Цитата

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

фтопку

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

smartov

Дата 16.7.2008, 10:25 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

En_t_end,

Цитата(En_t_end @ 16.7.2008, 10:18

)

фтопку

Почему?

Добавлено через 1 минуту и 18 секунд
OOP не цель, а средство. Смысл в том, чтобы не облегчать работу программистов ядра ради повышения понимания ими того с чем они работают и что именно делают

Добавлено через 2 минуты и 28 секунд
Может путанно написал. Короче говоря OOP расслабляет и позволяет меньше думать о том, что происходит на самом деле, а мыслить абстракциями

En_t_end

Дата 16.7.2008, 11:04 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Хотя пожалуй главный аргумент против - это туча софта который под такое ядро станет не доступным smile

Mayk

Дата 16.7.2008, 11:10 (ссылка)

(нет голосов)

Загрузка ...

^аВаТаР^ сообщение>>

Профиль
Группа: Участник
Сообщений: 2616
Регистрация: 22.5.2005
Где: за границей разум а

Репутация: 1
Всего: 134

Цитата(En_t_end @ 15.7.2008, 22:52

)

ses of some C++ keywords which don't generate a compiler error, but do generate unintended code

А пример гольдберговского keyword'а можно?

--------------------

Здесь был кролик. Но его убили.
Человеки < кроликов, йа считаю.

En_t_end

Дата 16.7.2008, 15:35 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Mayk,

Цитата(Mayk @ 16.7.2008, 15:10

)

А пример гольдберговского keyword'а можно?

что есть "гольдберговский" ?

bilbobagginz

Дата 16.7.2008, 16:02 (ссылка)

(нет голосов)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 14
Всего: 317

Цитата(En_t_end @ 15.7.2008, 18:52

)

C могут продуктивно изменять ядро, однако Object-Oriented реализация позволит раздробить ядро на осмысленные части, которые будет проще модифицировать. ИМХО.

насколько хорошо уважаемый знаком с настоящей реализацией и подсистемами ядра ?
чем не нравится текущее раздробление ?

кстати есть еще одна концептуальная проблема.

когда я пишу на C++:

Код


class A{
int a;
int b;
}
// a потом:
A myarr[10];

в зависимости от платформы я получу совершенно разные картины памяти, чем в C:

Код


typedef struct A_t{
int a;
int b;
} A;

A myarr[10];

т.е. в C++ sizeof(A) будет возвращать зависимые от компилятора величины (т.е. двойная зависимость), тогда как в C - всё будет зависеть только от архитектуры.

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

Цитата(En_t_end @ 16.7.2008, 10:18

)

После прочтения сложилось впечатление, что Торвальдс просто боится составить ОО-модель.

я не могу рассуждать, не зная его лично smile

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

но есть же проекты ОС написанные на C++, или хотя бы с API на C++ -

BeOS
Haiku
если не ошибаюсь NeXT (и Mac OS 10)

--------------------

Я ещё не демон. Я только учусь.

powerfox

Дата 16.7.2008, 16:44 (ссылка)

(нет голосов)

Загрузка ...

I wanna fork()

Профиль
Группа: Комодератор
Сообщений: 3990
Регистрация: 1.10.2005
Где: Санкт-Петербург

Репутация: 20
Всего: 97

Цитата(Linus (Из моей личной переписки))

> > If you piss off all people who *UNDERSTAND* OOP pluses who will play with
> > git and kernel?

I don't *want* crazy OOP people touching the kernel or git.

C++ makes sense in some situations. It sure as hell doesn't make sense in
system programming.

And people who don't understand that, I don't want even close to my system
programming areas. Sorry, but that's how it is.

Linus

Цитата(En_t_end @ 16.7.2008, 11:18

)

And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

фтопку

Линус прав.

Цитата(En_t_end @ 15.7.2008, 19:52

)

однако Object-Oriented реализация позволит раздробить ядро на осмысленные части, которые будет проще модифицировать. ИМХО.

Оно и так разбито на осмысленные части.

--------------------

smartov

Дата 16.7.2008, 16:57 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

Цитата(bilbobagginz @ 16.7.2008, 16:02)

но есть же проекты ОС написанные на C++, или хотя бы с API на C++ -

BeOS
Haiku
если не ошибаюсь NeXT (и Mac OS 10)

Старательно избегаешь оффтопика? smile

Добавлено через 59 секунд
powerfox,

Цитата(powerfox @ 16.7.2008, 16:44

)

Линус прав.

Люблю железные аргументы smile

bilbobagginz

Дата 16.7.2008, 18:13 (ссылка)

(нет голосов)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 14
Всего: 317

Цитата(smartov @ 16.7.2008, 16:57

)

Старательно избегаешь оффтопика? smile

нет.
Висту не видел.
Видел WindowsCE - написано на Си.

--------------------

Я ещё не демон. Я только учусь.

Любитель

Дата 16.7.2008, 18:19 (ссылка)

(нет голосов)

Загрузка ...

Программист-романтик

Профиль
Группа: Комодератор
Сообщений: 3645
Регистрация: 21.5.2005
Где: Воронеж

Репутация: нет
Всего: 92

Цитата(smartov @ 16.7.2008, 16:57

)

Старательно избегаешь оффтопика?

smartov, неужели ТАМ использовался С++?! smile

--------------------

http://oryolalex.mybrute.com

smartov

Дата 16.7.2008, 19:28 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

Цитата(Любитель @ 16.7.2008, 18:19

)

неужели ТАМ использовался С++

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

Любитель

Дата 16.7.2008, 19:30 (ссылка)

(нет голосов)

Загрузка ...

Программист-романтик

Профиль
Группа: Комодератор
Сообщений: 3645
Регистрация: 21.5.2005
Где: Воронеж

Репутация: нет
Всего: 92

Я думаю C

--------------------

http://oryolalex.mybrute.com

smartov

Дата 16.7.2008, 19:52 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

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

powerfox

Дата 16.7.2008, 20:27 (ссылка)

(нет голосов)

Загрузка ...

I wanna fork()

Профиль
Группа: Комодератор
Сообщений: 3990
Регистрация: 1.10.2005
Где: Санкт-Петербург

Репутация: 20
Всего: 97

Цитата(smartov @ 16.7.2008, 17:57

)

Люблю железные аргументы smile

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

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

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

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

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

Цитата(smartov @ 16.7.2008, 20:52

)

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

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

--------------------

En_t_end

Дата 16.7.2008, 22:49 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Цитата(powerfox @ 17.7.2008, 00:27

)

шаблоны через макросы, например

Цитата(powerfox @ 17.7.2008, 00:27

)

Если переписать ядро на С++ оно станет ещё запутаннее.

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

Цитата(powerfox @ 17.7.2008, 00:27

)

Нужно не просто проследить вызовы функций, а

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

Цитата(powerfox @ 17.7.2008, 00:27

)

1) Найти, что это за класс.
2) Найти дефолтный конструктор.
3) Если заинтересовались методом, то нужно понять откуда этот метод взялся (а при множественном наследовании ещё и чей вызывается).
4) Многие методы перегружены. Причём типами, которые вам не знакомы и могут иметь похожие названия.

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

Цитата(powerfox @ 17.7.2008, 00:27

)

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

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

Цитата(powerfox @ 17.7.2008, 00:27

)

В процедурном коде можно разобраться быстрее.

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

Цитата(powerfox @ 17.7.2008, 00:27

)

Объяснение того, что ядро слишком сложно и его всё равно могут читать единицы Си программистов, вообще абсурд.

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

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

Цитата(bilbobagginz @ 16.7.2008, 20:02

)

т.е. в C++ sizeof(A) будет возвращать зависимые от компилятора величины (т.е. двойная зависимость), тогда как в C - всё будет зависеть только от архитектуры.

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

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

En_t_end

Дата 16.7.2008, 23:06 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

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

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

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

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

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

En_t_end

Дата 16.7.2008, 23:22 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Цитата(powerfox @ 17.7.2008, 00:27

)

У меня есть небольшой опыт работы с крупным С++ проектом (Mozilla): c многочисленными шаблонами, классами просто мозг сломаешь, разбираясь в незнакомом коде.

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

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

gcc

Дата 17.7.2008, 07:05 (ссылка)

(нет голосов)

Загрузка ...

Агент алкомафии

Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: 1
Всего: 17

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

Код



#!/usr/bin/perl -w                                      # camel code
use strict;

                                           $_='ev
                                       al("seek\040D
           ATA,0,                  0;");foreach(1..3)
       {<DATA>;}my               @camel1hump;my$camel;
  my$Camel  ;while(             <DATA>){$_=sprintf("%-6
9s",$_);my@dromedary           1=split(//);if(defined($
_=<DATA>)){@camel1hum        p=split(//);}while(@dromeda
 ry1){my$camel1hump=0      ;my$CAMEL=3;if(defined($_=shif
        t(@dromedary1    ))&&/\S/){$camel1hump+=1<<$CAMEL;}
       $CAMEL--;if(d   efined($_=shift(@dromedary1))&&/\S/){
      $camel1hump+=1  <<$CAMEL;}$CAMEL--;if(defined($_=shift(
     @camel1hump))&&/\S/){$camel1hump+=1<<$CAMEL;}$CAMEL--;if(
     defined($_=shift(@camel1hump))&&/\S/){$camel1hump+=1<<$CAME
     L;;}$camel.=(split(//,"\040..m`{/J\047\134}L^7FX"))[$camel1h
      ump];}$camel.="\n";}@camel1hump=split(/\n/,$camel);foreach(@
      camel1hump){chomp;$Camel=$_;y/LJF7\173\175`\047/\061\062\063\
      064\065\066\067\070/;y/12345678/JL7F\175\173\047`/;$_=reverse;
       print"$_\040$Camel\n";}foreach(@camel1hump){chomp;$Camel=$_;y
        /LJF7\173\175`\047/12345678/;y/12345678/JL7F\175\173\0 47`/;
         $_=reverse;print"\040$_$Camel\n";}';;s/\s*//g;;eval;   eval
           ("seek\040DATA,0,0;");undef$/;$_=<DATA>;s/\s*//g;(   );;s
             ;^.*_;;;map{eval"print\"$_\"";}/.{4}/g; __DATA__   \124
               \1   50\145\040\165\163\145\040\157\1 46\040\1  41\0
                    40\143\141  \155\145\1 54\040\1   51\155\  141
                    \147\145\0  40\151\156 \040\141    \163\16 3\
                     157\143\   151\141\16  4\151\1     57\156
                     \040\167  \151\164\1   50\040\      120\1
                     45\162\   154\040\15    1\163\      040\14
                     1\040\1   64\162\1      41\144       \145\
                     155\14    1\162\       153\04        0\157
                      \146\     040\11     7\047\         122\1
                      45\15      1\154\1  54\171          \040
                      \046\         012\101\16            3\16
                      3\15           7\143\15             1\14
                      1\16            4\145\163           \054
                     \040            \111\156\14         3\056
                    \040\         125\163\145\14         4\040\
                    167\1        51\164\1  50\0         40\160\
                  145\162                              \155\151
                \163\163                                \151\1
              57\156\056

--------------------

Perl FAQ
freelance
perl, jquery, js, php
perl, jquery

Lazin

Дата 17.7.2008, 07:43 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 3820
Регистрация: 11.12.2006
Где: paranoid oil empi re

Репутация: 1
Всего: 154

Цитата(En_t_end @ 15.7.2008, 18:52

)

     So there's over 4 million lines of kernel source. Let's assume 10% is
      comments, so there's about 3.6 million lines left. Each of those lines
      has to be checked for C++ keywords. Assume that you can do about 5
      seconds per line (very optimistic), work 24 hours per day, and 7 days
      a week:
                        5 s   1 hour     1 day   1 week
      3600000 lines * ------ * -------- * ---------- * -------- = 29.8 weeks
                       line     3600 s     24 hours     7 days

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

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

--------------------

C++ is the steampunk of programming languages: modern ideas realized with victorian technology.

En_t_end

Дата 17.7.2008, 11:19 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Lazin,

Цитата(Lazin @ 17.7.2008, 11:43

)

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

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

Цитата(Lazin @ 17.7.2008, 11:43

)

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

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

Любитель

Дата 17.7.2008, 12:37 (ссылка)

(нет голосов)

Загрузка ...

Программист-романтик

Профиль
Группа: Комодератор
Сообщений: 3645
Регистрация: 21.5.2005
Где: Воронеж

Репутация: нет
Всего: 92

Цитата(powerfox @ 16.7.2008, 20:27

)

И я могу привести примеры ООП на Си

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

Цитата(En_t_end @ 17.7.2008, 11:19

)

Я не буду настаивать больше ни на чем, я согласен что это тупая затея, технически не реализуемая.

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

Цитата(En_t_end @ 17.7.2008, 11:19

)

Но с тем что C удобен для крупных проектов я не соглашусь никогда.

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

--------------------

http://oryolalex.mybrute.com

En_t_end

Дата 17.7.2008, 12:50 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

Цитата(Любитель @ 17.7.2008, 16:37

)

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

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

smartov

Дата 17.7.2008, 12:50 (ссылка)

(нет голосов)

Загрузка ...

свой собственный

Профиль
Группа: Экс. модератор
Сообщений: 4225
Регистрация: 2.2.2006
Где: NJ

Репутация: 3
Всего: 259

[offtopic]

Цитата(Lazin @ 17.7.2008, 07:43

)

я где-то читал статью, в которой говорилось, что там 60 000 000 строк кода...

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

En_t_end

Дата 17.7.2008, 13:03 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 2074
Регистрация: 4.12.2004

Репутация: нет
Всего: 20

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

nickless

Дата 18.7.2008, 22:24 (ссылка)

(нет голосов)

Загрузка ...

Гентозавр

Профиль
Группа: Участник Клуба
Сообщений: 2976
Регистрация: 29.8.2005
Где: Germany

Репутация: 7
Всего: 181

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

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

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

--------------------

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies
- Linus Torvalds

MAKCim

Дата 17.8.2008, 12:29 (ссылка)

(нет голосов)

Загрузка ...

Воін дZэна

Профиль
Группа: Экс. модератор
Сообщений: 5644
Регистрация: 10.12.2005
Где: Менск, РБ

Репутация: 4
Всего: 207

тут говорили про ОО-модель
а разве сейчас ее нет?
структуры - объекты, функции - методы, полиморфизм - void*
возьмите любую подсистему ядра
*.h файлы определяют интерфейсы, *.c файлы - работу с интерфейсами
все логично и вполне ОО
ОО - это в первую очередь логика построения, а не ЯП

--------------------

powerfox

Дата 17.8.2008, 22:57 (ссылка)

(нет голосов)

Загрузка ...

I wanna fork()

Профиль
Группа: Комодератор
Сообщений: 3990
Регистрация: 1.10.2005
Где: Санкт-Петербург

Репутация: 20
Всего: 97

Цитата(MAKCim @ 17.8.2008, 13:29

)

тут говорили про ОО-модель
а разве сейчас ее нет?

Ещё тут говорили, что она есть smile

--------------------

MAKCim

Дата 18.8.2008, 08:25 (ссылка)

(нет голосов)

Загрузка ...

Воін дZэна

Профиль
Группа: Экс. модератор
Сообщений: 5644
Регистрация: 10.12.2005
Где: Менск, РБ

Репутация: 4
Всего: 207

powerfox,
угу
что-то я твой пост пропустил smile

--------------------

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Клуб юнуксоидов \| Следующая тема »