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

Цитата

Кстати, BuhgHunter, есть ещё один вывод. Хорошо известно, что для ОСей, очень активно использующих С++, довольно много вирусов -- цинда и Symbian коррелируют с этим утверждением. А как быть с тем, что для PalmOS & Linux весьма и весьма мало вирусов? :D:D

А мне какзалось, тут дело в популярности .

Сообщение отредактировано: BugHunter - 26.07.06, 08:05

Цитата BugHunter @ 26.07.06, 07:59

Дело совсем не в понтах. на ++ реально ПРОЩЕ делать большие и огромные системы

А на Си реально КАЧЕСТВЕННЕЕ делать большие и огромные системы

Добавлено 26.07.06, 08:04
php, к примеру, вобще простой язык, только качество решений на нем очень часто низко.

Цитата

php, к примеру, вобще простой язык, только качество решений на нем очень часто низко.

php отличный c++ like язык, и качество решений на нём напрямую зависит от прямизны рук производителя.

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

Добавлено 26.07.06, 08:20

Цитата BugHunter @ 26.07.06, 08:07

php отличный c++ like язык, и качество решений на нём напрямую зависит от прямизны рук производителя.

Это, впрочем, можно отнести к любому средству разработки.

Цитата BugHunter @ 26.07.06, 08:07

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

И с этим тоже согласен. А потому предлагаю сосредоточится на реальных вопросах, касающихся оверхеда (как на уровне кода, так и на уровне результатов компиляции) при использовании С++.

Цитата p_kolya @ 26.07.06, 08:04

А на Си реально КАЧЕСТВЕННЕЕ делать большие и огромные системы

Да ну что ты?
Отличное высказывание? Я тоже могу сказать
На ассемблере реально КАЧЕСТВЕННЕЙ делать большие и огромные системы
А еще лучше в машинных кодах писать! А чо!

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

КАЧЕСТВО - это что по твоему вообще? По мне так качество - это когда программа делает то, что написано в документации к ней(ну м.б. больше, но не меньше никак). Что С, что С++ позволяют написать хорошо оптимизированный и удобный код, НО Цэ++ поддерживает механизмы обобщения(шаблоны), исключения и ООП что
1) Уменьшает количество исходных кодов.
2) Делает программу значительно более расширяемой
3) Уменьшает вероятность ошибок(изза значительно уменьшенного объема кода, а также механизма искллючений).

Эти 3 пунка как раз позволяют писать более оптимальный код, а также чаще позволяет писать код более соответствующие проекту.

Вывод:
1) C++ не медленней(а чеще и быстрее (сравни std::sort и qsort))
2) С++ расширяемей
3) С++ обобщенней
4) С++ менее подвержен ошибкам
5) С++ более приспособлен для отражения существующего проекта
6) С++ короче(исходный код больше)
7) С++ дает иногда больший размер бинарников

О каком более качественном кодинге на С вообще реч.
Ядро ОС? Ну.. по мне так я был бы рад если его писали на С++.. я бы отдал за это 100МБ оперативы(ну это верхний предел..), зато уверен - багов было бы меньше, и работыло бы не медленней.

Сообщение отредактировано: LuckLess - 26.07.06, 08:43

А потому предлагаю "рестартовать" обсуждение с моего поста Вопрос к программистам на C (сообщение #1185864). Там мною были откомментированы прара занимательных ссылок, предоставленных Шадом. Как раз касающихся вопросов оверхеда.

Добавлено 26.07.06, 08:46

Цитата LuckLess @ 26.07.06, 08:41

1) Уменьшает количество исходных кодов.
2) Делает программу значительно более расширяемой
3) Уменьшает вероятность ошибок(изза значительно уменьшенного объема кода, а также механизма искллючений).

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

Полностью поддерживаю оратора, высказавшего мысль о том, что все зависит от прямоты рук.

Цитата LuckLess @ 26.07.06, 08:41

1) C++ не медленней(а чеще и быстрее (сравни std::sort и qsort))

Ну тогда функтор для сравнения пусть будет extern'овой функцией, чтобы не было inline-подстановок, а?

