Вопрос к программистам на C , Исходники ядра Linux

Цитата

ну почему же, вот эти чтуки, приведённые здесь как раз на шаблончиках можно вполне переписать, и тоже всё будет compile-time :).

Нет. Суть в том, что С использует парадигмы "конечных автоматов" и "функциональной декомпозиции". В С++ для их использования требуется приложить усилия. Дело в том, что нормальный и адекватный С-программист может сказать в какой момент времени что делает его программа. Т.е., есть набор функций, в идеале каждая из которых решает только одну задачу. Весь функционал (в данном случае ядра) собирается из вот таких вот атомарных функций.

Это, по сути дела, и есть идеологическое различие С и С++. В С++ программист более озабочен "инкапсуляцией" и "наследованием", в С -- "функциональной непротиворечивостью" (сюда входят и грамотные реализации структур данных и алгоритмы, их обрабатывающие. Известно, что до 40% времени тратится на грамотную реализацию работы с памятью).

С другой стороны. Ядро начинает функционировать до загрузки каких-либо библиотек (в т.ч. и С++'овских). Следовательно, маханизмы исключений, шаблонов и т.д. и т.п. становятся доступными (см. ldconfig) позже начала работы ядра. По этой причине, в документации на ядро сказано, что "Вы можете использовать С++, но забудьте по крайней мере об exception'ах..." (почти цитата по причине перевода).

То, как написано ведро винды к проблеме не относится, т.к. со стороны линуксоида (см. сырцы M$, доступные где-то в Сети) оно написано... Ну, лучше не буду говорить как именно оно написано. Мат на форуме запрещён... :D:D:D

Цитата the_Shadow @ 18.04.06, 06:21

Нет. Суть в том, что С использует парадигмы "конечных автоматов" и "функциональной декомпозиции". В С++ для их использования требуется приложить усилия. Дело в том, что нормальный и адекватный С-программист может сказать в какой момент времени что делает его программа. Т.е., есть набор функций, в идеале каждая из которых решает только одну задачу. Весь функционал (в данном случае ядра) собирается из вот таких вот атомарных функций.

Шад, ты не поверишь - в С++ все тоже самое! Те же функции, те же конечные автоматы... Просто набор инструментальных средств побогаче. Ведь те же упомянутые тобою "наследование" и "инкапсуляция" - лишь инструменты в руках программиста. Впрочем, как и "абстракция", "полиморфизм", "шаблоны" и т. д. и т. п.

Цитата

Просто набор инструментальных средств побогаче. Ведь те же упомянутые тобою "наследование" и "инкапсуляция" - лишь инструменты в руках программиста. Впрочем, как и "абстракция", "полиморфизм", "шаблоны" и т. д. и т. п.

Я согласен. Но, кажущаяся "бедность" средств С, здесь играет другую роль. Ведь С++ никогда не станет тем, чем стал С -- портируемым ассемблером (для интересующихся рекомендую вспомнить когда писался С и какие языки были в то время).

Кроме того, по весьма (для меня) странной привычке, С++-программисты очень любят "зарубаться" на всех этих "усложенениях". Как будто, чем сложнее код написан, тем оно круче... По этой причине, Алан Кокс (Alan Cox) как-то и заметил, что "С++ -- для тех, кто не понимает что компьютер -- устройство на базе конечных автоматов"... :D:D:D

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

Шад - ты сам себя забанишь за незнание или как?..
В С++ никто не заставляет пользоваться crtl (если уж тебя так волнует этот вопрос с загрузкой библиотек).
С++ - абсолютный аналог C по функциональности + сладкий яд
а за приведённый в первом посте код я бы увольнял

Цитата

Шад - ты сам себя забанишь за незнание или как?.. :)

:D:D:D

Цитата

В С++ никто не заставляет пользоваться crtl (если уж тебя так волнует этот вопрос с загрузкой библиотек).

