Re[6]: Дочитал - Компьютерные священные войны

Здравствуйте, Кирилл Блаженнов, Вы писали:

КБ>Вот здесь Торвальдс расписывает следующее:
КБ>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

Здравствуйте, netch80, Вы писали:

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 память мона читать на более высоком уровне. Придется вводить дополнительные аллокаторы с обязаловкой их указания при инстанциировании контейеров.

На плюсах можно ваять эффективны код даже для 8-bit контроллеров. Так что, не все Торвальдсы одинаково полезны.

Здравствуйте, 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 не устраивает.

КБ>Кто что думает по этому поводу?

Mike Williams, один из создателей Erlang'а: «C++ и Java не нужны»

> Можно, но шаблоны таки использовать нежелательно — памяти может не хватить.

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

CDE>Можно, но шаблоны таки использовать нежелательно — памяти может не хватить.

Ау, в танке! Для разворачивания шаблонов память нужна во время компиляции! Размер/производительность/прожорливость скомпилиованного кода для шаблонов и #define будет абсолютно одинаковая.
Не надо путать с шаблоны исключениями и кучей.

Здравствуйте, Кирилл Блаженнов, Вы писали:

КБ>Прочитал статью — там вообще здоровая аргументация имеется?
КБ>Кто что думает по этому поводу?
ИМХО, всем этим дрочиловом а-ля "правильный язык — неправильный язык" занимаются люди, "сидящие на бюджете". Ни одна из мне известных фирм не выбирала язык по принципу "этот хороший, этот плохой".
А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.

Здравствуйте, Wissenschaftler, Вы писали:

W>А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.

Еще — Си просто проще. Я не сишник, и последний раз писал на Си(++) в институте лабы. Я жавист, с 3-го курса пишу на жабе. Но недавно проект на Си сделал без проблем(был единственный фейл — я забыл, что char в си однобайтный, но решилось быстро), причем проект под девайс с 64К памяти и прочими незавидными характеристиками(проц медленный, видно отображение символов на текстовом экране). На плюсах я бы задолбался. А так — несколько простых правил: выделяем все на стеке(памяти и так мало, с кучей заморачиваться нет смысла), не возвращаем локальные переменные и... Да и все, по сути. Разве что работа со строками немного парит(ну, после высокоуровневых языков, а либы не сильно поподключаешь в такой проект, ограничение на размер бинарника 90 килобайт), но все решаемо. А плюсовика на небольшой проект нанимать было бы дорого и бессмысленно.

Здравствуйте, Eugeny__, Вы писали:

E__>был единственный фейл — я забыл, что char в си однобайтный

Ага, щас, в Си sizeof(char) = 4, в С++ sizeof(char) = 1.

Здравствуйте, Кирилл Блаженнов, Вы писали:

КБ>1) С++ — говно.
КБ>2) С рулит

КБ>Прочитал статью — там вообще здоровая аргументация имеется?

не знаю, не читал

КБ>Кто что думает по этому поводу?

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

Здравствуйте, Brutalix, Вы писали:

B>Здравствуйте, Кирилл Блаженнов, Вы писали:

КБ>>1) С++ — говно.
КБ>>2) С рулит

КБ>>Прочитал статью — там вообще здоровая аргументация имеется?

B>не знаю, не читал

КБ>>Кто что думает по этому поводу?

B>Но вообще, мой жизненный опыт мне подсказывает, что хвалят С и ругают С++ те, кто С выучил, а С++ не осилил. Те кто могёт и на том и на другом, обычно в бутылку не лезут.
Кому что удобнее тот то и хвалит. Мне на C писать менее привычно, поэтому считаю, что C -- говноязык. Но поскольку кролик очень воспитанный, то он никому об этом не говорит.

Здравствуйте, sysenter, Вы писали:

S>Здравствуйте, Eugeny__, Вы писали:

E__>>был единственный фейл — я забыл, что char в си однобайтный

S>Ага, щас, в Си sizeof(char) = 4, в С++ sizeof(char) = 1.

Или Вы имеете в виду под sizeof что-то своё нестандартное, или сильно ошибаетесь.
Собственно sizeof(char) в чистом C у меня без всяких хохмочек выдаёт значение 1.

$ cat >4.c
#include <stdio.h>
int main() {
  printf("%u\n", (int)sizeof(char));
}
$ gcc -o 4 4.c
$ ./4
1

Если же речь про особенность представления в int, то это надо указывать явно.

Здравствуйте, sysenter, Вы писали:

S>Ага, щас, в Си sizeof(char) = 4,