Цитата LuckLess @ 26.07.06, 08:41

2) С++ расширяемей

Не понял высказывания. Ты что, средствами C++ можешь реализовать новый диалект этого языка?

Цитата LuckLess @ 26.07.06, 08:41

4) С++ менее подвержен ошибкам

Подвержен как и C. Все зависит от рук.

Цитата LuckLess @ 26.07.06, 08:41

5) С++ более приспособлен для отражения существующего проекта

Ну это ты загнул. Захотелось CGI на C++ попробовать и сравнить с PHP/JSP/ASP.NET? Для каждой задачи существует инструмент, который лучше остальных подходит для ее решения. И далеко не всегда это C++. Его часто используют не к месту, ибо модно/популярно/ничего другого не знают.

Цитата LuckLess @ 26.07.06, 08:41

6) С++ короче(исходный код больше)

Не понял высказывания. В смысле, код на C++ короче аналогичного кода на C? Такое бывает.

Цитата LuckLess @ 26.07.06, 08:41

О каком более качественном кодинге на С вообще реч.

И я тоже никак не пойму, что за неприязнь к C. Дерьмовый код можно написать на чем угодно.

Цитата LuckLess @ 26.07.06, 08:41

Ядро ОС? Ну.. по мне так я был бы рад если его писали на С++..

Мусье хорошо представляет себе, что программирование ядра сильно отличается от написания прикладного ПО? Какой бы был выигрыш, если на каждом шагу вызывались бы конструкторы, деструкторы; поддержка try/catch/throw, я так понимаю, тоже определенных ресурсов требует.
C здесь лучше хотя бы потому, что число сторонних эффектов в коде сведено к минимуму.

Цитата linuxfan @ 26.07.06, 09:21

Ну тогда функтор для сравнения пусть будет extern'овой функцией, чтобы не было inline-подстановок, а?

Производительность изменится, но не существенно.

Цитата linuxfan @ 26.07.06, 09:21

Не понял высказывания. Ты что, средствами C++ можешь реализовать новый диалект этого языка?

При определенной доле допущения в слове "диалект" - да. Реализовали же lambda-выражения? Реализовали (boost::lambda). Реализовали описание грамматик? Реализовали (boost::spirit). Знаю, что реализовывали lisp-подобные конструкции. Я к тому, что в этом отношении синтаксис С++ достаточно гибок. С фортом, конечно, не сравнится, но...

Цитата linuxfan @ 26.07.06, 09:21

Подвержен как и C. Все зависит от рук.

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

Цитата linuxfan @ 26.07.06, 09:21

Какой бы был выигрыш, если на каждом шагу вызывались бы конструкторы, деструкторы; поддержка try/catch/throw, я так понимаю, тоже определенных ресурсов требует.
C здесь лучше хотя бы потому, что число сторонних эффектов в коде сведено к минимуму.

А вот тут есть тонкий момент. Нужно хорошо представлять - как работает та или иная языковая конструкция. Как и когда вызываются консртукторы/деструкторы, к чему приводит использование болков try/catch и т. п. И при желании можно количество такого оверхеда свести к минимуму (если не сказать - "на нет"). Но тут лучше смотреть на реальном материале.

Цитата linuxfan @ 26.07.06, 09:21

Ну тогда функтор для сравнения пусть будет extern'овой функцией, чтобы не было inline-подстановок, а?

А зачем? Чтобы стало медленней я могу просто Sleep() в коде написать.
Другое дело что на С это сделать в принципе нельзя.

Цитата linuxfan @ 26.07.06, 09:21

Не понял высказывания. Ты что, средствами C++ можешь реализовать новый диалект этого языка?

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

Цитата linuxfan @ 26.07.06, 09:21

Подвержен как и C. Все зависит от рук.

Ну это само собой. Руки - главный инструмент. Но на С++ ошибок делается меньше из-за лаконичности и обобщения.

Цитата linuxfan @ 26.07.06, 09:21