Угу. вот только с gcc у тебя ровным счётом... ни как... :D:D:D А чем, как ты думаешь, мне собрать ядро Linux? Извини, но g++ (gpp) -- не более чем препроцессор для gcc (точнее, всё-таки, компилятора С). Таким образом, С в gcc (GNU Compiler Collection) первичен, а ++ -- ну, извини, так получилось... :D:D:D

Цитата

С++ - абсолютный аналог C по функциональности + сладкий яд :)

Хэх! Иногда даже договариваются до того, что С -- подмножество С++... :D:D:D
Это разные по идеологии программирования языки.

Цитата

а за приведённый в первом посте код я бы увольнял :yes:

По счастью, никто из kernel hackers об этом не знает и, видимо по этой причине, ядро работает. И довольно стабильно... :D:D:D

Цитата the_Shadow @ 18.04.06, 07:26

Ведь С++ никогда не станет тем, чем стал С -- портируемым ассемблером (для интересующихся рекомендую вспомнить когда писался С и какие языки были в то время).

Согласен. Не станет. Как можно стать тем, чем уже являешься?

Цитата the_Shadow @ 18.04.06, 07:26

Кроме того, по весьма (для меня) странной привычке, С++-программисты очень любят "зарубаться" на всех этих "усложенениях". Как будто, чем сложнее код написан, тем оно круче... По этой причине, Алан Кокс (Alan Cox) как-то и заметил, что "С++ -- для тех, кто не понимает что компьютер -- устройство на базе конечных автоматов"... :D:D

Хех. Что может быть проще использования boost::bind? Или boost::lambda? (примеры приведу по требованию) Но их реализация - это да. Без поллитры не разберешь. Точно также, как я без поллитры не разберу код линуксового ядра. И для меня это тоже будет казаться очень сложным. Я к тому, что сложность - понятие относительное. Как и простота. Пример с кокпитом реактивного самолета я уже приводил. Незнающий человек в обилии датчиков, тумблеров, переключателей, индикаторов просто запутается. Но это не значит, что кокпит плохо спроектирован, а самолет - отвратительно летает.

Цитата the_Shadow @ 18.04.06, 07:33

Угу. вот только с gcc у тебя ровным счётом... ни как... :D:D А чем, как ты думаешь, мне собрать ядро Linux? Извини, но g++ (gpp) -- не более чем препроцессор для gcc (точнее, всё-таки, компилятора С). Таким образом, С в gcc (GNU Compiler Collection) первичен, а ++ -- ну, извини, так получилось... :D:D

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

Цитата the_Shadow, 18.04.2006, 9:21:07, 1080660

То, как написано ведро винды к проблеме не относится

работает? быстро? правильно? вот и не трогай!

а насчёт goto таки да, при грамотном использовании оно очень даже полезно и злом не является.

Цитата

Шад, ты, по-моему, застрял где-то в начале 80-ых годов прошлого века, когда С++ действительно работал на уровне препроцессора. С тех пор многое изменилось, поверь мне :).

Уффф... Я тя поздравляю... См. gcc... Как-то по сию пору... Ибо работает... :D:D:D

Шад, С++ тоже работает на конечных автоматах
Примером языка, который не использует эти самые автоматы, например, SQL. (ну, опять таки, есть всякие надстройки и т.п.)
А уж если хочешь по настоящему другой идеологии - это вам на LISP нужно глянуть. Вот где водка будет уходить ящиками то

Цитата

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

однозначно

Добавлено 18.04.06, 09:46

Цитата

Это разные по идеологии программирования языки.