Боже, это ж где такая трава растет??

Здравствуйте, sysenter, Вы писали:

E__>>был единственный фейл — я забыл, что char в си однобайтный

S>Ага, щас, в Си sizeof(char) = 4, в С++ sizeof(char) = 1.

В Си sizeof(char) = 1. А вот 'c' является не char, а int.

Здравствуйте, netch80, Вы писали:

N>Или Вы имеете в виду под sizeof что-то своё нестандартное, или сильно ошибаетесь.

Eugeny__ говорит, что символы якобы в Си однобитные, что не соответствует действительности.
Вот проверь sizeof('a');

Здравствуйте, Deprivator, Вы писали:

S>>Ага, щас, в Си sizeof(char) = 4,
D>Боже, это ж где такая трава растет??

Разъяснение специально для тупых, Eugeny__ говорит, что якобы в Си размер символа 1 байт соответсвенно исходя из контекста я привёл размер не типа дынных char, а размер символа который в английском языке обозначается словом — char.
В Си sizeof('a') = 4

Здравствуйте, sysenter, Вы писали:

S>Eugeny__ говорит, что символы якобы в Си однобайтные, что не соответствует действительности.
S>Вот проверь sizeof('a');

fixed

Здравствуйте, ДимДимыч, Вы писали:

ДД>В Си sizeof(char) = 1. А вот 'c' является не char, а int.

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

Здравствуйте, sysenter, Вы писали:

S>Ага, щас, в Си sizeof(char) = 4, в С++ sizeof(char) = 1.

Ещё раз перечитал, вообще согласен, претензии обоснованы.
Ступил, он там пишет про размер типа char, а не про размер символа. Кидайте в меня камни благородные доны.

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Wissenschaftler, Вы писали:

W>>А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.

E__>Еще — Си просто проще. Я не сишник, и последний раз писал на Си(++) в институте лабы. Я жавист, с 3-го курса пишу на жабе. Но недавно проект на Си сделал без проблем(был единственный фейл — я забыл, что char в си однобайтный, но решилось быстро), причем проект под девайс с 64К памяти и прочими незавидными характеристиками(проц медленный, видно отображение символов на текстовом экране). На плюсах я бы задолбался. А так — несколько простых правил: выделяем все на стеке(памяти и так мало, с кучей заморачиваться нет смысла), не возвращаем локальные переменные и... Да и все, по сути. Разве что работа со строками немного парит(ну, после высокоуровневых языков, а либы не сильно поподключаешь в такой проект, ограничение на размер бинарника 90 килобайт), но все решаемо. А плюсовика на небольшой проект нанимать было бы дорого и бессмысленно.
На небольшой проект а-ля "сделал и забыл" — да. Если планируется разрабатывать хотя бы пару месяцев, а потом поддерживать, "инвестиции времени" окупятся влегкую.

Здравствуйте, sysenter, Вы писали:

N>>Или Вы имеете в виду под sizeof что-то своё нестандартное, или сильно ошибаетесь.

S>Eugeny__ говорит, что символы якобы в Си однобитные, что не соответствует действительности.
S>Вот проверь sizeof('a');

Не гони, символы в С полубитные

Здравствуйте, Brutalix, Вы писали:

B>Но вообще, мой жизненный опыт мне подсказывает, что хвалят С и ругают С++ те, кто С выучил, а С++ не осилил. Те кто могёт и на том и на другом, обычно в бутылку не лезут.

Тут есть одно "но": С++ и С — два разных языка с похожим синтаксисом.
Флейм вида "С(++) — говно!" возникает, как правило, после того, как человек всласть потрахается с проектом, думая, что "Си — это такой С++ без классов", или "С++ — это просто расширенный Си". Авотфиг — это другой язык, и его таки надо целенаправленно осваивать.
Примеры у меня перед глазами бывали неоднократно.
После разъяснительной работы и тыканья носом в учебники, как правило, отношение к языку менялось. Клинические случаи тоже бывали, что только подтверждает.

Здравствуйте, 4UBAKA, Вы писали:

UBA>Здравствуйте, sysenter, Вы писали:

N>>>Или Вы имеете в виду под sizeof что-то своё нестандартное, или сильно ошибаетесь.

S>>Eugeny__ говорит, что символы якобы в Си однобитные, что не соответствует действительности.
S>>Вот проверь sizeof('a');

UBA>Не гони, символы в С полубитные ;) :shuffle:

Отстаёте... в Сколково их уже на нанобиты режут

Здравствуйте, Deprivator, Вы писали:

D>Здравствуйте, sysenter, Вы писали:

S>>Ага, щас, в Си sizeof(char) = 4,

D>Боже, это ж где такая трава растет??

эта трава из M$
там ввели свой тип UCHAR который определен как unsigned int
сделано это видимо для оптимизации
из расчета на то что
читать байт с памяти расширяя его до int, это накладнее
чем читать сразу int из памяти считая что это байт

Здравствуйте, Brutalix, Вы писали:
КБ>>Кто что думает по этому поводу?
B>Но вообще, мой жизненный опыт мне подсказывает, что хвалят С и ругают С++ те, кто С выучил, а С++ не осилил. Те кто могёт и на том и на другом, обычно в бутылку не лезут.

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

для voyager-ов систему контроля сбоев писали на лиспе
http://www.flownet.com/gat/jpl-lisp.html

Здравствуйте, chemey, Вы писали:
C>Тут есть одно "но": С++ и С — два разных языка с похожим синтаксисом.
...
C>Авотфиг — это другой язык, и его таки надо целенаправленно осваивать.

Я не пишу ни на С ни на С++. Чем они отличаются? В каком месте отличия?

C>Примеры у меня перед глазами бывали неоднократно.

очень бы хотелось увидеть.

Здравствуйте, sysenter, Вы писали:

S>>>Ага, щас, в Си sizeof(char) = 4,
D>>Боже, это ж где такая трава растет??

S>Разъяснение специально для тупых,

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

S> Eugeny__ говорит, что якобы в Си размер символа 1 байт

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

S>соответсвенно исходя из контекста я привёл размер не типа дынных char, а размер символа который в английском языке обозначается словом — char.

тем не менее вы написали:

sizeof(char) = 4

что есть чушь неимоверная.

и даже с этими пояснениями, размер char — ОДИН байт, хоть ты тресни.
ибо как путаете численное значение символа (int) и собственно символ, размер которого 1.

S>В Си sizeof('a') = 4

это sizeof(int)

Кстати, упорное использование оператора присваивания вместо равенства тоже свидетельствует о вашем уровне.

Здравствуйте, chemey, Вы писали:

C>Тут есть одно "но": С++ и С — два разных языка с похожим синтаксисом.
C>Флейм вида "С(++) — говно!" возникает, как правило, после того, как человек всласть потрахается с проектом, думая, что "Си — это такой С++ без классов", или "С++ — это просто расширенный Си". Авотфиг — это другой язык, и его таки надо целенаправленно осваивать.

Я шел по пути электроника -> асм -> С -> С++ (сейчас еще и C#). На С писал долго.
Если взять С программу, заменить расширение файлов на .cpp и сделать минимальную косметическую правку, то получится рабочая С++ программа. так что с Вашим утверждением не согласен.

Другое дело, что на С++ можно писать в разных стилях. Когда я на него только перешел, я фактически писал как на С, используя от плюсов только три вещи: 1) возможность обьявлять переменные по ходу и в частности внутри for 2) деструкторы в классах, т.е. я мог например сделать класс CBuffer и не беспокоится, что память будет освобождена на выходе из ф-ции 3) человеческие строки. Язык без строк (С) — это ведь реально извращение и полный маразм.

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

Сказать честно, не понимаю неприятия C++ для low level задач. ну да, есть нюансы, например, с икслючениями, но в целом — не понимаю.
В крайнем случае можно было бы сделать какой-нить С++--

— с++ с ограничениями, это по-любому намного лучше чем чистый C.

Здравствуйте, netch80, Вы писали:

N>Ряд факторов, которые для обычного прикладного софта имеют малое значение, принципиальны для ядра. И именно эти факторы являются слабоуправляемыми или вообще неуправляемыми при написании на C++. В их число входит, например, объём сгенерированного кода (в основном того, что из шаблонов), детали реализации структур данных в STL и аналогах. Невозможно без существенных потерь исключить обработку исключений и поддержку RTTI.
Для Windows в ядре можно использовать и аналог STL, и даже исключения...

N>Если бы существовала промышленная поддержка промежуточного между C и современным C++ языка, который имеет классы и инкапсуляцию, наследование (можно без множественного) и виртуальные методы, пространства имён (то есть приблизительно равно так называемой C++ версии 1.5, по нумерации Страуса и cfront) — то это был бы отличный язык для ядра. Но C++ пошёл дальше и стал слабо пригодным к этому.
Есть ядра, написанные на С++: Haiku, L4, и т.д.