Ну это ты загнул. Захотелось CGI на C++ попробовать и сравнить с PHP/JSP/ASP.NET? Для каждой задачи существует инструмент, который лучше остальных подходит для ее решения. И далеко не всегда это C++. Его часто используют не к месту, ибо модно/популярно/ничего другого не знают.

Проэкт обычно описан языком более подходящем для того чтобы реализовывать его на С++ нежели чем на С.

Цитата linuxfan @ 26.07.06, 09:21

Не понял высказывания. В смысле, код на C++ короче аналогичного кода на C? Такое бывает.

именно что короче.

Цитата linuxfan @ 26.07.06, 09:21

И я тоже никак не пойму, что за неприязнь к C. Дерьмовый код можно написать на чем угодно.

Это да))

Цитата linuxfan @ 26.07.06, 09:21

Мусье хорошо представляет себе, что программирование ядра сильно отличается от написания прикладного ПО? Какой бы был выигрыш, если на каждом шагу вызывались бы конструкторы, деструкторы; поддержка try/catch/throw, я так понимаю, тоже определенных ресурсов требует.
C здесь лучше хотя бы потому, что число сторонних эффектов в коде сведено к минимуму.

Мусье как только видит 3 символа "C++" так сразу представляет себе конструкторы деструкторы и исключения? Чтож.. обыдно.
Большинство основных объектов ядра можно представить С++ обхектами - синглетонами, для которых собстно будет вызван 1 раз конструктор и 1 раз деструктор. С++ исключения врятли можно применить в ядре ессесно. Но заворачивание основных сущностей ядра в С++ классы и реализация похожих механизмов при помощи тех же шаблонов вполне бы подошло.

Сообщение отредактировано: LuckLess - 26.07.06, 09:42

Цитата

Ну тогда функтор для сравнения пусть будет extern'овой функцией, чтобы не было inline-подстановок, а?

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

Цитата

Не понял высказывания. Ты что, средствами C++ можешь реализовать новый диалект этого языка?

вероятно, имелось ввиду, что использование ООП позволяет расширять функциональность программы (системы) в будущем без серьезной переделки системы в целов. одно только динамическое связывание и полиморфизм чего только стоит. как это сделать в С, я слабо представляю. например, как на С реализовать паттерн "машина состояний", "команда", "алгоритм"?

Шад все грозился провести какое-то сравнение языков С и С++. Но, видимо, не осилил. Или времени так и не нашел. А потому есть предложение (если это кому-нибудь это действительно интересно) проверить оверхед С++ на более-менее реальных задачах, перейдя в раздел "Чистый С++". Проверять предлагаю так. С-шники предлагают задачу, в которой (по их мнению) будет существенный оверхед при реализации ее на С++. Предлагают свое решение. С++-сники предлагают свое. Сравниваем результаты. Как по объему исходного текста, так и по полученному ассемблерному результату.

Цитата Flex Ferrum @ 26.07.06, 07:12

а потому как соотносятся те или иные стандарты, и существуют ли они вообще - не столько для него принципиально.

Ну, да... Конечно...
Так зачем, говоришь, С-функции в Symbian'е? Для того, чтобы соответствовать тому, что у меня в голове?
Ну ни хрена себе... Буду теперь знать. Б?я! Это ж до какой степени нужно хотеть доказать свою правоту, не имея к тому ни единого шанса, с тем, чтобы отрицать очевидное!

Тебе показывают -- вот, производитель во имя того, чтобы поддерживать POSIX 1003.1 System Interfaces реализует С-функции, ан нет -- это для того, чтобы соответствовать мыслям какого-то дядьки из России.

Flex, смешно. И немного грустно. А вас, так называемых "профессиональных" программистов от души жаль, т.к. ваш "профессионализм" простирается на далее того, что вы сами считаете правильным. Дело ваше, а всё остальное -- и факты и рассуждения -- выше.

Стена ждёт тебя, Flex. Что делать -- ты в курсе, да?

Добавлено 26.07.06, 09:53

Цитата Flex Ferrum @ 26.07.06, 09:44

Но, видимо, не осилил. Или времени так и не нашел.