разные. А по функциональности С слабже.
Ну врят ли ты сможешь в компайл тайме посчитать. скажем, число Фибоначчи от 45 (ага, можно это руками сделать, но тогда каждую такую константу придётся комментировать - "это число фибоначчи от 33, это от 45 и т.п.)

Цитата the_Shadow @ 18.04.06, 09:39

Уффф... Я тя поздравляю... См. gcc... Как-то по сию пору... Ибо работает... :D:D

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

Цитата

Только сейчас из кода на С++ ты (в общем случае) не сможешь получить эквивалетнтый ему С-код путем одного только препроцессинга.

А я и не пытаюсь. Мне достаточно того, что делает gcc. Кстати, добавлю -- из С++ в gcc С не получается. Там... несколько иной принцип работы. Но называется это, пардон, но препроцессором.

Цитата

однозначно

RTFM. Однозначно RTFM (приговор доктора). Причины -- см. выше. Для уточнения принципов работы gcc.

Цитата

разные. А по функциональности С слабже.

Слава Богу, что признал. В ответ я признаю что по функционалу С позволяет делать то, что необходимо. Достаточно призрачным способом. Что, кстати, ядро Linux нам и демонстрирует.

Цитата

Ну врят ли ты сможешь в компайл тайме посчитать. скажем, число Фибоначчи от 45 :whistle: (ага, можно это руками сделать, но тогда каждую такую константу придётся комментировать - "это число фибоначчи от 33, это от 45 и т.п.)

Чего-чего? Что за бред!

Цитата the_Shadow @ 18.04.06, 10:27

Кстати, добавлю -- из С++ в gcc С не получается. Там... несколько иной принцип работы. Но называется это, пардон, но препроцессором.

Не понял. Подробнее.

Цитата

Не понял. Подробнее.

Уффф... Давай подробнее. Но, замечу, долго это... :D:D:D
Суть в том, что для преобразования (компиляции) в gcc используется RTTL (язык регистрового переноса). Таким образом реализованы все языки, входящие в gcc (Java, C++, Obj-C, Chill (ныне исключённый)). Собственно, после RTTL производится комплиляция в асм и далее по нисходящей.

С напрямую переводится в коды целевого асма (определяется ключами архитектуры процессора, для которого готовим код).

Добавлено 18.04.06, 10:51

Цитата

Ну врят ли ты сможешь в компайл тайме посчитать. скажем, число Фибоначчи от 45 :whistle: (ага, можно это руками сделать, но тогда каждую такую константу придётся комментировать - "это число фибоначчи от 33, это от 45 и т.п.)

Не понял утверждения. Чем тебе не нравятся эти решения -> http://www.cs.fiu.edu/~weiss/dsaa_c2e/files.html или http://docs.sun.com/app/docs/doc/806-3774/6jctamgut?a=view 8-/

Или, для решения банальнейшей задачи каждые 10 лет будем новые технологические решения разрабатывать? Вам что, делать не фиг? 8-/

Цитата the_Shadow @ 18.04.06, 10:47

Суть в том, что для преобразования (компиляции) в gcc используется RTTL (язык регистрового переноса). Таким образом реализованы все языки, входящие в gcc (Java, C++, Obj-C, Chill (ныне исключённый)). Собственно, после RTTL производится комплиляция в асм и далее по нисходящей.

С напрямую переводится в коды целевого асма (определяется ключами архитектуры процессора, для которого готовим код).

Теперь понятно. Но, сдается мне, что "так исторически сложилось". И говорить на этом основании, что С++ в gcc неполноценней, чем С я бы не стал...

Цитата

И говорить на этом основании, что С++ в gcc неполноценней, чем С я бы не стал...

Fuck, Flex, а где я это сказал? Это -- разные языки с разными областями применения. Другой аспект, что в M$ всё по-перемешалось, что, при переходе в Linux, приводит к "непоняткам". Но при чём здесь Linux и то, как там что сделано? :D:D:D

Цитата

Но, сдается мне, что "так исторически сложилось". :)

Нет. Ключевые слова здесь -- GNU Compilers Collection. Причём, должен быть язык, скажем так, первичный. Тот, на котором можно написать всё остальное. Точнее, не "написать", а "с помощью которого скомпилировать всё остальное". Вот, исходя из этого, всё и вытанцовывается.

Кстати, теперь понял почему я не суюсь в раздел по С|С++? :D:D:D