N>Если попытаться включить STL, то потребовался бы отдельный безумный пласт работы по её адаптации не на общепринятые в userland методы межзадачной синхронизации типа мьютексов, а на те, что в современном ядре, начиная с RCU и продолжая вплоть до спинлоков.
Какие проблемы с STL-то? Контейнеры STL я самолично в ядре использовал в C++-ном модуле. Всё что там нужно — это аллокаторы поменять и примитивы синхронизации.

Структуры с RCU — это вообще отдельная история, для них надо свои либы писать, тут STL никоим боком не относится.

Здравствуйте, disasm, Вы писали:

D>>Боже, это ж где такая трава растет??
D>эта трава из M$
D>там ввели свой тип UCHAR который определен как unsigned int
D>сделано это видимо для оптимизации
Нет, сделано это для прямого представления Unicode-символов (на что слегка намекает префикс 'U'). В gcc на Линуксе sizeof(wchar_t)==4, аналогично.

Хм...
Я думал будет обсуждение новой Linus Visual Studio С++

D>>эта трава из M$
D>>там ввели свой тип UCHAR который определен как unsigned int
C>Нет, сделано это для прямого представления Unicode-символов (на что слегка намекает префикс 'U').

гм, гм, даже интересно стало, поискал, мсдн:

A UCHAR is an 8-bit integer with the range: 0 through 255 decimal. Because a UCHAR is unsigned, its first bit (Most Significant Bit (MSB)) is not reserved for signing.

This type is declared as follows:
typedef unsigned char UCHAR, *PUCHAR;

кончайте прятать траву, делитесь

Здравствуйте, Deprivator, Вы писали:

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

За такие дела надо отрывать первичные половые признаки

D>Сказать честно, не понимаю неприятия C++ для low level задач. ну да, есть нюансы, например, с икслючениями, но в целом — не понимаю.

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

M>Mike Williams, один из создателей Erlang'а: «C++ и Java не нужны»

Си тоже.

Здравствуйте, Brutalix, Вы писали:

D>>Другое дело, что на С++ можно писать в разных стилях. Когда я на него только перешел, я фактически писал как на С
B>За такие дела надо отрывать первичные половые признаки

D>>Сказать честно, не понимаю неприятия C++ для low level задач. ну да, есть нюансы, например, с икслючениями, но в целом — не понимаю.
B>это просто. нюансы надо если не понять, то хотя бы выучить. Если же сравнивать Си и Си++ в стиле Си с классами, то Си рвет "Си с классами" как тузик грелку.

бррр.... ну и в каком месте Си "рвет как тузик грелку" язык с _точно_ такими же возможностями ПЛЮС ряд дополнительных?
а вот обратное утверждение верно.
возможность использовать нормальные строки, обьявлять переменные где хочешь, классы (пусть даже в самом простом примитивном виде) и контейнеры дает огромное преимущество, после которого чистый С забывается как ночной кошмар на утро.

M>>Mike Williams, один из создателей Erlang'а: «C++ и Java не нужны»

dmz>Си тоже.

Ну, по его словам:
— близко к железу: ассемблер
— realtime: C
— скриптинг: Perl, Python...
— приложения: OCaml, Haskell, Erlang...

Для C++/Java места нет

Здравствуйте, Mamut, Вы писали:

M>>>Mike Williams, один из создателей Erlang'а: «C++ и Java не нужны»

dmz>>Си тоже.

M>Ну, по его словам:
M>- близко к железу: ассемблер
M>- realtime: C
M>- скриптинг: Perl, Python...
M>- приложения: OCaml, Haskell, Erlang...
С тем же успехом можно написать
— realtime: C++
— приложения: C++/Java...
Для Си, OCaml, Haskell, Erlang места нет

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Wissenschaftler, Вы писали:

W>>А самая частая причина, по которой низкоуровневые вещи пищут на Си "in industry" — сишники дешевле плюсников того же уровня. Все дела.

E__>Еще — Си просто проще. Я не сишник, и последний раз писал на Си(++) в институте лабы. Я жавист, с 3-го курса пишу на жабе. Но недавно проект на Си сделал без проблем(был единственный фейл — я забыл, что char в си однобайтный, но решилось быстро), причем проект под девайс с 64К памяти и прочими незавидными характеристиками(проц медленный, видно отображение символов на текстовом экране). На плюсах я бы задолбался. А так — несколько простых правил: выделяем все на стеке(памяти и так мало, с кучей заморачиваться нет смысла), не возвращаем локальные переменные и... Да и все, по сути. Разве что работа со строками немного парит(ну, после высокоуровневых языков, а либы не сильно поподключаешь в такой проект, ограничение на размер бинарника 90 килобайт), но все решаемо. А плюсовика на небольшой проект нанимать было бы дорого и бессмысленно.

