Здравствуйте, Кирилл Блаженнов, Вы писали:
КБ>Вот здесь Торвальдс расписывает следующее: КБ>1) С++ — говно. КБ>2) С рулит
КБ>Прочитал статью — там вообще здоровая аргументация имеется?
Нет, аргументация неосилятора. КБ>Кто что думает по этому поводу?
Ну он гнёт свою линию С форева, С++ мастдай.
Здравствуйте, Кирилл Блаженнов, Вы писали:
КБ>Вот здесь Торвальдс расписывает следующее: КБ>1) С++ — говно. КБ>2) С рулит
Вообще-то в этой статье Торвальдс ничего не расписывает. Расписывает автор статьи, и он заметно уводит разговор в сторону.
КБ>Прочитал статью — там вообще здоровая аргументация имеется?
У кого? У Торвальдса — да. У автора статьи — нет, у него национальное русское блюдо "каша в голове", потому что он не представляет себе отличия программирования для ядра и пытается применять аргументы типа "в C stdio нельзя читать строки произвольной длины", хотя и ничего ему не мешает, и stdio не единственное IO для C (вспомним хотя бы sfio), и — что самое главное — stdio в ядре это полная чушь (хотя есть пара внешне похожих функций типа kprintf, тем не менее даже приблизительного аналога нет и не будет).
КБ>Кто что думает по этому поводу?
Ряд факторов, которые для обычного прикладного софта имеют малое значение, принципиальны для ядра. И именно эти факторы являются слабоуправляемыми или вообще неуправляемыми при написании на C++. В их число входит, например, объём сгенерированного кода (в основном того, что из шаблонов), детали реализации структур данных в STL и аналогах. Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI.
Если бы существовала промышленная поддержка промежуточного между C и современным C++ языка, который имеет классы и инкапсуляцию, наследование (можно без множественного) и виртуальные методы, пространства имён (то есть приблизительно равно так называемой C++ версии 1.5, по нумерации Страуса и cfront) — то это был бы отличный язык для ядра. Но C++ пошёл дальше и стал слабо пригодным к этому.
Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков.
Именно об этом стоило бы говорить в контексте "Linus & C++", а не тот бред, что в статье.
Здравствуйте, Кирилл Блаженнов, Вы писали:
КБ>Вот здесь Торвальдс расписывает следующее: КБ>1) С++ — говно. КБ>2) С рулит
КБ>Прочитал статью — там вообще здоровая аргументация имеется?хЪ
Неа, тезисно.
0. Сразу назвать оппонента *даком, это задаст нужный тон академической дискуссии (дискуссия там шикарная, есть даже пара адекватов).
1. C++ говно потому что говно, те кто думает иначе -- гавнюки.
2. Если бы единственной причиной использовать C было не допустить в проект программистов C++, то он бы это сделал, потому что он бохъ, а они см. п.1.
3. Те, кто не согласен со мной гавнюки и скорее всего пишут на С.
4. Халва!Халва!Халва!
5. Не нравится C, переходи на .... КБ>Кто что думает по этому поводу?
Либо у Торвальдса ПМС и плохое настроение, либо он настоящий вождь красноглазых.
Здравствуйте, netch80, Вы писали:
КБ>>Прочитал статью — там вообще здоровая аргументация имеется?
N>У кого? У Торвальдса — да. У автора статьи — нет, у него национальное русское блюдо "каша в голове", потому что он не представляет себе отличия программирования для ядра
так у вас та же каша
N>Ряд факторов, которые для обычного прикладного софта имеют малое значение, принципиальны для ядра. И именно эти факторы являются слабоуправляемыми или вообще неуправляемыми при написании на C++. В их число входит, например, объём сгенерированного кода (в основном того, что из шаблонов), детали реализации структур данных в STL и аналогах. Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI.
чем вам мешает RTTI которое никак не связано с ОС?
какбэ RTTI реализуется константными статическими структурами данных, привязанными к таблицам виртуальнцых методов.
а что там с исключениями? я хз как у вас в линуксе, но например в винде в ядре есть исключения, причем в Си
N>Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков.
какая еще синхронизация в STL?
или вы не про STL а про стандартную библиотеку? так там тоже нет синхронизации %)
Здравствуйте, Abyx, Вы писали:
N>>У кого? У Торвальдса — да. У автора статьи — нет, у него национальное русское блюдо "каша в голове", потому что он не представляет себе отличия программирования для ядра A>так у вас та же каша
В чём?
N>>Ряд факторов, которые для обычного прикладного софта имеют малое значение, принципиальны для ядра. И именно эти факторы являются слабоуправляемыми или вообще неуправляемыми при написании на C++. В их число входит, например, объём сгенерированного кода (в основном того, что из шаблонов), детали реализации структур данных в STL и аналогах. Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI. A>чем вам мешает RTTI которое никак не связано с ОС? A>какбэ RTTI реализуется константными статическими структурами данных, привязанными к таблицам виртуальнцых методов.
Мешает, например, тем, что невозможно предсказать, в каком именно модуле будет заведена эта таблица. Практически она заводится в каждом, с помощью COMMON-блоков (в терминологии COFF — COMDAT-записей).
Это хорошо, если речь идёт о итоговом монолитном бинарнике, но с модульной структурой ядра это превращается в кошмар.
A>а что там с исключениями? я хз как у вас в линуксе, но например в винде в ядре есть исключения, причем в Си
Я знаю про SEH, но копировать его или аналог в Linux не стали. И, кстати, SEH достаточно сильно отличается от исключений C++ (и попытки объединить их в единый механизм имеют существенные проблемы).
В общем вопроса не понял. Исключения — достаточно специфический механизм; самое неприятное для ядерного программирования — что в некоторых случаях их в принципе нельзя допускать, или делать сложные и дорогие схемы перехвата.
N>>Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков. A>какая еще синхронизация в STL? A>или вы не про STL а про стандартную библиотеку? так там тоже нет синхронизации %)
По тому, что я видел, она кое-где таки есть. Даже в сишной библиотеке не зря отличаются fputc() и fputc_unlocked().
Здравствуйте, netch80, Вы писали:
A>>чем вам мешает RTTI которое никак не связано с ОС? A>>какбэ RTTI реализуется константными статическими структурами данных, привязанными к таблицам виртуальнцых методов.
N>Мешает, например, тем, что невозможно предсказать, в каком именно модуле будет заведена эта таблица. Практически она заводится в каждом, с помощью COMMON-блоков (в терминологии COFF — COMDAT-записей). N>Это хорошо, если речь идёт о итоговом монолитном бинарнике, но с модульной структурой ядра это превращается в кошмар.
в чем кошмар-то? разве что только в том что при компиляции всех модулей заголовочные файлы должны быть одинаковы.
N>>>Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков. A>>какая еще синхронизация в STL? A>>или вы не про STL а про стандартную библиотеку? так там тоже нет синхронизации %)
N>По тому, что я видел, она кое-где таки есть. Даже в сишной библиотеке не зря отличаются fputc() и fputc_unlocked().
так библиотека ввода-вывода это не STL
N>Если бы существовала промышленная поддержка промежуточного между C и современным C++ языка, который имеет классы и инкапсуляцию, наследование (можно без множественного) и виртуальные методы, пространства имён (то есть приблизительно равно так называемой C++ версии 1.5, по нумерации Страуса и cfront) — то это был бы отличный язык для ядра. Но C++ пошёл дальше и стал слабо пригодным к этому.
Дык есть EC++: это просто С с классами и шаблонами. Без виртуального/множественного наследования и исключений.
A>а что там с исключениями? я хз как у вас в линуксе, но например в винде в ядре есть исключения, причем в Си
А вы в курсе что в ядре винды SEH не работает на irql>PASSIVE_LEVEL ?
N>>Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков. A>какая еще синхронизация в STL? A>или вы не про STL а про стандартную библиотеку? так там тоже нет синхронизации %)
Ну фиг с ней, с синхронизацией. Но есть две большие неприятности, которые могут превратить в геморрой работу с СТЛ. Первая — размер стека. В ядре винды он 12кб. Потому стандартные тактики типа создать на стеке структурку и потом всунуть ее в vector уже чреваты. Вторая — irql и разные пулы памяти. Не любую выделенную на PASSIVE память мона читать на более высоком уровне. Придется вводить дополнительные аллокаторы с обязаловкой их указания при инстанциировании контейеров.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, netch80, Вы писали:
N>Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI.
Это не так.
N>Если бы существовала промышленная поддержка промежуточного между C и современным C++ языка, который имеет классы и инкапсуляцию, наследование (можно без множественного) и виртуальные методы, пространства имён (то есть приблизительно равно так называемой C++ версии 1.5, по нумерации Страуса и cfront) — то это был бы отличный язык для ядра. Но C++ пошёл дальше и стал слабо пригодным к этому.
Ну, казалось бы, сильно ограничить использование шаблонов + полностью отказаться от stl и вперёд...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, __UNIX_hokum, Вы писали:
__U>На плюсах можно ваять эффективны код даже для 8-bit контроллеров. Так что, не все Торвальдсы одинаково полезны.
Можно, но шаблоны таки использовать нежелательно — памяти может не хватить.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, netch80, Вы писали:
N>>Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI.
E>Это не так.
N>>Если бы существовала промышленная поддержка промежуточного между C и современным C++ языка, который имеет классы и инкапсуляцию, наследование (можно без множественного) и виртуальные методы, пространства имён (то есть приблизительно равно так называемой C++ версии 1.5, по нумерации Страуса и cfront) — то это был бы отличный язык для ядра. Но C++ пошёл дальше и стал слабо пригодным к этому.
E>Ну, казалось бы, сильно ограничить использование шаблонов + полностью отказаться от stl и вперёд...
На самом деле кому сильно надо — тот так и делает. Собсна и сама Atmel рекомендует такую практику, если пишешь для восьмибитных AVR, а чистый C не устраивает.
> Можно, но шаблоны таки использовать нежелательно — памяти может не хватить.
Ой, да ладно, вроде, без шаблонов невозможно наговнякать код, который отожрёт всю память, и ещё попросит. Если понимать работу шаблонов, то можно писать код, не уступающий обычному, C-шному, как по размерам, так и по скорости.
CDE>Можно, но шаблоны таки использовать нежелательно — памяти может не хватить.
Ау, в танке! Для разворачивания шаблонов память нужна во время компиляции! Размер/производительность/прожорливость скомпилиованного кода для шаблонов и #define будет абсолютно одинаковая.
Не надо путать с шаблоны исключениями и кучей.
Здравствуйте, Кирилл Блаженнов, Вы писали:
КБ>Прочитал статью — там вообще здоровая аргументация имеется? КБ>Кто что думает по этому поводу?
ИМХО, всем этим дрочиловом а-ля "правильный язык — неправильный язык" занимаются люди, "сидящие на бюджете". Ни одна из мне известных фирм не выбирала язык по принципу "этот хороший, этот плохой".
А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.
W>А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.
Еще — Си просто проще. Я не сишник, и последний раз писал на Си(++) в институте лабы. Я жавист, с 3-го курса пишу на жабе. Но недавно проект на Си сделал без проблем(был единственный фейл — я забыл, что char в си однобайтный, но решилось быстро), причем проект под девайс с 64К памяти и прочими незавидными характеристиками(проц медленный, видно отображение символов на текстовом экране). На плюсах я бы задолбался. А так — несколько простых правил: выделяем все на стеке(памяти и так мало, с кучей заморачиваться нет смысла), не возвращаем локальные переменные и... Да и все, по сути. Разве что работа со строками немного парит(ну, после высокоуровневых языков, а либы не сильно поподключаешь в такой проект, ограничение на размер бинарника 90 килобайт), но все решаемо. А плюсовика на небольшой проект нанимать было бы дорого и бессмысленно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