Видимо, мне просто лень. За такого рода исследование денег мне, я полагаю, не заплатят.

Цитата the_Shadow @ 26.07.06, 09:51

Это ж до какой степени нужно хотеть доказать свою правоту, не имея к тому ни единого шанса, с тем, чтобы отрицать очевидное!

Шадыч, хочу заметить, что ты (имея все шансы на это) не смог привести ни одной цитаты из стандарта POSIX, подтверждающие твою точку зрения (оглавление и описание fflush таковыми также не являются в силу описанных выше обстоятельств). И я не берусь обсуждать что есть и чего нет в Symbian, потому что не имею об этой системе (и о требованиях к ней) никакого представления. По этому с документацией по этой системе - не ко мне, а к людям, которые хорошо осведомлены об этой системе. Сейчас для меня (в дискуссии с тобой) имеет значение только стандарты. И ничего кроме стандартов.

Цитата the_Shadow @ 26.07.06, 09:51

Flex, смешно. И немного грустно. А вас, так называемых "профессиональных" программистов от души жаль, т.к. ваш "профессионализм" простирается на далее того, что вы сами считаете правильным. Дело ваше, а всё остальное -- и факты и рассуждения -- выше.

Шадыч, хочу заметить, что это высказывание (в том числе) напрямую относится и к тебе. И (еще раз обращаю твое внимание): ни одного факта (читай - цитаты из стандартов IEEE 1003.1x, который POSIX) ты не привел. Ты практически ни одно из своих высказываний не подтвердил цитатами все из того же стандарта. Так о каких фактах ты говоришь? А уровень моего профессионализма попрошу не трогать. Ибо для его выяснения (и суждения на его счет) тебе предется подтвердить уровень своего профессионализма. Ты готов к этому?

Цитата the_Shadow @ 26.07.06, 09:51

Видимо, мне просто лень. За такого рода исследование денег мне, я полагаю, не заплатят.

Ну, лень - так лень. Тогда позволь мне твои рассуждения на этот счет считать ничем не подкрепленными абстрактными рассуждениями.

Цитата Flex Ferrum @ 26.07.06, 09:37

Производительность изменится, но не существенно.

Мне кажется, что она упадет на уровень сишного qsort'а. Алгоритм-то один и тот же, а плюсы выигрывают как раз за счет inline-подстановки.

Цитата Flex Ferrum @ 26.07.06, 09:37

Знаю, что реализовывали lisp-подобные конструкции.

Насколько подобные? Не верю я в гибкость C++. Плюсовым темплейтам до Lisp'овского DEFMACRO как до луны пешком

Цитата Flex Ferrum @ 26.07.06, 09:37

Только ошибки другого характера и другого уровня (т. е. несколько более высокоуровневые).

Ну да. Ошибки вида "этот **** компилер всунул вызов деструктора куда не следует" (утрирую)

Цитата Flex Ferrum @ 26.07.06, 09:37

Нужно хорошо представлять - как работает та или иная языковая конструкция.

Как только мы сосредотачиваемся на инструменте, а не на задаче, значит настала пора подобрать другой инструмент.

Цитата Flex Ferrum @ 26.07.06, 09:37

И при желании можно количество такого оверхеда свести к минимуму (если не сказать - "на нет").

Можно, только к чему мы придем в итоге? "Вкусности" C++ как раз могут принести оверхед туда, где он не нужен.
Пример? Пожалуйста: бинарные операторы (+,-,*,/,&,| и т.д.) должны вернуть значение, после чего при присваивании произойдет копирование этого значения в результат. Т. е. запись
[code=cpp]MyClass a,b,c;
/*инициализируем b и c */
a = b+c;[code]
приведет к созданию промежуточного временного объекта и это уже головная боль программиста, чтобы обеспечить минимальный оверхед при создании/удалении объекта. В std::string это решили "шареньем" (sharing) строкового значения. Но такой подход:
1. может быть сложен в реализации
2. ведет к необходимости написания дополнительного избыточного кода, а дополнительный код -- дополнительное поле для граблей
По уму тогда уж нужен operator +(const MyClass &a,const MyClass &b,MyClass &res), где задача по подбору res (временный объект или сразу lvalue) возьмет на себя компилятор.