И что же ты там такое эзотерическое использовал, что оно может быть только Си и не скомпилится плюсовым компилятором?

ЗЫ Это я к тому, что С++ изначально разрабатывался как надмножество Си, т.е. чтоб можно было взять сишный код и посыпать его сверху классами/шаблонами/перегрузками/RAII, и все будет работать. Ну или, перефразируя, можно было писать в стиле Си и чтоб все работало, при необходимости пользуясь плюсовыми рулезами. Почему вдруг "На плюсах я бы задолбался", не понимаю.

Здравствуйте, jazzer, Вы писали:

J>И что же ты там такое эзотерическое использовал, что оно может быть только Си и не скомпилится плюсовым компилятором?

Я думаю, имелось в виду, что в случае C++ надо и писать на его родных средствах, а не на средствах C.
А в таком случае разница уже очень существенна.

Здравствуйте, Mamut, Вы писали:

M>>>Mike Williams, один из создателей Erlang'а: «C++ и Java не нужны»

dmz>>Си тоже.

M>Ну, по его словам:
M>- близко к железу: ассемблер
M>- realtime: C
M>- скриптинг: Perl, Python...
M>- приложения: OCaml, Haskell, Erlang...

M>Для C++/Java места нет :)

Для C++ я бы ещё частично согласился — стиль с использованием бутерброда из разных языков для разных задач обычно не хуже, чем стиль использования одного бутербродного языка (хотя MS с этим, похоже, не согласится;))
А вот возражения против Java, приводящие в отместку к использованию или функциональных языков, или скриптовых, уже (к сожалению или к счастью) адекватными не будут.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, jazzer, Вы писали:

J>>И что же ты там такое эзотерическое использовал, что оно может быть только Си и не скомпилится плюсовым компилятором?

N>Я думаю, имелось в виду, что в случае C++ надо и писать на его родных средствах, а не на средствах C.
N>А в таком случае разница уже очень существенна.

Ну тут вот сказали рядом, что писали как на Си, но с использованием RAII, объявлением переменных в любом месте и прочих простых плюсовых вещей типа перегрузки функций и параметров по умолчанию — почему нет? Программа остается простой, хоть и плюсовой, все очень легко понять и отследить, и при этом нет половины связанного с чистым Си геморроя.

Угу. И половину времени разработки трахаемся с организацией межъязыкового интеропа.

Здравствуйте, jazzer, Вы писали:

J> Это я к тому, что С++ изначально разрабатывался как надмножество Си, т.е. чтоб можно было взять сишный код и посыпать его сверху классами/шаблонами/перегрузками/RAII, и все будет работать. Ну или, перефразируя, можно было писать в стиле Си и чтоб все работало, при необходимости пользуясь плюсовыми рулезами. Почему вдруг "На плюсах я бы задолбался", не понимаю.

Соблазн всё равно был бы, а там то одно то другое, то зачем нам этот ужасный голый char*

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

Именно поэтому я очень часто сознательно пишу не "в стиле С", а конкретно -- на С. Жалею тех, кто придёт за мной читать.

Здравствуйте, Eugeny__, Вы писали:

E__>Еще — Си просто проще. Я не сишник, и последний раз писал на Си(++) в институте лабы. Я жавист, с 3-го курса пишу на жабе. Но недавно проект на Си сделал без проблем(был единственный фейл — я забыл, что char в си однобайтный, но решилось быстро), причем проект под девайс с 64К памяти и прочими незавидными характеристиками(проц медленный, видно отображение символов на текстовом экране). На плюсах я бы задолбался.
E__> А так — несколько простых правил: выделяем все на стеке(памяти и так мало, с кучей заморачиваться нет смысла), не возвращаем локальные переменные и... Да и все, по сути. Разве что работа со строками немного парит(ну, после высокоуровневых языков, а либы не сильно поподключаешь в такой проект, ограничение на размер бинарника 90 килобайт), но все решаемо.
У вас в голове больки!!!
Что вам мешало точно так же написать на С++?
Или если С++ то надо обязательно наццатиэтажные шаблоны городить и туеву хучу хитрожопо наследованных классов с "виртуальными деструкторами" (тм) ?
Откуда вот это вот убеждение?
Бери С++, пиши на нём так, как писал бы на plain С, но там где реально надо — юзай расширенные возможности.