Цитата LuckLess @ 26.07.06, 09:40

Другое дело что на С это сделать в принципе нельзя.

Можно. qsort пишется макросом в заголовке, в качестве аргумента передается inline-функция для сравнения. Но безусловно, плюсовое решение с template будет намного понятнее.

Цитата LuckLess @ 26.07.06, 09:40

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

Плохое утверждение. Т. к. плюсовое ABI не стандартизовано даже в рамках одной ОС, с плюсовыми shared object в Linux работать практически невозможно. Помню, как я пытался собрать ClanLib интеловским компилем. Ни одно приложение, собранное gcc, не смогло слинковаться с этой либой
Если ты думаешь, что плагины можно реализовывать исключительно на C++, то посмотри на:
1) gimp
2) gdk-pixbuf (подключаемые лоадеры)
3) devcot/cyrus (imap сервера; и тот и другой легко расширяются, но в "запланированных авторами пределах")
4) bonobo -- аналог COM, но на C (часть GNOME)
5) uw-imapd (там дизайн позволяет писать свои storage)

Цитата LuckLess @ 26.07.06, 09:40

Проэкт обычно описан языком более подходящем для того чтобы реализовывать его на С++ нежели чем на С.

Какие языки кроме C/C++ ты знаешь, чтобы выдвигать столь смелое утверждение? Используемый инструмент сильно влияет на образ мышления. Возможно, тебе весь мир видится в темплейтах и классах, а на самом деле проект может быть реализован питоне красиво, эффективно и слету?
Или ты подразумеваешь именно что "легче на C++, чем на C"? Это утверждение скорее правдиво, т. к. легче использовать std::string, std::vector и пр, чем писать свой велосипед (glib не предлагать, ибо эффективность сильно снижается).

Цитата Flex Ferrum @ 26.07.06, 10:10

Сейчас для меня (в дискуссии с тобой) имеет значение только стандарты. И ничего кроме стандартов.

Извини, уже приводились. Не произвели на тебя ни какого впечатления, т.к. ты постоянно аппелируешь к ISO, описывающему язык С, но "забиваешь" на то, что тебе приводилось выше. К примеру, сообщение # 283.
Дана ссылка на документ и приведено содержимое страницы. Где там хоть что-то, отличное от С?

Какого вообще хрена аппелировать к тому, что там не описано? Где там Ada, Java, C++, asm? Функции какого языка там перечислены? И, в данном контексте, при чём здесь "можно описать на всём, на чём угодно?", если оно уже описано? И, если оно не описано, что же всё-таки, описывает POSIX 1003.1 System Interfaces и каким именно образом? Если это не функции языка С, определяющие системный API для POSIX-совмеситмых ОС, то... В принципе, вопросы уже сейчас риторические.

Ой, чесслово -- думай и делай и говори что угодно. Твой "профессионализьм" меня слабо волнует...

Добавлено 26.07.06, 10:40

Цитата linuxfan @ 26.07.06, 10:38

Если ты думаешь, что плагины можно реализовывать исключительно на C++, то посмотри на:

Видимо, linuxfan, он не знает о существовании семейства dl-функций... :D:D:D

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

Цитата linuxfan @ 26.07.06, 10:38

Плохое утверждение.

После работы с GTK+/GNOME (писанными на С по большей части) -- никудышное, уж извини, LuckLess, но вообще никудышное. Довольно сложные проекты описаны прямо и руками. С минимумом бреда.

Как пример -- проект на С++ (Qt) имеет класс QThread. А зачем оно там? posix_threads уже перестали работать? А вот в GTK+/GNOME попыток "описать всё" просто нет. Есть набор либ. Каждая описывает какой-то аспект (gnet -- позволяет работать с сетью, есть либы по работе с БД, и т.д. и т.п.), но именно и чисто "системный уровень" остаётся за самой системой. Как, в принципе, и должно быть.