forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Дискуссия об использовании языка C++ для разработки ядра Linux, opennews (??), 14-Янв-24, (0) [смотреть все]

Пока с не осилит инициализацию структур, говорить о переносе кода безполезно, , _kp (ok), 23:42 , 14-Янв-24, (62) –24 //

О чем речь С может инициализировать структуры, Аноним (75), 00:03 , 15-Янв-24, (75) +2
struct A int a int b A a1 1, 2 работает в C 20 может и в более ранних , Аноним (75), 00:07 , 15-Янв-24, (78) +1 //

a1 1, 2 Вот не надо подобного Когда полей в структуре не один десяток, получи, _kp (ok), 11:30 , 15-Янв-24, (244) –1 //

И хотя это правда, стоит добавить когда в структуре столько полей - мы знаем чт, Аноним (-), 13:43 , 16-Янв-24, (513) +2

Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а , Аноним (525), 14:32 , 16-Янв-24, (525) +1

Вообще-то сделают данные более структурированные - и - вот - менее подверженными, Аноним (-), 18:18 , 19-Янв-24, (644) +1

Что значит мы Это задачи такие И не все делается в одиночку Что требуется для, _kp (ok), 20:06 , 16-Янв-24, (578)

Ну да, вы такие особенные на всю планету, наверное Значит общее управление проек, Аноним (-), 18:33 , 19-Янв-24, (645) +1

Эй, это даже в си работает Вы там что-то совсем тормоз не отпустили Черт, даже, Аноним (-), 00:42 , 15-Янв-24, (90) +1 //

В смысле, даже В плюсах эта фича полноценно появилась только в C 20, когда к, Аноним (115), 02:23 , 15-Янв-24, (115) +5
code a x 1, y 2 code Вот такой синтаксис завезли только в 20е плюсц, Аноним (149), 03:49 , 15-Янв-24, (149) +1 //

Ага А если не в исходнике было не x 1, y 2, , а в другом порядке , _kp (ok), 11:24 , 15-Янв-24, (240)

Все правильно, ибо нефиг создавать ложное впечатление, есть же строгий порядок и, ДаНуНафиг (?), 18:23 , 15-Янв-24, (363) +3

Если сам с нуля пишешь то обычно да, логичнее писать по порядку, но бывает испол, _kp (ok), 02:21 , 16-Янв-24, (469)

Все это прекрасно выделяется блоками комментариев Не могу представить ситуации , ДаНуНафиг (?), 16:38 , 19-Янв-24, (643)

Да это ж это же костылизм Впрочем, сейчас оно уже в прошлом Да легко Перестави, _kp (ok), 18:34 , 19-Янв-24, (646)

Ничего не понял про собирающего Если у него были старые исходники, то у него вс, ДаНуНафиг (?), 07:41 , 21-Янв-24, (672)

Я сейчас почти не пишу драйверы, но когда то писал Сейчас в основном под встраи, _kp (ok), 11:55 , 15-Янв-24, (249) +3 //

На самом деле очень зависит от И может являть собой и memset или memcpy в опред, Аноним (-), 14:35 , 15-Янв-24, (305) +1

Вы предлагаете в структуры напихать методов на все случаи Только описывать их п, _kp (ok), 11:37 , 16-Янв-24, (505)

В С и С нет методов, не было никогда и не будет -- есть функции-члены , adolfus (ok), 20:24 , 16-Янв-24, (581)
Я лишь констатировал что на си можно делать весьма по разному - в том числе даже, Аноним (-), 04:04 , 17-Янв-24, (599)

А можно пример, чтобы это было так не только с -O0 Зачем компилятору вызывать к, Аноним (341), 16:29 , 15-Янв-24, (341) +1

А, методы, определённые в теле класса, неявно помечены как inline Если определе, Аноним (341), 20:20 , 16-Янв-24, (580)

Пейсатель, CPP - это C PreProcessor, CXX - для плюсов , pavlinux (ok), 17:21 , 15-Янв-24, (352) +1
Про 0 тактов - constexpr ctor , ДаНуНафиг (?), 18:29 , 15-Янв-24, (367)

consteval, Аноним (115), 18:45 , 15-Янв-24, (373)
1 Да, я это использую Но не так и редко бывает на ровном месте и constexpr vari, _kp (ok), 02:31 , 16-Янв-24, (471)

На сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 та, Аноним (-), 02:47 , 16-Янв-24, (474)

constexpr и задумано для этого Не спорю Но где то не применимо Хотя в большинс, _kp (ok), 10:13 , 16-Янв-24, (492)

Как бы плюсы мощнее сей Но если повыпендриваться - то си можно основательно пер, Аноним (-), 04:09 , 17-Янв-24, (600)

Красивее - нет, но оно и не всегда нужно, а когда и вовсе нужно убирать , ДаНуНафиг (?), 16:29 , 19-Янв-24, (642)

А что плохого в extern C Очень часто используется , InuYasha (??), 00:03 , 16-Янв-24, (450)
это не совсем так placement new в C может инициализировать объекты по адресу , анон (?), 16:27 , 16-Янв-24, (554) +1

Благодарю Жаль что с constexpr оно только с c 20 только, а то в embedded в ход, _kp (ok), 20:19 , 16-Янв-24, (579)

Есть же знатоки , Аноним (236), 11:16 , 15-Янв-24, (236) //

А что не так Если ни какими опциями компилятора нельзя избежать правки рабочего, _kp (ok), 11:26 , 15-Янв-24, (241) //

Строго говоря разница усматривается Сизифов труд это бесконечное наказание, мар, Котофалк (?), 15:30 , 15-Янв-24, (325) +1

С поддерживает 25 способов инициализации, и это уже само по себе проблема , leap42 (ok), 12:57 , 15-Янв-24, (270) +2 //

В 20 сишную fild_name 100 запилили , Аноним (293), 13:52 , 15-Янв-24, (293)

Нельзя туда цпп Ладно модули, только не ядро Запаримся пересобирать же Си соб, Аноним (1), 21:43 , 14-Янв-24, (1) –17 //

Там жалобы есть в том числе на макросы А они вполне себе могут компилиться доль, oficsu (ok), 21:46 , 14-Янв-24, (2) //

ШТО Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой Это ша, Аноним (18), 22:08 , 14-Янв-24, (18) +3 //

Но остаётся совсем чуть-чуть до этого https github com Hirrolot metalang99http, funny.falcon (?), 23:20 , 14-Янв-24, (52) +3

А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит р, Аноним (-), 23:41 , 14-Янв-24, (61) +4

Они ну вот буквально на грани Единственный лимит - рекурсия до 128, чтоли, у, Аноним (-), 23:32 , 14-Янв-24, (56) –1
Да, можно Но это рассуждение об экстремальных примерах Но экстремальные пример, oficsu (ok), 23:48 , 14-Янв-24, (69) –1

Тормозящие шаблоны целиком типичная ситуация в 100 проектов Программы на этом , Аноним (214), 10:28 , 15-Янв-24, (214) +2

Шаблоны это compile time Ну и хрен с ними, сколько им компиляться Главное, что, Аноним (293), 20:31 , 15-Янв-24, (408) +1

А ещё макросы не анализируются также хорошо как шаблоны через статический анализ, Bottle (?), 22:29 , 14-Янв-24, (30) +1

Так пусть определятся для начала Если rust можно, то почему плюсы нельзя , Аноним (4), 21:47 , 14-Янв-24, (4) +5 //

А кто сказал, что раст можно Пока что раст -- это для модулей, которые с ваниль, _hide_ (ok), 22:36 , 14-Янв-24, (32) +1 //

Это сказал Линус в интервью, что ожидается большее использование в базовых компо, Витюшка (?), 23:18 , 14-Янв-24, (51) +1

Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет, Аноним (107), 02:09 , 15-Янв-24, (107)

Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследова, Герман (??), 10:07 , 15-Янв-24, (204) +1 //

Какие тебе гарантии нужны Средства в плюсах давно есть А если у тебя генетичес, Аноним (252), 12:21 , 15-Янв-24, (252)

Средства, использования которых необязательны Было бы в плюсах все хорошо с без, Герман (??), 12:42 , 15-Янв-24, (255) +2

Давайте полюбуемся на простые _Generic-макросы в ядре И вообще на макросы https, Аноним (341), 16:51 , 15-Янв-24, (347) +2

А сколько там модулей в стандартной библиотеке, которые меняются из версии в вер, Аноним (6), 21:50 , 14-Янв-24, (6)
Даже в Gentoo завезли бинарное ядро , Аноним (7), 21:50 , 14-Янв-24, (7) +1 //

Для истинных гентушков это ничкго не изменило , Аноним (36), 22:43 , 14-Янв-24, (36) //

Как будто только гента позволяет ядро пересобрать В Void это делается ровно точ, Аноним (105), 02:02 , 15-Янв-24, (105)

Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах Неиспол, Аноним (452), 00:06 , 16-Янв-24, (452) +2

Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно соб, Аноним (115), 13:49 , 16-Янв-24, (517)

Yolo Я майнлайне кернель под дебианом собираю В билдсистеме ядра даже есть ген, Аноним (-), 04:16 , 17-Янв-24, (601)

Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля Сложно, Аноним (623), 16:35 , 17-Янв-24, (623)

ИМХО где как На десктопе я от дистровского конифига танцевал, таргетируя более-, Аноним (-), 18:46 , 19-Янв-24, (647)

Так разговоры давно идут об введений подмножеств - урезанной современной версии , maximnik0 (?), 21:51 , 14-Янв-24, (8) –1 //

Так то g заметно тормознее gcc потому что C куда как более фичастый язык , Аноним (-), 23:43 , 14-Янв-24, (63) //

И чё Когда сам GCC c версии 4 8 тоже начал постепенный переход на C , тоже ныл, Аноним (452), 00:13 , 16-Янв-24, (458) +2

А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощ, Аноним (-), 02:52 , 16-Янв-24, (475) +1

Это в прошлом было такое А сейчас что скорость компиляции примерно одинакова, , _kp (ok), 21:47 , 16-Янв-24, (583)

Угу, конечно Запускаем допустим libaom компилиться И чего-то сишная часть тика, Аноним (-), 04:30 , 17-Янв-24, (603)

Если например пересборка компилятора esp32s3 и системы сборки сократила время сб, _kp (ok), 12:26 , 17-Янв-24, (615)

Я ESP не использую, и врядли буду когда либо Так что это знание может и будет п, Аноним (-), 16:53 , 21-Янв-24, (673)

Как нас унесло Изначальный смысл был скормить си исходники компилятору с , а н, _kp (ok), 19:21 , 21-Янв-24, (674)

Вот те раз А я то думал изначальный смысл - оценить технологию, по возможности , Аноним (-), 20:34 , 21-Янв-24, (675)

А зачем вы его постоянно пересобираете , Аноним (20), 22:12 , 14-Янв-24, (20) +4 //

2 6 32 работает - не трожь , Аноним (36), 22:46 , 14-Янв-24, (40) +3
Потому что оно багованное Проверяем, есть ли баги в новых версиях , anonymous (??), 23:39 , 14-Янв-24, (60) //

Так это ж надо желать один раз, когда хочется попробовать новую версию А один р, Аноним (20), 01:49 , 15-Янв-24, (104) +1

Потому что его постоянно правят Вот бы заморозили его разработку, да Тогда мож, Аноним (77), 00:06 , 15-Янв-24, (77)
https bellard org tcc tccboot htmlа ведь когда-то можно было и так, игрушечным, pv (?), 13:23 , 15-Янв-24, (277) +1

опять огульные выдуми кро скорость сборки когда же вы успокоитесь, выдумщики, Аноним (27), 22:27 , 14-Янв-24, (27) +2
А что вы про Rust запоёте , Аноним (36), 22:40 , 14-Янв-24, (34) +1 //

Судя по комментариям, большинство из тех, кто поет на OpenNET про Rust разбира, Проходил мимо (?), 08:00 , 15-Янв-24, (179) +2

Шёл 2024 год , Аноним (3), 21:46 , 14-Янв-24, (3) –11 //

П с Так там ещё и 80 символов ограничение 129318 8205 9792 65039 , Аноним (3), 21:47 , 14-Янв-24, (5) –5 //

https lkml org lkml 2020 5 31 326, Аноним (9), 21:53 , 14-Янв-24, (9) +5
Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменял, Аноним (115), 23:57 , 14-Янв-24, (72) –3 //

А лучше трем символам Или может восьми, видел и такое , Аноним (107), 02:37 , 15-Янв-24, (118)

В ядре как раз-таки 8, Аноним (296), 14:03 , 15-Янв-24, (296) +1

стирает исходники ядра пры линукса фу , InuYasha (??), 00:04 , 16-Янв-24, (451)

Яваскриптеры голосуют за два пробела В общем, после окончания споров табы пробе, Аноним (313), 14:58 , 15-Янв-24, (313)

Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, сле, Аноним (293), 13:49 , 15-Янв-24, (291) +1

Не лучше Таб 1 байт, пробелы 1 байта , rmh (?), 14:34 , 15-Янв-24, (304) +2

И что , n00by (ok), 14:11 , 16-Янв-24, (521)

Ложь Едет, если в редакторе настроена замена пробелов табуляциями То есть от н, Аноним (313), 14:52 , 15-Янв-24, (311) –2

едет, если умственно-ограниченные начинают использовать табуляцию не для инденти, Аноним (391), 19:14 , 15-Янв-24, (391) +1

Фанаты пробелов - это потомки тех, кто в 90-х в офисе вместо настройки первой ст, Аноним (313), 21:29 , 15-Янв-24, (420) +2

Вы бредите Табуляция - это табуляция, ОДИН символ Что значит равной 4 символа, Аноним (313), 15:01 , 15-Янв-24, (315)

TAB это терминальный опкод, а не символ Ровно как и все ASCII символы до 0x20 н, Аноним (115), 15:17 , 15-Янв-24, (321) +2

Ну пусть будет 1 оп код вместо четырёх есть же разница , VladSh (?), 18:50 , 15-Янв-24, (376) +1

когда я в подном большом проекте заменил все отступы на табы вместо 4 пробелов , InuYasha (??), 00:07 , 16-Янв-24, (453)

А еще на несколько мегов меньше читать и парсить компилеру whitespaces до лампо, Аноним (-), 02:55 , 16-Янв-24, (477)
Производительность взлетела до небес, наверное , Аноним (482), 06:37 , 16-Янв-24, (482) +1

Что такой тугой, TAB равен изначально 8-и символам и это неудобно Что породило , Аноним (115), 13:53 , 16-Янв-24, (520)

Ещё раз, специально для вас Форматирование при использовании табов едет только у, Аноним (525), 14:56 , 16-Янв-24, (531) +1

Какой и ты тугой Форматирование в общем случае едет всё равно потому что TABы к, Аноним (115), 17:52 , 16-Янв-24, (565)

Типичный, кстати, пример, где всё это едет, как раз линуксовое ядро, которое пиш, Аноним (115), 17:55 , 16-Янв-24, (566)

Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с , _kp (ok), 22:00 , 16-Янв-24, (584)

На печатных машинках чужие исходники не отображали так что там проблема с тем чт, Капитан О. (?), 20:37 , 21-Янв-24, (676)

TAB - был не символом, а кодом движения печатающей головки или руки оператора По, _kp (ok), 18:23 , 22-Янв-24, (681)

Да вообще тупые Пора уже на слак перейти, или накрайняк на дискорд Я уже уст, nich (ok), 21:58 , 14-Янв-24, (10) //

Лучше в твиттер или как она там называется теперь , Вы забыли заполнить поле Name (?), 03:14 , 15-Янв-24, (137) +4

и до сих пор не придумали ничего лучше, чем форум Даже в виде рассылки , Аноним (16), 22:05 , 14-Янв-24, (16)
Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки, Аноним (107), 02:12 , 15-Янв-24, (109) +4
О, кто-то календарь перевернул , Тот_Самый_Анонимус_ (?), 05:36 , 15-Янв-24, (160) –1

Это он ещё очень дипломатично выразился относительно этого нагромождения сокраще, Аноним (11), 21:59 , 14-Янв-24, (11) +3 //

А какая тебе разница, какие там спецсимволы Тебе алгоритмы писать, а не буковки, Аноним (81), 00:13 , 15-Янв-24, (81) –5 //

Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода , Витюшка (?), 01:35 , 15-Янв-24, (100) +8 //

Нет Код должен реализовывать алгоритм, который описан обычным человеческим язык, Аноним (573), 18:57 , 16-Янв-24, (573)

Это верно, но есть нюанс Идея самодокументированного кода позволяет автору со, n00by (ok), 19:09 , 16-Янв-24, (575)

В каком месте GPL лишает кого-то имущественных прав Цитату , Аноним (-), 18:50 , 19-Янв-24, (648)

В месте замены право на лево copyleft , n00by (ok), 08:36 , 20-Янв-24, (659)

Скрыто модератором, Аноним (-), 11:26 , 20-Янв-24, (661)

Скрыто модератором, n00by (ok), 15:36 , 20-Янв-24, (669)

Код гораздо чаше нужно читать, чем писать Поэтому, чем удобнее его читать, тем , Аноним (170), 07:22 , 15-Янв-24, (170) +3 //

с этим тоже можно поспорить, т к на читиаемость влияет и количество строк и got, Советский инженер (ok), 09:55 , 15-Янв-24, (197)

В С есть большая проблема -- ссылки в перечне параметров функции Это препятст, adolfus (ok), 20:33 , 16-Янв-24, (582)

Что касается обычных непричин , нон-секвитуров и прочих нерелевантных доводов, , Аноним (609), 08:27 , 17-Янв-24, (609)

Ну так пройдитесь просто по двумерному массиву Когда-нибудь изображения обрабат, adolfus (ok), 12:04 , 17-Янв-24, (614)

Cache-friendly программирование Не, не слышали И продолжили выходить из влож, Аноним (609), 08:32 , 17-Янв-24, (610)

Каше-френдли программирование начинается прежде всего с безальтернативного исп, adolfus (ok), 12:34 , 17-Янв-24, (616)

Предсказание и предвыборка команд работают для call ret начиная с NetBurst и дл, n00by (ok), 14:45 , 17-Янв-24, (622)

И Rust и C более выразительные языки чем C, и именно поэтому код на них горазд, warlock66613 (ok), 19:53 , 15-Янв-24, (397)

Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понима, _kp (ok), 22:07 , 16-Янв-24, (585)
Несмотря на то, что я топлю за C , не могу не придраться, что C ОЧЕНЬ опасен , wyry (?), 18:20 , 18-Янв-24, (635)

Ну и че ты не переписал еще все ядро на brainfuck , scriptkiddis (?), 10:01 , 16-Янв-24, (490)

Так сокращения это норма для линукса cp, mv, dd, rm, ls, df, du, pz, Аноним (248), 11:47 , 15-Янв-24, (248) +4 //

Это объясняется легаси , Аноним (258), 12:45 , 15-Янв-24, (258) //

Могу назвать ещё минимум две причины, по которымls -lЛучше, чемlist-files-and-di, Аноним (313), 15:05 , 15-Янв-24, (316) +2

Вы только что рассказали почему powershell - ацтой каких мало Ах да, автодополн, Аноним (-), 18:59 , 15-Янв-24, (382) +2

Наоборот же, powershell показывает, что можно всем угодить изкоробочными алиасам, Аноним (341), 19:24 , 15-Янв-24, (393) +1

Он мне так угАдил своим синтаксисом, километровыми командами и очешуенным времен, Аноним (446), 23:57 , 15-Янв-24, (446)

Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна , Аноним (341), 02:54 , 16-Янв-24, (476) +1

В результате самое крутое что есть в шелле ака мелкая автоматизация системной ру, Аноним (-), 03:04 , 16-Янв-24, (479)

Тебя опять что-ли шиза долбает, 294й То что по умолчанию идёт с PSReadLine ты о, Аноним (546), 15:53 , 16-Янв-24, (546)

Ну во первых я вобью проблему в поискарь и скопипащу 90 решения Во вторых я не, Аноним (-), 19:03 , 19-Янв-24, (649)

У тебя как 294й, с способностью понимать тексты Проблема Скопипасть в поискарь , Аноним (684), 19:00 , 23-Янв-24, (684)
Меня от шелла интересует 2 сценария oneliner руками на 1 раз, here and now Л, Аноним (-), 21:48 , 23-Янв-24, (685)
Резюмируя два Инфоцыган 294й забыл сам с чего начал автодополнения нет, коротких, Аноним (690), 06:18 , 24-Янв-24, (690)

А когда пишешь скрипт в любимом редакторе, то никакого автодополнения для этого, _kp (ok), 22:10 , 16-Янв-24, (586)

Это объясняется тем, что всё это нужно постоянно набирать Что касательно rust, , Аноним (115), 15:23 , 15-Янв-24, (322)

То-то наверно лучше в C когда звёздочка обозначает сразу 4 разных операции А , fuggy (ok), 23:35 , 15-Янв-24, (439)

Или это значит мои старческие мозги скатываются в деменцию, новых символов отли, Аноним (-), 20:25 , 15-Янв-24, (406) –1 //

Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а, Аноним (499), 11:14 , 16-Янв-24, (499) +2
Это значит лишь то, что Линус, будучи взрослым человеком, способен определить чт, Аноним (573), 19:03 , 16-Янв-24, (574) //

Линуса просто уже ранее настойчиво попросили быть повежливее Странно что еще ни, Stellarwind (?), 15:39 , 25-Янв-24, (691)

На это я отвечал в 211И на это тоже Правда, не на цитату Линуса, а на изложенн, n00by (ok), 17:02 , 25-Янв-24, (692) –1

Легендарная битва Интересно чем закончится Но сразу и Rust и C одновременно , Витюшка (?), 21:59 , 14-Янв-24, (12) +7 //

У C сейчас второе, или даже третье дыхание По моим личным ощущениям Но за Rus, Витюшка (?), 22:05 , 14-Янв-24, (15) +2 //

Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал , Аноним (11), 22:12 , 14-Янв-24, (21) +2
По моим, наверное, второе дыхание было с C 0x C 1y А вот уже с C 1z C 2a и , jjklh (?), 22:28 , 14-Янв-24, (29) +3
Как там у него с портабельностью и вообще готовностью к проду Вот представьте ч, Аноним (-), 23:47 , 14-Янв-24, (67) +2 //

К сожалению, нет Я и говорю что некому топить за него Топить - не только в расс, Витюшка (?), 01:37 , 15-Янв-24, (101)

Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хру, Аноним (-), 19:03 , 15-Янв-24, (385)

В основном языки имеют одну реализацию С в этом плане является прям крайним и, Витюшка (?), 22:01 , 15-Янв-24, (423) +1

гарантирующую 100 вендорлок, что после си и си как бы нефиговый регресс, е, Аноним (446), 23:47 , 15-Янв-24, (442) –1

Почему Они насмотрелись на rust и другие языки и начали стандартизовывать нужны, Вы забыли заполнить поле Name (?), 03:05 , 15-Янв-24, (135) +1 //

Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-ч, Аноним (175), 07:45 , 15-Янв-24, (175)

Пару ножек , Аноним (313), 15:07 , 15-Янв-24, (317) +4

А в rust что-то вообще СТАНДАРТИЗОВАНО У него ж ни единой версии стандарта нет, Аноним (-), 19:06 , 15-Янв-24, (387) +3

типа на стандартном С можно ядро написать вот умора, язык разработан для написа, Советский инженер (ok), 19:35 , 15-Янв-24, (395)

Ну, почти Режим freestanding официально специфицирован с C99 аж Там правда пар, Аноним (446), 23:50 , 15-Янв-24, (445) +1

дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что, Советский инженер (ok), 11:20 , 16-Янв-24, (500)

Хрустики даже и так не смогли Все познается в сравнении которое они и не выд, Аноним (-), 19:17 , 19-Янв-24, (650)

Хрустики смогли пробиться в ядро, а С со всеми своими стандартами не смог Очер, Советский инженер (ok), 11:13 , 20-Янв-24, (660)

Они пока так пробились что постоянно переделывают свое месиво, постоянно надо са, Аноним (-), 12:17 , 20-Янв-24, (662)

ты как ни плюйся желчью, а факт есть факт раст в ядре а плюсы нет точно не в , Советский инженер (ok), 21:44 , 21-Янв-24, (679)

В ядре много чего было И не все из этого с нами сейчас Так что это само по себ, Аноним (-), 21:54 , 23-Янв-24, (686)

Возможно потому что его компилятор работает только на последних версиях систем , Аноним (6), 22:06 , 14-Янв-24, (17) //

Там llvm Всё что поддерживает llvm в целом должен или может поддерживать Zig ht, Витюшка (?), 22:15 , 14-Янв-24, (23) //

Вот только для ядра будет требование сборки с использованием gcc Для раста из-за, Аноним (41), 22:50 , 14-Янв-24, (41) +2

Ну, вот и нужны кто будет двигать Zig и возьмётся за добавление к gcc Это должн, Витюшка (?), 23:26 , 14-Янв-24, (54) +1

Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в g, Аноним (-), 23:48 , 14-Янв-24, (68) +1

У LLVM все прекрасно с поддержкой платформ Это GCC поддерживает всяких хлам и н, Аноним (-), 00:03 , 15-Янв-24, (76) –5

ну, ладно выкинут поддержку неподдерживаемых платформ из ядра, потому что, допус, jjklh (?), 03:38 , 15-Янв-24, (145)

При чем тут все платформы Зачем тебе новейший драйвер напр сетевухи на 100Гб н, Аноним (41), 10:53 , 15-Янв-24, (226) –2

BSDшники уже пробовали рассказывать сказку про не нужные всем фичи И где они т, Аноним (-), 19:12 , 15-Янв-24, (390)

Да нет там никакой битвы, тем более легендарной Очень вялая дискуссия где одни , Аноним (20), 04:29 , 17-Янв-24, (602)

Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости нагово, Аноним (13), 22:04 , 14-Янв-24, (13) +6 //

Линус может сказать, что уже прошло много времени и язык существенно изменился в, Аноним (115), 00:09 , 15-Янв-24, (79) +1 //

Он высказался не о языке Он не подумав зачем ему думать, он же диктатор-хозяин, Аноним (94), 00:53 , 15-Янв-24, (94) –2 //

Не знаю о каком именно высказывании говоришь, я видел только где в основном обсу, Аноним (115), 02:14 , 15-Янв-24, (110)

171 C is a horrible language It 8217 s made more horrible by the fact that, 11 (?), 09:18 , 15-Янв-24, (189) +1

Линус знатно потроллил Никто ведь не заставлял принимать a lot на свой счёт , n00by (ok), 10:23 , 15-Янв-24, (211) +2

- что теперь программисты N-го сорта допущены в ядро , Аноним (313), 15:11 , 15-Янв-24, (318)

Тут у Линуса осталось 3 варианта действий 1 покаяться за вред, нанесённый проек, Аноним (368), 18:33 , 15-Янв-24, (368)

Лол, а почему он не может сказать раст уже в ядро добавили, зачем там третий яз, Аноним (-), 20:38 , 15-Янв-24, (410)

Какой третий Весь сишный код фиксится до совместимости с clang и объявляется, Аноним (460), 01:14 , 16-Янв-24, (460)

Речь о c образца 2007г или ранних Вы сами то хотите на них писать Ладно, это , _kp (ok), 22:32 , 16-Янв-24, (587)

Разрешите поинтересоваться Что именно подразумевает header only и почему это на, Синий попугай (ok), 00:18 , 15-Янв-24, (86) +1 //

Либа со сложным и или большим кодом а если код простой и небольшой, который воо, Аноним (97), 01:21 , 15-Янв-24, (97) //

Подтверждением в виде дизассемблерного листинга не порадуете , n00by (ok), 06:45 , 15-Янв-24, (164)

Не тормози, сникерсни Если либа в c cpp и ее отдельным so сделали - все три , Аноним (-), 12:56 , 15-Янв-24, (267)

А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приход, Аноним (293), 18:12 , 15-Янв-24, (360)

Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорны, Аноним (460), 01:18 , 16-Янв-24, (461)

Большинство основных STL частей чисто шаблонные Например, тот же std map генер, Аноним (115), 14:18 , 16-Янв-24, (522)
STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли Для стан, n00by (ok), 14:26 , 16-Янв-24, (524)

Тормозят пока что эксперты и внедрители Си в Linux У меня стандартная библиот, n00by (ok), 14:22 , 16-Янв-24, (523)

И это все круто и офигенно - потому что что С чисто практической точки зрения, , Аноним (-), 12:25 , 20-Янв-24, (663)

Потому что ты придумал тезис круто и офигенно , что бы приписать его мне В над, n00by (ok), 15:28 , 20-Янв-24, (668)

чудик не знал про pragma once, но уже требует кого-то там вон из профессии , Аноним (486), 07:32 , 16-Янв-24, (486) +1

Э Очевидно имелось ввиду именно линковка Один файл компилируется в объектник , Аноним (589), 23:13 , 16-Янв-24, (589)

Взял и boost опозорил , Вы забыли заполнить поле Name (?), 03:03 , 15-Янв-24, (132) +4 //

STL же, boost сама по себе помойка, Аноним (115), 04:57 , 15-Янв-24, (151) +2 //

Любопытно, сколько из присутствующих видели библиотеку Степанова и Ли , n00by (ok), 10:26 , 15-Янв-24, (213)

Покажи, посмотрим , Аноним (293), 13:21 , 15-Янв-24, (275)

Если долго вглядываться в бездну, бездна начнет вглядываться в тебя А вообще, вс, Аноним (421), 21:52 , 15-Янв-24, (421)

pacman -Qo usr include c usr include c 13 2 1 is owned by gcc 13 2 1-, Аноним (421), 21:55 , 15-Янв-24, (422)
Это не то , n00by (ok), 14:34 , 16-Янв-24, (526)

Почему бы это просто в C не добавить , Вы забыли заполнить поле Name (?), 03:04 , 15-Янв-24, (133) //

Давно есть Человек просто поумничать хотел, Аноним (194), 09:44 , 15-Янв-24, (194) –1 //

Шаблонов нет, а compile-time вычисления есть , Аноним (293), 18:14 , 15-Янв-24, (361)

C с этими добавлениями называется C , Аноним (238), 11:20 , 15-Янв-24, (238) +1
Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си , Аноним (115), 14:16 , 15-Янв-24, (298)

Зачем переписывать на C чтобы потом пришлось переписывать на Rust умалчивается, fuggy (ok), 04:44 , 15-Янв-24, (150) +1 //

На rust переписывать не придётся Его засунули в ядро чтобы шумные детишки наигр, Аноним (115), 05:13 , 15-Янв-24, (155) –1 //

Тоже так считаю , Аноним (173), 07:41 , 15-Янв-24, (173)
Раст - навсегда в ядре Учитывая, сколько уве в сетевых подсистемах ведра на сиш, Аноним (253), 12:38 , 15-Янв-24, (253)

Ничего нигде не бывает навсегда, ты сам тут не навсегда Как засунули, так и убе, Аноним (115), 14:28 , 15-Янв-24, (302) +1

Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали , Аноним (253), 14:51 , 15-Янв-24, (310)

Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо, Аноним (115), 15:28 , 15-Янв-24, (323)

А сколько на сегодня Раста в сетевой подсистеме ядра Помоему, пока что хрен цел, Аноним (293), 18:18 , 15-Янв-24, (362) +1

Помимо политики была ещё одна причина - исключения в C , хотя Линус тогда не г, Аноним (341), 17:20 , 15-Янв-24, (351) +1 //

Линус и не развернул тему fundamentally broken В ядре NT возможно использоват, n00by (ok), 14:54 , 16-Янв-24, (530)

Не, нужно сразу 26 в редакции clangа на сегодняшний день брать Потому что без r, Аноним (19), 22:11 , 14-Янв-24, (19) +1 //

вот честно чем пользоваться этой синтаксической ахинеей проще написать в 5 ст, Аноним (194), 09:49 , 15-Янв-24, (195) –1 //

И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того, Аноним (279), 13:25 , 15-Янв-24, (279) //

А потом через полгода выйдет новый пихон - и вообще сборочница сломается Питонж, Аноним (-), 14:47 , 15-Янв-24, (309) +1

В пакетах всё ещё можно поставить второй питон Так что да, ничего не сломается , Аноним (115), 17:58 , 15-Янв-24, (357)

Это в каких бы таких пакетах Поддержку питона2 вынесли сами питоняши еще скольк, Аноним (-), 19:27 , 15-Янв-24, (394)
Итерация свойственна человеку, кодогенерация божественна , Аноним (421), 22:04 , 15-Янв-24, (424)

Засуньте ваш Шланг в Ядрописатели требуют обязательность сборки GCC , Аноним (293), 13:45 , 15-Янв-24, (289) //

Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому ана, Аноним (371), 18:39 , 15-Янв-24, (371) +1 //

Если разработчики ядра захотят обязательно эти концепты, то разработчики GCC пой, Аноним (293), 19:01 , 15-Янв-24, (383) –1

в шланге нет концептов, в gcc они есть Если задействовать код на концептах - то, Аноним (460), 02:10 , 16-Янв-24, (467)

С чего вдруг лучше то , Аноним (589), 23:16 , 16-Янв-24, (590) +1

См рис 1 , Аноним (636), 23:59 , 18-Янв-24, (636)

Как раз схожесть синтаксиса это скорее надостаток, потому что внешнее соходство , Placeholder (ok), 22:14 , 14-Янв-24, (22) +9 //

Так и си этого не гарантирует как и большинство высокоуровневых языков с 1 комп, Аноним (173), 22:25 , 14-Янв-24, (26) +1 //

Это гарантируют стандарты и Си, и Си , а вот смешивание языков может привести к, n00by (ok), 10:31 , 15-Янв-24, (216)

Главные различия, которые следует запомнить В стандарте C нет Value Length Arr, Bottle (?), 22:28 , 14-Янв-24, (28) //

В ядре тоже нету VLA В стандаре C99 было, но потом, поняв ошибку, сделали это в, Аноним (31), 22:34 , 14-Янв-24, (31) //

А в чём проблема VLA Лучше с alloca и указателями для того же самого геморроить, Аноним (58), 23:38 , 14-Янв-24, (58)

В том что 1 Никогда не знаешь когда этот код навернется 2 Способов узнать на, Аноним (-), 23:54 , 14-Янв-24, (70) +1

От переполнения стэка ни один код не защищён И ни один код не защищён от исчерп, Аноним (99), 01:30 , 15-Янв-24, (99) –1

Всего лишь 100Мб, не грохнется Тем более запрос через аллокатор никогда не прив, Аноним (115), 02:08 , 15-Янв-24, (106) –1

Тьфу, действительно мегабайт, перепутал с гигами С выделением на стеке тоже можн, Аноним (126), 02:51 , 15-Янв-24, (126)

Но почему-то проверок места на стеке нигде нет, Аноним (115), 02:56 , 15-Янв-24, (127)

1 Ну попробуй так на AtMega какой-нибудь Правда, грохаться этот убогий не у, Аноним (-), 14:10 , 15-Янв-24, (297)

Какое отношение аппаратные исключения имеют к условному libc, или аллокатору пам, Аноним (115), 15:34 , 15-Янв-24, (326) –1

А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется А вот и хрен, э, Аноним (-), 20:23 , 15-Янв-24, (405)
А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется А вот и хрен, э, Аноним (-), 22:45 , 15-Янв-24, (426)

Это и на AMD64 не работает , n00by (ok), 15:00 , 16-Янв-24, (533)

Если я статически пишу uint8_t arr 10 я имею основания полагать что это будет , Аноним (-), 02:49 , 15-Янв-24, (124) +2

кто сказал раст , jjklh (?), 03:25 , 15-Янв-24, (138) +1
Сишечка не системная - также можно исчерпать стек, вызывая функции Особенно есл, Аноним (149), 03:28 , 15-Янв-24, (139) –2

Да А кто у нас тогда системный то На сях что-то большая часть системщины, бутл, Аноним (-), 13:29 , 15-Янв-24, (283) +1

В некоторых компиляторах есть builtin, позволяющий проверить наличие места на ст, Аноним (140), 03:29 , 15-Янв-24, (140) +1

Просто вопрос был почему VLA не рекомендуют в системщине Ну вот потому В сях в, Аноним (-), 13:50 , 15-Янв-24, (292) +1

Локальные переменные живут в стеке VLA в принципе может жить где угодно, но нуж, Аноним (375), 18:48 , 15-Янв-24, (375)

Читайте стандарты си Там вообще нет упоминания стека, никак и нигде То что кон, Аноним (-), 23:02 , 15-Янв-24, (429)

Конечно, не будет Во всех тестах в массив будут записаны 1-3 байта и они ничего, Аноним (149), 03:41 , 15-Янв-24, (146)

Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них тойота и полу, Аноним (-), 13:45 , 15-Янв-24, (290)

Главное, чтобы у тебя этот суровый r эксепшн tm не произошёл во время полёта н, Tron is Whistling (?), 16:42 , 15-Янв-24, (345)

А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 , nothingaboutdog (?), 20:45 , 15-Янв-24, (413)
Если это важно - это решается другими методами См как это кажется, боинг сдела, Аноним (-), 23:08 , 15-Янв-24, (431)

Не гидравлический пресс надеюсь А то fail fast может в fall fast перейти D, Tron is Whistling (?), 11:27 , 16-Янв-24, (503)
Мне у некоторых софтсвитчей вот этот fail fast нравится Да пусть оно лучше сесси, Tron is Whistling (?), 11:28 , 16-Янв-24, (504)
Софт свич несколько отличается от печатки с силовухой, допустим Одно дело по пр, Аноним (-), 20:56 , 21-Янв-24, (677)
Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочу, Tron is Whistling (?), 22:17 , 21-Янв-24, (680)
По законам Мерфи - устройство порой сгорает первым, защитив предохранитель И F, Аноним (-), 22:14 , 23-Янв-24, (687)
А ваш софт умеет думать, пока МК дымится вместе с платой , Tron is Whistling (?), 22:16 , 23-Янв-24, (688)
Почему Потому что по законам Мерфи первым сдохнут датчики для вашего софта , Tron is Whistling (?), 22:32 , 23-Янв-24, (689)

Как я понял твои ответы - Если мы используем массив со статическим временем жизн, Аноним (341), 17:59 , 15-Янв-24, (358)

И мы можем более адекватно эту идею проверить Частично даже в компилтайме, смот, Аноним (-), 23:21 , 15-Янв-24, (434)

Я почему шучу про много энергично говорим - потому что идеи assert ов для разм, Аноним (341), 01:39 , 16-Янв-24, (462)
Не то что немыслимые - а еще хуже чем динамическая аллокация Ибо еще менее de, Аноним (-), 19:38 , 19-Янв-24, (651)

Дожили А вот ядро Windows NT - защищено Потому что там стек не используют и та, n00by (ok), 06:49 , 15-Янв-24, (166) –1

Для особо одарённых, кто судит по себе и считает это троллингом https learn m, n00by (ok), 10:54 , 15-Янв-24, (227)

И по ссылке написано, дословно, под стэк выделено суммарно три страницы, так ст, freehck (ok), 12:30 , 16-Янв-24, (509)

Надо перевести на понятный Стек крайне осторожно используется для хранения адре, n00by (ok), 15:13 , 16-Янв-24, (534)

Боюсь, что это ты не понял Данная статья просто предостерегает разработчиков о , freehck (ok), 15:27 , 16-Янв-24, (536)

Очевидно, это ты не понял смысл таких не подпускают Защита стека в Window, n00by (ok), 16:10 , 16-Янв-24, (550)
Ух едрить как же всё запущено Ну, с тем же успехом можно сказать, что код защищ, freehck (ok), 16:27 , 16-Янв-24, (553)
Я знаю, что некоторые умело подменяют тезис с целью превзойти собеседника Вот то, n00by (ok), 17:45 , 16-Янв-24, (564)
Размер стека можно задать каким нужно, вызвав соответствующую функцию Это он по, Аноним (637), 00:04 , 19-Янв-24, (637)
Формулировка некорректна Можно _попробовать_ задать размер KeExpandKernelStackA, n00by (ok), 14:58 , 19-Янв-24, (641)

Хорошо, n 55666, но память процесса переполнена Или переполнена иным, более есте, _kp (ok), 12:17 , 15-Янв-24, (251)

Я знаю что сделает нормальный системщик 1 Запретит такую конструкцию если без н, Аноним (-), 14:00 , 15-Янв-24, (295) +1

Проблема в том, что это ядро Вот скажи, какой там размер стека , n00by (ok), 06:48 , 15-Янв-24, (165) –1

Ну если хруст завозят, то и православные плюсики должны завезти , Аноним (173), 22:21 , 14-Янв-24, (24) +1 //

Немного не так Зашкварился на rust Всё, теперь c отказать 8212 не по понят, PnD (??), 17:00 , 15-Янв-24, (348)
Это уже помойка будет какая-то , warlock66613 (ok), 20:02 , 15-Янв-24, (398)

Плюсы очень нужны в ядре, потому что поддержка модулей в Си даже не планируется,, Bottle (?), 22:24 , 14-Янв-24, (25) –9 //

Модули в рабочем состоянии пока что только в компиляторе от микрософта, Аноним (75), 00:01 , 15-Янв-24, (74) //

В шланге давно в рабочем состоянии И в CMake с недавнего времени Но ядро Linux, Аноним (98), 01:25 , 15-Янв-24, (98) //

CMake сам по себе кактус И у тебя вообще хватает инженерного интеллекта, чтобы , Аноним (115), 02:20 , 15-Янв-24, (111) +2

Сфигали не подходит для ядра, если для сборки под голые микроконтроллеры без раз, Аноним (140), 03:30 , 15-Янв-24, (141) +1

Если не подходит, то это же ещё не означает, что не найдутся упоротоые, которые , Аноним (115), 05:25 , 15-Янв-24, (158) +2

Но, но ведь троллейбус делается из буханки ржаного В любом случае чистые make фа, Аноним (-), 20:42 , 15-Янв-24, (411)

модули - проприетарный рак от майкрософт хидеры ничего не замедляют, если мозга, Аноним (-), 00:47 , 15-Янв-24, (92) –2 //

Тогда вам стоит для начала поработать с большими проектами, Аноним (115), 05:26 , 15-Янв-24, (159) +1 //

Насколько большими Сколько строк , Аноним (172), 07:41 , 15-Янв-24, (172)

Настолько, что какой-нибудь sloccount не посчитает за разумное время, Аноним (115), 14:31 , 15-Янв-24, (303)

так вы не делайта свои большие проекты в одну портянку , Аноним (194), 12:06 , 15-Янв-24, (250) +1

А модули в Python, D и ещё много где, тоже Microsoft ввела , Аноним (293), 13:42 , 15-Янв-24, (287) +2

header-only библиотеки конечно можно написать так, чтобы они замедляли компиляци, Аноним (299), 14:26 , 15-Янв-24, (299) +2 //

Это не байка Ты на своей шкуре это сможешь заценить, подключив в программу CLI1, Аноним (375), 18:50 , 15-Янв-24, (377)
Это не байка Погугли патчи ядра от Инго Молнара , Bottle (?), 21:24 , 15-Янв-24, (418)

Наконец-то С Архаика Си - это конечно круто, но технологии идут вперёд , Ivan7 (ok), 22:36 , 14-Янв-24, (33) +3 //

Внедрение плюсов - такой себе шаг вперед, Герман (??), 08:51 , 15-Янв-24, (183) –1
Скрыто модератором, Аноним (-), 15:29 , 16-Янв-24, (537)

Пусть пихают и раст и зиг и сипипи сразу И вейланд с системдой тоже сразу в ядр, Аноним (35), 22:40 , 14-Янв-24, (35) –1
И Carbon, и VLang - тоже , Аноним (37), 22:44 , 14-Янв-24, (37) +2 //

Cabron , Аноним (58), 23:39 , 14-Янв-24, (59) +1 //

Cartoon, Аноним (293), 13:23 , 15-Янв-24, (276) +1

а вот VLang мысль и в самом деле интересная Но, но что там с архитектурами, отл, Котофалк (?), 15:35 , 15-Янв-24, (327) //

Он вроде в С компилируется, значит считай поддерживает считай что все В отличии, Аноним (499), 10:52 , 16-Янв-24, (498)

Не забывая про Zig и Seed ElenaLang -тоже неплохо , Аноним (37), 22:46 , 14-Янв-24, (39) –1 //

Marusya на подходе , Sw00p aka Jerom (?), 14:26 , 15-Янв-24, (300) //

Сначала Алиса, Аноним (293), 15:30 , 15-Янв-24, (324) //

такими темпами не видать нам Katyusha , Sw00p aka Jerom (?), 15:46 , 15-Янв-24, (333)

Seed это вот этот https ru wikipedia org wiki Seed7 , Аноним (293), 20:35 , 15-Янв-24, (409)

Бедный Linux, как же упорно туда всякую гадость пихают , Аноним (42), 22:52 , 14-Янв-24, (42) +2 //

Если плюсы таки завезут, то rust там быстро сдохнет, Аноним (115), 00:14 , 15-Янв-24, (83) +6 //

Вместе с Си и ядром целиком, Герман (??), 08:52 , 15-Янв-24, (184) +6
Это тебе так кажется Раст пихают не потому, что фанаты , а потому, что на то, Аноним (20), 04:35 , 17-Янв-24, (604) +1 //

Да, конечно, не потому что фанаты Давай посмотрим на объективные факты Основ, Аноним (623), 17:06 , 17-Янв-24, (624)

Кресты это нехорошо Одни и те же ошибки ошибки при завышенном чсв плюсовиковНе , Илья (??), 18:40 , 20-Янв-24, (670) +1

Поддерживаю данное начинание , Анонимбус 2000 (?), 22:54 , 14-Янв-24, (43) –1
Это ядро уничтожит энтропия и тогда GNU Hurd всех победит Осталось подождать ещ, Антонимусс (?), 22:55 , 14-Янв-24, (44) +3
Хм, я от с с отошел лет так 15 назад Но вроде наибольшей проблемой в применен, Аноним (45), 22:57 , 14-Янв-24, (45) //

Ведро беспокоит что-либо, кроме gcc , Аноним (48), 23:03 , 14-Янв-24, (48)
А разве с СИ не так же Пришлось делать гну-тые расширения, чтобы собирать ядро , Аноним (-), 23:15 , 14-Янв-24, (49)
Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать н, Аноним (57), 23:33 , 14-Янв-24, (57) +1 //

Да чё там думать, пусть берут эту схему из g Кстати, кто-то как-то приводил д, Аноним (293), 18:47 , 15-Янв-24, (374)

Зачем конкретному ядру бинарная совместимость Эту версию ядра или другую можно , Аноним (293), 18:56 , 15-Янв-24, (380) +1 //

Например, какая-нибудь nvidia тебе поставляет драйвер готовым модулем, ТвойКопетанОчевидность (?), 21:05 , 15-Янв-24, (416) –1

Скоро ядро перепишет ИИ В бинарных кодах сразу , 3draven (ok), 22:58 , 14-Янв-24, (46) –3 //

Машинный код, Информатика (?), 23:18 , 14-Янв-24, (50)
Пусть хотя бы драйвер напишет рабочий А потом сможет в нем баг поправить , Вы забыли заполнить поле Name (?), 02:50 , 15-Янв-24, (125)
ИИ пока что даже простой код генерировать не научился Если не считать измусолен, Аноним (263), 12:54 , 15-Янв-24, (263)

Это не тот самый разраб из Интела, который прислал такой пачт, который даже не с, Аноним (-), 23:00 , 14-Янв-24, (47) –1
Ну наконец-то об этом заговорили , Ilya Indigo (ok), 23:22 , 14-Янв-24, (53) –4
давно пора , cheburnator9000 (ok), 23:43 , 14-Янв-24, (64)
А я согласен на плюсы в ядре Благодаря изменениям под встраиваемые системы там , anodymus (?), 23:44 , 14-Янв-24, (65) +1 //

А каких, собственно, корпорастов Тех, которые GCC разрабатывают , asaaddxasaadd (ok), 00:22 , 15-Янв-24, (87) –1 //

В гугле забанили , Аноним (75), 00:28 , 15-Янв-24, (88)
https isocpp org std the-committee, Аноним (75), 00:30 , 15-Янв-24, (89) //

Одни белые лица и в основном мужики, никакого диверсити , Аноним (175), 08:06 , 15-Янв-24, (181)

Ты лучше посмотри где они работают Сплошные майкрософты, гуглы и прочие корпорац, Аноним (-), 20:49 , 15-Янв-24, (414) +2

С другой стороны понаделают выразительных конструкций , а потом разгребать В б, Вы забыли заполнить поле Name (?), 02:49 , 15-Янв-24, (123) //

Вот, ради интереса, поробуйте объяснить кому-нибудь да хоть себе как в Ядре сп, yet another anonymous (?), 11:19 , 15-Янв-24, (237) +1 //

вы точно программист , Аноним (194), 16:27 , 15-Янв-24, (340)

Ну тут надвое сказано Что именно разгребать ООП для того и придумали, что, Аноним (631), 17:42 , 17-Янв-24, (631) //

А причем тут ООП Хорошую декомпозицию и абстракцию можно сделать без него lisp, Вы забыли заполнить поле Name (?), 02:46 , 18-Янв-24, (633)

скорее потому, что с - надстройка над стого самого intel, который патчи даже н, Аноним (-), 23:58 , 14-Янв-24, (73) //

Пожалуйста, никогда не пишите код на C Вот из-за таких сишников, пищущих на , Аноним (278), 13:25 , 15-Янв-24, (278) +2 //

Давайте классы на GовноObject делать, так определённо лучше , Аноним (375), 18:52 , 15-Янв-24, (378)
как раз наоборот - современный выглядит порой как несто среднее между растом , InuYasha (??), 00:10 , 16-Янв-24, (456)
Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится, Аноним (341), 10:02 , 16-Янв-24, (491) +1

Потом все равно на Carbon переписывать , Аноним (95), 01:14 , 15-Янв-24, (95) +2 //

А вот кстати про Carbon почти никто не пишет, а он развивается просто бешеными т, Аноним (107), 02:30 , 15-Янв-24, (116) //

Понятное дело, что если обратную совместимость не блюсти, то можно все менять ка, Вы забыли заполнить поле Name (?), 02:46 , 15-Янв-24, (122) //

И карго почти наверняка будет запрещено, а ведь это считай центральная фича язык, Аноним (175), 07:32 , 15-Янв-24, (171)

В методичке написано, что это не часть языка и вы можете жить и без него Но та, yet another anonymous (?), 11:27 , 15-Янв-24, (243)
Агаблин, обеспечивает вендорлок на гугл, амазон и майкрософт , Аноним (-), 23:39 , 15-Янв-24, (440)

Гугель говорил, что Carbon будет собирать и код писанный для C , Аноним (293), 20:21 , 15-Янв-24, (404)

Подскажите, это начало конца или второе рождение , Аноним (96), 01:18 , 15-Янв-24, (96) //

Время переходить на NetBSD , bulbasalo (?), 01:44 , 15-Янв-24, (103) //

Если и переходить на то семейство, то уж на Стрекозу , Аноним (293), 13:26 , 15-Янв-24, (280)
Почему не QNX Minix Да даже BeOS была бы куда лучшей альтернативой , Аноним (631), 17:39 , 17-Янв-24, (630)

Это метастазы , Аноним (245), 11:32 , 15-Янв-24, (245)
Это конвульсии трупа Фактически уже понятно - как только добрый диктатор сд, Аноним (631), 17:38 , 17-Янв-24, (629)

Я за ядро на Java Заколебали уже Там тоже синтаксис аналогичный И вообще все, Аноним (105), 02:10 , 15-Янв-24, (108) –8 //

с gc что будем делать , aaaaa (?), 12:55 , 15-Янв-24, (265)
А JVM под чем крутить , Аноним (293), 13:28 , 15-Янв-24, (281) //

Под lisp-машиной, Аноним (115), 14:37 , 15-Янв-24, (308) +1 //

А Lisp-машину на чём Гусары, молчать , Аноним (293), 19:10 , 15-Янв-24, (388)

Так она уже машина Или не знаешь что это такое Тогда википедия в помощь, Аноним (115), 21:06 , 15-Янв-24, (417)

Пока это только умозрительная машина Которую можно вертеть только на , Аноним (589), 23:31 , 16-Янв-24, (593)

Только на java-процессоре , Котофалк (?), 15:39 , 15-Янв-24, (330) //

А Lisp-машину на чём Гусары, молчать , Аноним (293), 19:03 , 15-Янв-24, (384) –1 //

на эмуляторе поверх явапроцессора, Советский инженер (ok), 13:45 , 16-Янв-24, (515)

Пока линуксом управляет один единственный до боеб, способный забаррикадироваться, Аноним (113), 02:20 , 15-Янв-24, (113) –6 //

Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, мо, Аноним (107), 02:32 , 15-Янв-24, (117) +2 //

Есть пример лучще - Fuchsia и ее вот, мы, ща, на десктопы, столица миоа - в нью, Аноним (-), 19:59 , 19-Янв-24, (652)

Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, то, Аноним (120), 02:42 , 15-Янв-24, (120) +4 //

Вас услышали В новом нотпаде уже встроено Он теперь поди по сети отсылает кажд, Аноним (-), 18:44 , 15-Янв-24, (372)

Посмотри вот это видео https www youtube com watch v YyRVOGxRKLg Торвальдс гов, Вы забыли заполнить поле Name (?), 02:43 , 15-Янв-24, (121)
Че ты несешь Совет директоров даже если и принимает решения, то не о каждом эле, Аноним (105), 03:12 , 15-Янв-24, (136) –2
Линус понимает как нужно вести такой проект, а ты нет Сейчас практически весь с, Аноним (115), 05:05 , 15-Янв-24, (152) +3 //

Потому что корпорации в эпоху Интернета быстро поняли, куда дует ветер, и решили, Школьник (ok), 09:18 , 17-Янв-24, (611)

Один процент на десктопах, а не на серверах И проблема не в ядре, Аноним (75), 05:22 , 15-Янв-24, (157)
Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других Ни, Аноним (187), 09:00 , 15-Янв-24, (187)
Форкни ядро и веди его в какое хочешь будущее , Аноним (264), 12:54 , 15-Янв-24, (264)

Останавитесь , Вы забыли заполнить поле Name (?), 02:42 , 15-Янв-24, (119) +1
Round 2 Fight Как бы в отчасти правда, но и ложь тоже Пустив С в ядро им н, Вы забыли заполнить поле Name (?), 02:57 , 15-Янв-24, (128) +1 //

Гайдлайны, внезапно, в ядре и для Си есть Уровень обсуждений далёких от разрабо, Аноним (115), 05:07 , 15-Янв-24, (153) +1 //

Для с они увеличатся на порядок из-за возможных фич языка, Вы забыли заполнить поле Name (?), 14:36 , 15-Янв-24, (306) +1 //

Пусть определятся, какие фичи в ядре допустимы По тем и пишут , Аноним (293), 15:35 , 15-Янв-24, (328) +1
Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек, Аноним (115), 17:56 , 15-Янв-24, (356) –2

Вот дока по стилю С в ядре https www kernel org doc html v4 10 process coding-, Вы забыли заполнить поле Name (?), 22:35 , 15-Янв-24, (425) +4

Табы это 8 пробелов Нас не волнует низкоуровневые вещи вроде отступов, а ещ, Аноним (341), 23:29 , 15-Янв-24, (436) –2

Мой оригинальный комментарий https www opennet ru openforum vsluhforumID3 1325, Вы забыли заполнить поле Name (?), 23:50 , 15-Янв-24, (443) +1

Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь Дока в яд, Аноним (115), 23:32 , 15-Янв-24, (437) +1

Так и не понял куда приклеился ответ, он был анониму с ссылками, Аноним (115), 23:33 , 15-Янв-24, (438)
gt оверквотинг удален Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн , Вы забыли заполнить поле Name (?), 23:45 , 15-Янв-24, (441)

Нет гайдлайна, раньше туда тупых не брали Сейчас пытаешься приклеить документац, Аноним (115), 02:03 , 16-Янв-24, (466)

Просто в конторе не любят писать доку - признай это Поэтому кичиться cs на 1 ст, Вы забыли заполнить поле Name (?), 02:32 , 16-Янв-24, (472)
А в гугл берут тупых по твоей логике раз у них есть гайдлайн Чтож тогда яндексо, Вы забыли заполнить поле Name (?), 02:41 , 16-Янв-24, (473)

Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут, Аноним (-), 20:02 , 19-Янв-24, (653)

Оригинально я писал про гайдлайн, а не cs Если ядро смешивает их, то ко мне как, Вы забыли заполнить поле Name (?), 00:00 , 16-Янв-24, (448)

Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c в нём А зн, Аноним (115), 02:13 , 16-Янв-24, (468) –2

AUTOBOT - это блочит и я не знаю почему А как они собираются исключения туда з, Аноним (-), 03:04 , 15-Янв-24, (134) –1 //

Разумеется, ведь самая главная фича плюсов это исключение, Аноним (115), 05:08 , 15-Янв-24, (154) +3
Пока нашёл там обработку ошибок То есть функция может вернуть либо результать, , Пряник (?), 10:11 , 15-Янв-24, (207)

Это такой лол, что я даже не знаю, что сказать Но когда пропадёт калабуховский , Аноним (147), 03:41 , 15-Янв-24, (147)
Здравый смысл, наконец-то берет верх , bOOster (ok), 03:48 , 15-Янв-24, (148) +2
Да уж, беда пришла откуда не ждали Если что-то и может быть хуже С, то это С , Аноним (96), 05:49 , 15-Янв-24, (161) +1 //

Поправил, не благодари, Аноним (172), 07:46 , 15-Янв-24, (176) –1

Единственная проблема плюсов в ядре -- это привычки и отношение к языку значител, n00by (ok), 07:07 , 15-Янв-24, (168) –1 //

То, что будет возможность писать на плюсах совсем не означает, что толпы молодёж, ДаНуНафиг (?), 18:36 , 15-Янв-24, (370) //

Толпам молодёжи и немоложёжи вообще срать на ядро, они от него в принципе с уд, Аноним (379), 18:56 , 15-Янв-24, (379) //

Под фреймворком обычно понимается что-то тяжёлое На плюсах возможно реализовать, n00by (ok), 15:47 , 16-Янв-24, (545)

На деле, плюсы в ядре повышают порог вхождения по сравнению с Си , n00by (ok), 15:43 , 16-Янв-24, (543)
Лол, молодёжь на javascript пишет, ей что сишечка что плюсы это древние рукописи, Гультай (?), 09:03 , 19-Янв-24, (638)

Это что, реклама Red Hat между делом Данному разговору уже не первое десятилети, freehck (ok), 07:51 , 15-Янв-24, (178) //

Это как раз именно потому, что в нём нет С , ИмяХ (ok), 20:08 , 15-Янв-24, (402)

Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявног, Аноним (182), 08:32 , 15-Янв-24, (182) +6 //

Можно, но костыльно очень Или хотите в ядро нечто, наподобие Glib Это человекон, Аноним (36), 08:55 , 15-Янв-24, (185) –2
Ядро писали на Си, потому что плюсов тогда толком и не было , n00by (ok), 10:46 , 15-Янв-24, (220) +1 //

Ну были, конечно, уровня Borland C А вот был ли свободный g в 1991, не знаю, Аноним (293), 15:37 , 15-Янв-24, (329) //

Был где-то с 87-го https gcc gnu org releases html, 22 (?), 20:45 , 15-Янв-24, (412)
Гипотетически они может и были, а практически стандарт языка принят в 98-м , n00by (ok), 15:56 , 16-Янв-24, (547)

Никакого -- утверждение слишком сильное для сишки Как минимум из-за неявного пр, freehck (ok), 12:57 , 15-Янв-24, (268) //

Rust тоже не ООП язык Вполне себе можно писать крупные проекты и в процедурном , fuggy (ok), 23:50 , 15-Янв-24, (444) +1 //

В ООП стиле на расте писать нельзя т к нет наследования ООП в самом деле не ки, Аноним (115), 02:27 , 16-Янв-24, (470)

В каких задачах нужно ООП , Вы забыли заполнить поле Name (?), 02:58 , 16-Янв-24, (478)

Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями , Аноним (499), 10:45 , 16-Янв-24, (497) +1

На самом деле ООП там нужен только потому, что ООП является отдельной индустрией, freehck (ok), 13:05 , 16-Янв-24, (511) –1

Если объекты в плане понятий из предметной области однотипные Любая, даже мин, Аноним (589), 23:45 , 16-Янв-24, (594)

c это не либа работы со строками Причины совершенно в ином - нет API и нет га, Аноним (115), 15:43 , 15-Янв-24, (332) +1

Это у Red Hat всё шуточки первоапрельские, а между тем Эпол, например, вполне ус, awoland (ok), 08:59 , 15-Янв-24, (186) +2 //

У эппла анально-ректальные стайлгайды и референсы Во-вторых, эпплы сами выпуска, Noname (??), 09:50 , 15-Янв-24, (196) +2 //

Винда написана на С и работает на огромном зоопарке устройств , beck (??), 10:23 , 15-Янв-24, (210) //

Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось и, Аноним (214), 10:44 , 15-Янв-24, (218) –1

Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые бл, Аноним (214), 10:46 , 15-Янв-24, (221)
Какие полтора типа Минимум шесть Windows не виновата в том, что у тебя лапки , beck (??), 10:51 , 15-Янв-24, (225)

Суть в том, что они там были испокон времён, ничего нового, и то на хлам с армом, Аноним (214), 11:01 , 15-Янв-24, (232)

Выкинь уже свой зион с али, с 171 ECC 187 -памятью , Аноним (482), 06:52 , 16-Янв-24, (485) +1

Твои фантазии унылые, фиксация какая-то , Аноним (214), 09:45 , 16-Янв-24, (488)

Во-первых, стайлгайды и референсы не имеют никакого отношения к технологиям прог, awoland (ok), 14:37 , 15-Янв-24, (307) //

И ты ещё что-то там про газификацию луж пишешь Лол , Noname (??), 17:03 , 15-Янв-24, (349)

Вообще вопрос надо ставить глобально Зачем ограничения на язык для разработки м, poulch (??), 09:09 , 15-Янв-24, (188) +1 //

Та же мысль В Сишный интерфейс функций умеют почти все языки, пусть ядро остает, Аноним (205), 10:09 , 15-Янв-24, (205) //

собственно, а кто запрещает , Советский инженер (ok), 11:35 , 15-Янв-24, (246)

Тогда как собирать всю эту мозаику У инструментов будут свои зависимости, а у т, Аноним (459), 00:16 , 16-Янв-24, (459)

Зачем ибо когда придёт какой-нибудь С 50, который наконец-таки превратится в R, Аноним (191), 09:23 , 15-Янв-24, (191) –1 //

Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C и почему Ра, Аноним (459), 10:58 , 15-Янв-24, (229) +1 //

Анвин считает, что C более предпочтителен, чем Rust, так как последний сущест, Аноним (293), 13:34 , 15-Янв-24, (284)

Ты думаешь, что в C 50 порежут все что можно по самые помидоры Так что останетс, Аноним (589), 23:48 , 16-Янв-24, (595)

давно пора, d_kazbek (?), 09:40 , 15-Янв-24, (192) +1
Руст действительно будет интереснее, а кресты уже показали несостоятельность за , Noname (??), 09:43 , 15-Янв-24, (193) //

Интереснее побаловатся на раз, а так С зрелый язык промышленной разработки и п, Аноним (459), 11:01 , 15-Янв-24, (233) –1
А чем D не взлетел Что в этом языке такого плохого, что его нельзя использоват, Аноним (631), 17:27 , 17-Янв-24, (628)

Ну вообще плюсы в ядре - здраво, но с оговорками Исключения придётся вымести, по, Tron is Whistling (?), 10:07 , 15-Янв-24, (203) //

Какие ещё целые массы тех, кто в не-плюсовый C не осилил - как они вообще окозал, ay8910 (?), 11:22 , 15-Янв-24, (239) //

Человек не понимает, что ядро пишется корпорациями на деньги корпораций Им и ре, Аноним (253), 12:58 , 15-Янв-24, (271)
Цель как раз в том, чтобы они в них и не оказались , Tron is Whistling (?), 15:12 , 15-Янв-24, (320)
Сходи к попам, посмотри на их кресты Пойми, чем плюс отличается от креста , Аноним (293), 20:26 , 15-Янв-24, (407)

Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает , Аноним (293), 13:19 , 15-Янв-24, (274)
Во всех контейнерах STL можно передавать собственные аллокаторы Можно хоть для , Аноним (278), 13:35 , 15-Янв-24, (285) //

Соглашусь только за C 20 Хотя да, в принципе о нём и речь , Tron is Whistling (?), 15:11 , 15-Янв-24, (319)

Вместо STL будет своя либа с примитивами в c стиле STL для ядерных целей не п, Аноним (115), 15:47 , 15-Янв-24, (334)

Я, конечно, не участвую в разработке ядра и не мне решать как и многим коммента, Пряник (?), 10:16 , 15-Янв-24, (208) //

Как раз неосиляторы и впариают новые языки Писать на них они тоже не умеют, но , banonymous (?), 10:47 , 15-Янв-24, (222) –3 //

Впарили раст в ядро - корпорации, их ядро, а не неосиляторы У корпораций нет ин, Аноним (253), 12:42 , 15-Янв-24, (256) //

Что-то по вакансиям не сильно этого заметно , Аноним (459), 00:11 , 16-Янв-24, (457)

Какие такие вакансии Ты о чём Речь про ведро, корпорациям-хозяйкам ведра не ну, Аноним (253), 10:13 , 16-Янв-24, (493)

И кто же это тут несолилятор, лол , Аноним (278), 13:28 , 15-Янв-24, (282) –1

Ядро windows написано на С Вопрос об использовании С давно закрыт Это работ, beck (??), 10:24 , 15-Янв-24, (212) +3 //

Но даже windows переходит на Rust , Пряник (?), 10:29 , 15-Янв-24, (215) //

В винде архитектура гибридная Они могут позволить себе какие-то независимые час, beck (??), 10:58 , 15-Янв-24, (230) +2 //

Пиши драйвера в пр-ве пользователя на чём угодно, Аноним (115), 16:00 , 15-Янв-24, (339)

Не переходят, а пишут отдельные модули Там же не идиоты переписывать работающий, Аноним (459), 11:08 , 15-Янв-24, (234)

Ну, работать та работает Но вот как работает , Аноним (41), 10:56 , 15-Янв-24, (228) //

Нормально работает Десятки миллионов серверов и сотни миллионов десктопов по вс, beck (??), 11:00 , 15-Янв-24, (231) +1 //

по-дефолту в плюсах нет инструментов для безопасной работы с памятью RAII и sma, Аноним (253), 12:55 , 15-Янв-24, (266) –1

Очнись, наркоша Смарт поинтеры в плюсовых проектах уже более 30 лет в том или и, Аноним (115), 18:26 , 15-Янв-24, (364) +1

Ну ты и оболтус Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто, Аноним (253), 10:17 , 16-Янв-24, (494)

Если так хорошо работает, почему везде линукс Фактически сиплюсы используются т, Аноним (264), 12:52 , 15-Янв-24, (261) //

Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда Смартф, beck (??), 13:43 , 15-Янв-24, (288) –1 //

Не хочется тебя расстраивать, но это не от того, что винда хорошо работает Это , Вы забыли заполнить поле Name (?), 14:55 , 15-Янв-24, (312)

Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду 2 са, Аноним (-), 15:55 , 15-Янв-24, (336)

Путаешь интерфейс и подложку На подложке в этих же аппаратах - далеко не винда , Tron is Whistling (?), 16:35 , 15-Янв-24, (344)

Возможно, но например банкоматы я встречал на винде Винда IoT Core вполне достат, Аноним (-), 17:18 , 15-Янв-24, (350)

Банкомат - слишком примитивное устройство Дисплей, кейпад, принтер и полтора ко, Tron is Whistling (?), 18:27 , 15-Янв-24, (365)

В самом аппарате, который деньги выдаёт, контроллеры бывают разные, но они автон, Tron is Whistling (?), 18:28 , 15-Янв-24, (366)
У одной фирмы я видал там характерную лужайку с кнопкой Start Или, не менее паф, Аноним (-), 20:07 , 19-Янв-24, (654)

Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за мини, Аноним (353), 17:37 , 15-Янв-24, (353)

Всё очень просто На интерфейсе для врача - винда В МРТ, на рентгене, в аппарате, Tron is Whistling (?), 16:32 , 15-Янв-24, (342) +1

Внутри аппаратов чистое железо с прошивкаме Накой там ОС , beck (??), 22:55 , 15-Янв-24, (427)

Прошивки прямо в металле DВы недооцениваете современные прошивки , Tron is Whistling (?), 23:04 , 15-Янв-24, (430)

То есть винда тебе только картинку рисует, всеми же серьёзными задачами занимают, Tron is Whistling (?), 16:33 , 15-Янв-24, (343)

Совершенно другие ОС даже не в состоянии нарисовать картинку, ОК , Аноним (482), 23:22 , 15-Янв-24, (435)

Там программеры другие, они занимаются не рисованием картинок, а работой со слож, Tron is Whistling (?), 11:25 , 16-Янв-24, (501)

ви таки недооцениваете сложность рисования картинок по данным, полученным от сож, Советский инженер (ok), 12:15 , 16-Янв-24, (507)

Картинки рисовать - тоже сложно, не спорю, но это больше математика Ну и плюс ве, Tron is Whistling (?), 13:48 , 16-Янв-24, (516)
Короче есть разница тупо на CPU процессить данные или работать с кучей датчиков, Tron is Whistling (?), 13:49 , 16-Янв-24, (518)

Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки А т, Аноним (293), 19:17 , 15-Янв-24, (392)

Закупаем такие современное оборудование с условием, что нам его кто-то продаст , Аноним (482), 06:47 , 16-Янв-24, (484)

Ядро винды написано на Си, Аноним (115), 17:39 , 15-Янв-24, (354) +2
Откуда вы эту муйню все копируете Ядро винды написано и продолжает писаться на , хрю (?), 14:53 , 16-Янв-24, (529) +1 //

Достаточно интервью в котором мелкомагкие переписывальщики на раст говорят о том, Аноним (589), 23:57 , 16-Янв-24, (596)

Вроде же не 1 апреля еще Автор цитаты выше Перепил на новый год и думает что на, Вирт (?), 11:26 , 15-Янв-24, (242) –1 //

Все способы выстрелить себе в ногу в C - это исключительно наследие C На чист, Аноним (278), 13:41 , 15-Янв-24, (286) //

А кто не начнёт, когда в шаблонном коде получаешь ошибку в коде кишок , Вы забыли заполнить поле Name (?), 15:00 , 15-Янв-24, (314)
А дебильные классические типы целых чисел там как Их так то и в си неплохо бы в, Аноним (-), 00:09 , 16-Янв-24, (454) //

Ты не поверишь, но отрицательный индекс в массиве по указателю - очень даже вост, Tron is Whistling (?), 11:26 , 16-Янв-24, (502)

В производстве овно кода и CVEшек Верю Можно просто открывать новости пенька и , Fyjy (?), 13:41 , 16-Янв-24, (512) –1

Вот есть у меня вот прямо индекс указателей на элементы Есть поинтер на какой-т, Tron is Whistling (?), 13:51 , 16-Янв-24, (519)

Так твой пример сам по себе небезопрасный И на этот случай есть унарный --, зна, Аноним (115), 14:45 , 16-Янв-24, (527)

Мне не нужно менять сам указатель , Tron is Whistling (?), 20:00 , 16-Янв-24, (577)

Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме , Аноним (-), 20:15 , 19-Янв-24, (656) –1

Да не, я не против, чтобы ты вместо одного сервера у меня 10 купил, но ты ведь н, Tron is Whistling (?), 21:41 , 19-Янв-24, (658)

Я как махровый сишник готов поспорить что все то же самое можно было сделать зна, Аноним (-), 12:44 , 20-Янв-24, (665)

На самом деле пусть уходят - чище будет , Tron is Whistling (?), 13:04 , 20-Янв-24, (666)

Инихрена себе уровень самокритики Вот это вы круты Я правильно понимаю что вы , Аноним (-), 21:09 , 21-Янв-24, (678)

А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали Я все, Аноним (655), 20:12 , 19-Янв-24, (655) –1

Хахахаха, ты предлагаешь невозможное Сейчас набигут фанатики и объяснят тебе, чт, Fyjy (?), 13:44 , 16-Янв-24, (514)

Лучше уж Rust C это нагромождение костылей, если все это особенно метапрогра, nc (ok), 11:47 , 15-Янв-24, (247) //

Да, только раст спасёт ведро линукс , Аноним (253), 12:39 , 15-Янв-24, (254) //

Да дело не в том что кто-то чего-то спасет Языки программирования объективно ра, nc (ok), 12:53 , 15-Янв-24, (262) +1 //

А опция --std компилятору не подойдет , Серб (ok), 13:57 , 15-Янв-24, (294) –1

Для реализации ломающих изменений и сохранения возможности компиляции старых фай, nc (ok), 15:40 , 15-Янв-24, (331)

Это само по себе хорошо т к не нужно править дохринилиард прагм во всём репозит, Аноним (115), 15:56 , 15-Янв-24, (337)

Да нет Наоборот Если захочется применить в исходнике новые возможности, то ты , _oleg_ (ok), 16:56 , 16-Янв-24, (561)

Правильно и логично - когда не надо менять код под каждый новый стандарт Любая н, Серб (ok), 17:14 , 16-Янв-24, (563)

А зачем его менять, если как предлагается выше, компиляторы поддерживают разные , _oleg_ (ok), 18:06 , 16-Янв-24, (568)

Например, что бы оптимизации сработали Смотри lto , Серб (ok), 18:18 , 16-Янв-24, (571)

Если pragma version относится только к синтаксической части, то оптимизации здес, _oleg_ (ok), 18:51 , 16-Янв-24, (572)

Стандарты очень часто вводят для включения возможности оптимизации На старых ст, Серб (ok), 12:46 , 17-Янв-24, (617)
Оптимизации - расплывчатое понятие Что я вижу в новых стандартах C и C это не, _oleg_ (ok), 13:20 , 17-Янв-24, (618)
На изменение обработки volatile смотрел , Серб (ok), 13:43 , 17-Янв-24, (619)
На расширение того, что при constexpr уйдет в компиле тайм смотрел , Серб (ok), 13:48 , 17-Янв-24, (620)

Странно, но именно для этого его и используют Конечно там включается до гхм , Серб (ok), 16:49 , 15-Янв-24, (346)

В результате программисты просто бы никуда не переходили Совместимость со стары, Аноним (115), 15:58 , 15-Янв-24, (338) +1

rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хоте, Аноним (115), 15:52 , 15-Янв-24, (335) +3
Про C согласен Но и rust не нужен Пусть пишут свои проекты Зачем в ядро лез, _oleg_ (ok), 16:48 , 16-Янв-24, (559)

Чего только не сделают, лишь бы переизобрести лисп в своем языке Отправляйте в, Аноним (263), 13:01 , 15-Янв-24, (272) –1
хруст до добра не доведет, Аноним12345 (?), 14:28 , 15-Янв-24, (301) +2
Скрыто модератором, Миллион глаз (?), 17:53 , 15-Янв-24, (355)
Какой смысл C заменять на C Между ними нет никакой принципиальной разницы C , DEF (?), 18:05 , 15-Янв-24, (359) –2 //

Никаких новых парадигм в расте нету Тогда уже лисп давайте, Аноним (194), 18:35 , 15-Янв-24, (369) +1 //

Путались в указателях, теперь будут путаться в скобочках , Вы забыли заполнить поле Name (?), 22:55 , 15-Янв-24, (428)

1 Раст требует грёбанного тулчейна 2 Хотя-бы потому, что на крестах доступны р, Аноним (386), 19:04 , 15-Янв-24, (386) +1 //

Именно, а Раст без тулчейна и с unsafe теряет свои главные преимущества и принци, Аноним (499), 10:38 , 16-Янв-24, (496) +1
а с или с не требуют грёбанного тулчейна как же тогда текстовые файлы с исхо, Советский инженер (ok), 12:20 , 16-Янв-24, (508)

Сам ты морально устаревший C такой же устаревший как ложка с вилкой Да что это, _oleg_ (ok), 16:47 , 16-Янв-24, (558) //

Обычная болезнь зумеров Знаний - мало, энергии - много, страсть ко всему новому, Аноним (631), 17:25 , 17-Янв-24, (627)

Нет, к чёртовой матери таких товарищей , Товарищ (?), 18:57 , 15-Янв-24, (381) +2
Не узнаю вас, анонимы Ловко вас провели Что, уже идея с растом не так плоха ка, Вы забыли заполнить поле Name (?), 03:18 , 16-Янв-24, (480) //

Судя по реакции, скорее наоборот Под угрозой включения Rust в ядро все уже согл, Аноним (499), 10:36 , 16-Янв-24, (495) +2

Откуда вообще взялось это ограничение на язык для ядерных модулей Сишные интерф, хрю (?), 14:57 , 16-Янв-24, (532) //

Нужна поддержка сбоки модулей на другом языке Нужно выработать единый интре, Вы забыли заполнить поле Name (?), 15:43 , 16-Янв-24, (544) //

Вот поэтому высокоуровневых программистов и веб-мака нельзя подпускать к систем, Аноним (-), 07:07 , 17-Янв-24, (607) //

Что плохого в идее WASI , Вы забыли заполнить поле Name (?), 02:53 , 18-Янв-24, (634)

Я зол В низкоуровневых разработках нет места объектно-ориентированным языкам С, Аноним (-), 15:25 , 16-Янв-24, (535) +1 //

Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода, Аноним (499), 16:20 , 16-Янв-24, (552) –1
Да ладно бы ОО C даже как ОО не очень Просто страшное недоразумение какое-то, _oleg_ (ok), 16:43 , 16-Янв-24, (556) +1 //

Не тролинга ради вопрос в каком языке ООП сделано как надо , Вы забыли заполнить поле Name (?), 23:11 , 16-Янв-24, (588) //

Нормальное ООП должно быть основано на интерфейсах Никакого наследования Тем б, DEF (?), 23:26 , 16-Янв-24, (592)

Да ты чё, сам придумал Но тогда почитай, на каких столпах основано это самое ОО, Аноним (608), 07:34 , 17-Янв-24, (608)

smalltalk, от автора термина ООП Erlang Что ещё хз Это из того, что видел C , _oleg_ (ok), 11:18 , 17-Янв-24, (612)

Набор микросервисов с динамической типизацией В качестве примера ООП это лучше , Серб (ok), 14:37 , 19-Янв-24, (639)
В Java поправили diamond problem, зато напихали default interface Отличие абстр, fuggy (ok), 23:49 , 22-Янв-24, (682)

Кто ж сказал, что java идеальна C в этом плане получше, по свидетельствам очев, _oleg_ (ok), 11:36 , 23-Янв-24, (683)

Например, в D чистый преемник С Нет множ наследования порождающие больше п, Аноним (631), 17:21 , 17-Янв-24, (626)

Тут только одна проблема - это самое порождение проблем родит их для разработчик, Серб (ok), 14:40 , 19-Янв-24, (640)

Что ж людям-то не работается спокойно То rust с его кошмарным синтаксисом, то C, _oleg_ (ok), 16:41 , 16-Янв-24, (555) //

Я слушал интервью Страуструпа Он сам хотел этого - язык в котором есть всё в ви, Аноним (-), 16:53 , 16-Янв-24, (560) //

Дело не в том, что там всё в виде объектов Дело в том, что там просто кошмарный, _oleg_ (ok), 17:04 , 16-Янв-24, (562) –1 //

Можно ссылку , Вы забыли заполнить поле Name (?), 02:33 , 17-Янв-24, (597)

В книге The C Programming Language, 4th Edition, подчеркиваеться что Страустру, Полная отсебятина (?), 02:57 , 17-Янв-24, (598)
Не могу найти оригинал Перепечатка тут http harmful cat-v org software c I, _oleg_ (ok), 11:22 , 17-Янв-24, (613)

Майкрософт вот не тупит и на расте уже Винду переписывает https www theregist, Аноним (20), 04:39 , 17-Янв-24, (605) //

Приводить Майкрософт компанию, которую все презирают , как пример для подражани, Аноним (-), 07:04 , 17-Янв-24, (606) +3
То, что в M работают индусские м к ки, порождает и соотв решения - вот Раст к , Аноним (631), 17:16 , 17-Янв-24, (625) +1 //

Да это вы просто не видели что они с виндофоном вытворяли Еще и нокию за собой , Аноним (-), 20:20 , 19-Янв-24, (657) +2

Заскорузлые мозги устаревшие решения Почему не D Для кого развивали преем, Аноним (631), 14:41 , 17-Янв-24, (621) //

Если бы его грамотно пиарили и больше людей в разработку включили, а так имеем ч, Аноним (632), 00:09 , 18-Янв-24, (632) +2

Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты , Аноним (667), 13:34 , 20-Янв-24, (667)
С и С имеют множества недостатков от которых некоторые современные языки вылеч, Аноним (671), 03:53 , 21-Янв-24, (671) //

Поток сознания, Аноним (693), 14:10 , 28-Мрт-24, (693)

Сообщения [Сортировка по времени | RSS]

1. "Дискуссия об использовании языка C++ для разработки ядра Lin..." –17 +/–

Сообщение от Аноним (1), 14-Янв-24, 21:43

Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.

Ответить | Правка | Наверх | Cообщить модератору

2. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от oficsu (ok), 14-Янв-24, 21:46

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

Ответить | Правка | Наверх | Cообщить модератору

18. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +3 +/–

Сообщение от Аноним (18), 14-Янв-24, 22:08

>Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу
ШТО?
Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. Это шаблоны можно заставить компилироваться сколь угодно долго.

Ответить | Правка | Наверх | Cообщить модератору

52. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +3 +/–

Сообщение от funny.falcon (?), 14-Янв-24, 23:20

> не обладают тьюринговой полнотой
Но остаётся совсем чуть-чуть до этого.
https://github.com/Hirrolot/metalang99
https://jadlevesque.github.io/PPMP-Iceberg/
Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
И оно компилится действительно очень долго.
Кроме TCC, он быстр даже в этих шаблонах. Правда, чуть-чуть бажит.

Ответить | Правка | Наверх | Cообщить модератору

61. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +4 +/–

Сообщение от Аноним (-), 14-Янв-24, 23:41

> Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
> И оно компилится действительно очень долго.
А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею.
Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.

Ответить | Правка | Наверх | Cообщить модератору

56. "Дискуссия об использовании языка C++ для разработки ядра Lin..." –1 +/–

Сообщение от Аноним (-), 14-Янв-24, 23:32

> Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой.
> Это шаблоны можно заставить компилироваться сколь угодно долго.
Они ну вот буквально на грани :). Единственный лимит - рекурсия до 128, чтоли, уровней в GCC разрешена. Но с таким количеством рекурсии можно основательно позажигать.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

69. "Дискуссия об использовании языка C++ для разработки ядра Lin..." –1 +/–

Сообщение от oficsu (ok), 14-Янв-24, 23:48

> Это шаблоны можно заставить компилироваться сколь угодно долго
Да, можно. Но это рассуждение об экстремальных примерах. Но экстремальные примеры — скорее редкость. Дуплицирование кода от макросов способно замедлять компиляцию точно так же, как и шаблоны. И способно иногда замедлять её даже сильнее при решении аналогичных задач

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

214. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Аноним (214), 15-Янв-24, 10:28

Тормозящие шаблоны целиком типичная ситуация в 100% проектов. Программы на этом языке компилируются дольше всего.

Ответить | Правка | Наверх | Cообщить модератору

408. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Аноним (293), 15-Янв-24, 20:31

Шаблоны это compile time. Ну и хрен с ними, сколько им компиляться. Главное, чтобы потом сгенерённый код быстро работал.

Ответить | Правка | Наверх | Cообщить модератору

30. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Bottle (?), 14-Янв-24, 22:29

А ещё макросы не анализируются также хорошо как шаблоны через статический анализ.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +5 +/–

Сообщение от Аноним (4), 14-Янв-24, 21:47

Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

32. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от _hide_ (ok), 14-Янв-24, 22:36

А кто сказал, что раст можно? Пока что раст -- это для модулей, которые с ванилью собирать не обязательно

Ответить | Правка | Наверх | Cообщить модератору

51. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Витюшка (?), 14-Янв-24, 23:18

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

Ответить | Правка | Наверх | Cообщить модератору

107. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (107), 15-Янв-24, 02:09

Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет.

Ответить | Правка | Наверх | Cообщить модератору

204. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Герман (??), 15-Янв-24, 10:07

Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследование классов, шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо, лишнее усложнение не нужно, высока цена ошибки
Раст же, как и Си, - прост. Да, раст посложнее Си по части обучения, но проще плюсов, и он предоставляет множество гарантий безопасности, чего нет в плюсах

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

252. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (252), 15-Янв-24, 12:21

>гарантий безопасности
Какие тебе гарантии нужны? Средства в плюсах давно есть. А если у тебя генетическая склонность стрелять по своим ногам, то тут и раст не справится.

Ответить | Правка | Наверх | Cообщить модератору

255. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Герман (??), 15-Янв-24, 12:42

Средства, использования которых необязательны? Было бы в плюсах все хорошо с безопасностью, не было бы придумано столь много безопасных замен ему. Раст учит разработчиков с самого начала изучения следить за правильной работой с памятью, не давая некорректному коду скомпилироваться
Говорят, что у Раста мнимая безопасность, потому что есть unsafe (который в случае ошибки при работе с памятью, укажет разработчику, куда стоит смотреть в первую очередь), но код на плюсах - весь unsafe

Ответить | Правка | Наверх | Cообщить модератору

347. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Аноним (341), 15-Янв-24, 16:51

> шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо
Давайте полюбуемся на простые _Generic-макросы в ядре. И вообще на макросы.
https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...
https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

6. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (6), 14-Янв-24, 21:50

А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

7. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Аноним (7), 14-Янв-24, 21:50

Даже в Gentoo завезли бинарное ядро.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

36. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (36), 14-Янв-24, 22:43

Для истинных гентушков это ничкго не изменило.

Ответить | Правка | Наверх | Cообщить модератору

105. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (105), 15-Янв-24, 02:02

Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.

Ответить | Правка | Наверх | Cообщить модератору

452. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Аноним (452), 16-Янв-24, 00:06

Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.

Ответить | Правка | Наверх | Cообщить модератору

517. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (115), 16-Янв-24, 13:49

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

Ответить | Правка | Наверх | Cообщить модератору

601. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 17-Янв-24, 04:16

> Отличается же, в генте не нужно готовить всякий шлак вроде initrd и
> не нужно собирать всё ядро. В других линуксах всё же обычно
> дают возможность пересобрать всё и это очень долго,
Yolo! Я майнлайне кернель под дебианом собираю. В билдсистеме ядра даже есть генерация пакетов. Таргет "make bindeb-pkg" - и билдсистема сама скроит пакетик с кернелом в лучшем виде. И да, часть систем тоже взлетает без initrt. Хоть они и дебианы. Что в этом такого?
И уж конечно кастомизировать можно все что угодно. Билдится это - в зависимости от того что включено. Только билдить кернел для 1 тазика не совсем практично - для какого-то "класса железок" намного прагматичнее. Ибо майнтайнить зоопарк - затея весьма голимая. Особенно как локалхостов становится более десятка.
> а ксатомизировать крайне геморно
Я бы не назвал menuconfig чем-то ужасным. А вон там для референса дистровский конфиг есть например. И гемор - он в чем? И чего так уж упрощает в этом гента? Там самое сложное - это понимать что эти галочки реально делают. Гента в этом не поможет вообще никак :)

Ответить | Правка | Наверх | Cообщить модератору

623. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (623), 17-Янв-24, 16:35

>  А вон там для референса дистровский конфиг есть например. И гемор - он в чем?
Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. Сложность заключается в кол-ве телодвижений от начала процесса и до выкатки в бутовый конфиг за вычетом времени в menuconfig

Ответить | Правка | Наверх | Cообщить модератору

647. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 19-Янв-24, 18:46

> Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля.
ИМХО где как. На десктопе я от дистровского конифига танцевал, таргетируя более-менее похожие на мой компы x86-64, без совсем редких вундервафель махрового энтерпрайза или винтажного добра редко встречающегося в x86-64.
Да, кернел жирнее и дольше билдится. Зато подымает 3 мои компа включая "альтернативные/бэкапные" и ноут. Без затрат времени на билдовку им уберкастома. Это осознанный tradeoff.
А например на ARM - я местами и от мелкого defconfig оттанцевал. Потому что вот там из дистрокернела вырезать ненужное можно и заманаться уже, если я таргетирую допустим пяток похожих железок на чипах одной фирмы и более - нифига.
> Сложность заключается в кол-ве телодвижений от начала процесса и до
> выкатки в бутовый конфиг за вычетом времени в menuconfig
Когда тазиков оказывается не 1 а эн, начинает хотеться некоторого обобщения оных и урезания объема работ. Если у меня легион одноплатников - и я буду каждому кернел под микроскопом пилять - я тогда займусь только микро-оптимизациями, а на более полезные и интересные проекты времени не останется. И вот интеерсные проекты будут спущены в угоду 2% перфоманса. А оно того точно стоило? Эти 2% никто не заметит - и я уж точно не упирался в 2% перфоманса в задачах которые там были. Иначе я бы выбрал более мощную железку, для более разумных сроков проекта.

Ответить | Правка | Наверх | Cообщить модератору

8. "Дискуссия об использовании языка C++ для разработки ядра Lin..." –1 +/–

Сообщение от maximnik0 (?), 14-Янв-24, 21:51

>Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.С выкидыванием всякого хлама,там такого всего накопилось ......
Вообще удивительно как это еще собирается.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

63. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 14-Янв-24, 23:43

> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.
> С выкидыванием всякого хлама,там такого всего накопилось ......
Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.

Ответить | Правка | Наверх | Cообщить модератору

458. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Аноним (452), 16-Янв-24, 00:13

И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.

Ответить | Правка | Наверх | Cообщить модератору

475. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Аноним (-), 16-Янв-24, 02:52

> И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход
> на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный.
> Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю.
На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).

Ответить | Правка | Наверх | Cообщить модератору

583. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от _kp (ok), 16-Янв-24, 21:47

> Так то g++ заметно тормознее gcc...
  Это в прошлом было такое.
А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc, в среднем, но не всегда.
  Но нет дыма без огня. В разных сборках компиляторов скорость может отличаться в разы, например, бывает "хорошая" сборка g++ может быть заметно быстрее gcc или другой сборки g++. Такой бардак с компиляторами есть для esp32 и stm32, и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары компиляторов можно сделать неверные выводы.
  При тесте на исходнике который могут переварить оба компилятора, нормальных сборок, то разница незначительна, и быстрее может оказаться и g++.
  А  если понаворотите кода, то логично, что работы станет больше, и оптимизировать тоже  надо.
  А еще некорректно сравнивать скорость компиляции в отрыве от результата компиляции, а то clang часто быстрее g++, но у g++ бинарник получше на мой взгляд выходит.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

603. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 17-Янв-24, 04:30

> А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc,
> в среднем, но не всегда.
Угу, конечно. Запускаем допустим libaom компилиться. И чего-то сишная часть тикает быстро, а вот плюсатые - всего лишь тесты - куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивные. Cmake индикатор прогресса кажет, в процентах, там хорошо видно кто тормоз.
>   Но нет дыма без огня. В разных сборках компиляторов скорость
> может отличаться в разы, например, бывает "хорошая" сборка g++ может быть
> заметно быстрее gcc или другой сборки g++.
У меня стандартный дебиановский gcc/g++ 12.x - такой как его дебиан отгружает. Васянские сборки я устанавливать не собираюсь хоть там как.
> Такой бардак с компиляторами есть для esp32 и stm32,
Я для STM32 собираю обычным дистровским же gcc-arm-none-eabi (впрочем и gcc-arm-gnueabihf катит). Но я для фирмварей только си юзаю. А зачем мне васянские сборки, опять же?
> и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары
> компиляторов можно сделать неверные выводы.
Вон то - совершенно типовой тренд для билдовки софта. Суммарно я так или иначе пробовал билдовать около 250 разных программ так что имел возможность заметить тренды. Они мало меняются по версиям системного gcc, g++ всегда заметно медленнее gcc как компилер.
>   При тесте на исходнике который могут переварить оба компилятора, нормальных
> сборок, то разница незначительна, и быстрее может оказаться и g++.
Возможно. Однако плюсатый софт в целом компилится весьма ощутимо медленнее. Ессно его нельзя собрать gcc для сравнения. Но например GTKшную морду трансмишна на си VS плюсатую на Qt - вполне, и в силу сравнимой функциональности можно прикинуть как мне время билдовки. И оно ессно не в пользу g++ от слова вообще.
>   А еще некорректно сравнивать скорость компиляции в отрыве от результата
> компиляции, а то clang часто быстрее g++, но у g++ бинарник
> получше на мой взгляд выходит.
Я выразил "интегральный" опыт - в целом плюсатый софт заметно тормознее в компиле. Вот хоть как. И тот же gcc после того как разрешили юзеж плюсов пересобираться стал ощутимо дольше, что в общем то и не фича вовсе.

Ответить | Правка | Наверх | Cообщить модератору

615. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от _kp (ok), 17-Янв-24, 12:26

>>А зачем мне васянские сборки, опять же?
Если например пересборка компилятора esp32s3 и системы сборки сократила время сборки проекта  с 40 до 8 секунд, то таких Васянов на руках носить надо.
Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" дали подсказку куда копать, то и их труды не пропали.
>>куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивны
Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.
Но это справедливо для одной версии и сборки компиляторов clang и gcc. А разные версии и сбоки могут отличаться как угодно
Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, свежие компиляторы в принципе медленнее старых версий их же самих. И разрыв между компиляцией си и с++ будет вполне заметен. А на среднемощном десктопе таки пофиг.

Ответить | Правка | Наверх | Cообщить модератору

673. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 21-Янв-24, 16:53

> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны"
> дали подсказку куда копать, то и их труды не пропали.
Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому.
> Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.
Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить.
> Ещё на слабых для разработки компах, и тем более каких есть ноутбуках,
> свежие компиляторы в принципе медленнее старых версий их же самих. И
> разрыв между компиляцией си и с++ будет вполне заметен. А на
> среднемощном десктопе таки пофиг.
У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.

Ответить | Правка | Наверх | Cообщить модератору

674. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от _kp (ok), 21-Янв-24, 19:21

Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а не переписывать, чем занята другая группа.
Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Но случаи бывают разные. Банально что то поправить, и собрать не дома. Есть ещё командировки. И студенты в конце концов.
>>плюсовые проекты заметно тормознее билдить.
Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда по сути си проекты, с минимумом фич от с++, или их отсутствием, собирают с++ компилятором. И тут, взависимости от стиля исходника, бинарник может получиться и лучше, и контроль типов получше, а разница во времени компиляции минимальна в подобных случаях.
Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, а то именно на мощных компах проекты "начинающих" и "консерваторов" не используют все ресурсы компа, и даже на мощной машине собираются неспешно.

Ответить | Правка | Наверх | Cообщить модератору

675. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (-), 21-Янв-24, 20:34

> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а
> не переписывать, чем занята другая группа.
Вот те раз. А я то думал изначальный смысл - оценить технологию, по возможности объективно и непредвзято. И в этом смысле меня таки как кастомщика и кернелбилдера в контексте сабжа беспокоит потенциал для обвала скорости компила в разы.
Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит.
Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will.
> Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы?
> Но случаи бывают разные. Банально что то поправить, и собрать не дома.
> Есть ещё командировки. И студенты в конце концов.
Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит.
>>>плюсовые проекты заметно тормознее билдить.
> Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда
> по сути си проекты, с минимумом фич от с++, или их
> отсутствием, собирают с++ компилятором.
Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config.
> И тут, взависимости от стиля исходника, бинарник может получиться и лучше,
С фига ли вдруг?
> и контроль типов получше,
Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить...
> Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить
> не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки,
Ну да, давайте искать не там где ключ потеряли, а под фонарем, потому что там светло. Вон то все же похоже на костыль или неизбежное зло, которым занялись от отличной скорости сборки плюсоты. Это конечно не оправдание для совсем уж хреновых подходов.
> а то именно на мощных компах проекты "начинающих" и "консерваторов" не
> используют все ресурсы компа, и даже на мощной машине собираются неспешно.
Да вообще-то при пинке в кучу потоков процы оно нормально жрет и как раз упирается в именно проц. Вот особенно - плюсота как раз. Там именно g++ плотно проц грузит надолго, в остальное захочешь не упрешься. На сях там еще может быть всякий оверхед, io и проч, т.к. относительно резво билдует. Но в плюсах это как раз намного меньшая проблема.

Ответить | Правка | Наверх | Cообщить модератору

20. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +4 +/–

Сообщение от Аноним (20), 14-Янв-24, 22:12

А зачем вы его постоянно пересобираете?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

40. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +3 +/–

Сообщение от Аноним (36), 14-Янв-24, 22:46

2.6.32 работает - не трожь!

Ответить | Правка | Наверх | Cообщить модератору

60. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от anonymous (??), 14-Янв-24, 23:39

Потому что оно багованное.
Проверяем, есть ли баги в новых версиях.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

104. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Аноним (20), 15-Янв-24, 01:49

Так это ж надо желать один раз, когда хочется попробовать новую версию. А один раз - какая разница, сколько оно собирается? Это ж не 200 тысяч запросов в секунду где время обработки имеет значение.

Ответить | Правка | Наверх | Cообщить модератору

77. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +/–

Сообщение от Аноним (77), 15-Янв-24, 00:06

> А зачем вы его постоянно пересобираете?
Потому что его постоянно правят. Вот бы заморозили его разработку, да? Тогда можно было бы переписывать на любые языки и не заботиться о том, что кто-то захочет его собрать.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

277. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от pv (?), 15-Янв-24, 13:23

> А зачем вы его постоянно пересобираете?
https://bellard.org/tcc/tccboot.html
а ведь когда-то можно было и так, игрушечным компилятором размером в 100кБ, написанным изначально вообще для ioccc.
да и чего мелочиться, в ядре просто необходим питон, яваскрипт, го, и вижуалбэйсик!
и систему сборки ещё обязательно поменять, а то несовременно как-то.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

27. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Аноним (27), 14-Янв-24, 22:27

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

34. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +1 +/–

Сообщение от Аноним (36), 14-Янв-24, 22:40

>Запаримся пересобирать же! Си собирается намного шустрее.
А что вы про Rust запоёте?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

179. "Дискуссия об использовании языка C++ для разработки ядра Lin..." +2 +/–

Сообщение от Проходил мимо (?), 15-Янв-24, 08:00

Судя по комментариям, большинство из тех, кто "поет" на OpenNET про Rust разбираются в нем примерно как свинья в апельсинах. Хотя, возможно, свинья разбирается все же лучше.
Хейтеры, которые ниАсилили. Естественно, что у любого, кто в теме вопли всяких криворуких рукожопов вызывают лишь гомерический смех.
PS Это не значит, что Rust идеальный и у него нет проблем. Некоторые вещи там сделаны не лучшим образом.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–17 +/–
Сообщение от Аноним (1), 14-Янв-24, 21:43
Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от oficsu (ok), 14-Янв-24, 21:46
	Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (18), 14-Янв-24, 22:08
	>Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу ШТО? Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. Это шаблоны можно заставить компилироваться сколь угодно долго.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от funny.falcon (?), 14-Янв-24, 23:20
	> не обладают тьюринговой полнотой Но остаётся совсем чуть-чуть до этого. https://github.com/Hirrolot/metalang99 https://jadlevesque.github.io/PPMP-Iceberg/ Я сделал на шаблонах довольно мощную штуку с объектным программированием на C. И оно компилится действительно очень долго. Кроме TCC, он быстр даже в этих шаблонах. Правда, чуть-чуть бажит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:41
	> Я сделал на шаблонах довольно мощную штуку с объектным программированием на C. > И оно компилится действительно очень долго. А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею. Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:32
	> Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. > Это шаблоны можно заставить компилироваться сколь угодно долго. Они ну вот буквально на грани :). Единственный лимит - рекурсия до 128, чтоли, уровней в GCC разрешена. Но с таким количеством рекурсии можно основательно позажигать.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	69. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от oficsu (ok), 14-Янв-24, 23:48
	> Это шаблоны можно заставить компилироваться сколь угодно долго Да, можно. Но это рассуждение об экстремальных примерах. Но экстремальные примеры — скорее редкость. Дуплицирование кода от макросов способно замедлять компиляцию точно так же, как и шаблоны. И способно иногда замедлять её даже сильнее при решении аналогичных задач
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	214. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (214), 15-Янв-24, 10:28
	Тормозящие шаблоны целиком типичная ситуация в 100% проектов. Программы на этом языке компилируются дольше всего.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	408. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 20:31
	Шаблоны это compile time. Ну и хрен с ними, сколько им компиляться. Главное, чтобы потом сгенерённый код быстро работал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Bottle (?), 14-Янв-24, 22:29
	А ещё макросы не анализируются также хорошо как шаблоны через статический анализ.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	4. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+5 +/–
	Сообщение от Аноним (4), 14-Янв-24, 21:47
	Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	32. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от _hide_ (ok), 14-Янв-24, 22:36
	А кто сказал, что раст можно? Пока что раст -- это для модулей, которые с ванилью собирать не обязательно
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Витюшка (?), 14-Янв-24, 23:18
	Это сказал Линус в интервью, что ожидается большее использование в базовых компонентах ядра. Те модули - это пока, проба пера.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (107), 15-Янв-24, 02:09
	Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	204. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Герман (??), 15-Янв-24, 10:07
	Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследование классов, шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо, лишнее усложнение не нужно, высока цена ошибки Раст же, как и Си, - прост. Да, раст посложнее Си по части обучения, но проще плюсов, и он предоставляет множество гарантий безопасности, чего нет в плюсах
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	252. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (252), 15-Янв-24, 12:21
	>гарантий безопасности Какие тебе гарантии нужны? Средства в плюсах давно есть. А если у тебя генетическая склонность стрелять по своим ногам, то тут и раст не справится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	255. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Герман (??), 15-Янв-24, 12:42
	Средства, использования которых необязательны? Было бы в плюсах все хорошо с безопасностью, не было бы придумано столь много безопасных замен ему. Раст учит разработчиков с самого начала изучения следить за правильной работой с памятью, не давая некорректному коду скомпилироваться Говорят, что у Раста мнимая безопасность, потому что есть unsafe (который в случае ошибки при работе с памятью, укажет разработчику, куда стоит смотреть в первую очередь), но код на плюсах - весь unsafe
	Ответить \| Правка \| Наверх \| Cообщить модератору


	347. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (341), 15-Янв-24, 16:51
	> шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо Давайте полюбуемся на простые _Generic-макросы в ядре. И вообще на макросы. https://github.com/torvalds/linux/blob/052d534373b7ed33712a6... https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...
	Ответить \| Правка \| К родителю #204 \| Наверх \| Cообщить модератору


	6. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (6), 14-Янв-24, 21:50
	А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	7. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (7), 14-Янв-24, 21:50
	Даже в Gentoo завезли бинарное ядро.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	36. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (36), 14-Янв-24, 22:43
	Для истинных гентушков это ничкго не изменило.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	105. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (105), 15-Янв-24, 02:02
	Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	452. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (452), 16-Янв-24, 00:06
	Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	517. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 13:49
	Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно собирать всё ядро. В других линуксах всё же обычно дают возможность пересобрать всё и это очень долго, а ксатомизировать крайне геморно
	Ответить \| Правка \| Наверх \| Cообщить модератору


	601. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 04:16
	> Отличается же, в генте не нужно готовить всякий шлак вроде initrd и > не нужно собирать всё ядро. В других линуксах всё же обычно > дают возможность пересобрать всё и это очень долго, Yolo! Я майнлайне кернель под дебианом собираю. В билдсистеме ядра даже есть генерация пакетов. Таргет "make bindeb-pkg" - и билдсистема сама скроит пакетик с кернелом в лучшем виде. И да, часть систем тоже взлетает без initrt. Хоть они и дебианы. Что в этом такого? И уж конечно кастомизировать можно все что угодно. Билдится это - в зависимости от того что включено. Только билдить кернел для 1 тазика не совсем практично - для какого-то "класса железок" намного прагматичнее. Ибо майнтайнить зоопарк - затея весьма голимая. Особенно как локалхостов становится более десятка. > а ксатомизировать крайне геморно Я бы не назвал menuconfig чем-то ужасным. А вон там для референса дистровский конфиг есть например. И гемор - он в чем? И чего так уж упрощает в этом гента? Там самое сложное - это понимать что эти галочки реально делают. Гента в этом не поможет вообще никак :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	623. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (623), 17-Янв-24, 16:35
	> А вон там для референса дистровский конфиг есть например. И гемор - он в чем? Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. Сложность заключается в кол-ве телодвижений от начала процесса и до выкатки в бутовый конфиг за вычетом времени в menuconfig
	Ответить \| Правка \| Наверх \| Cообщить модератору


	647. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 18:46
	> Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. ИМХО где как. На десктопе я от дистровского конифига танцевал, таргетируя более-менее похожие на мой компы x86-64, без совсем редких вундервафель махрового энтерпрайза или винтажного добра редко встречающегося в x86-64. Да, кернел жирнее и дольше билдится. Зато подымает 3 мои компа включая "альтернативные/бэкапные" и ноут. Без затрат времени на билдовку им уберкастома. Это осознанный tradeoff. А например на ARM - я местами и от мелкого defconfig оттанцевал. Потому что вот там из дистрокернела вырезать ненужное можно и заманаться уже, если я таргетирую допустим пяток похожих железок на чипах одной фирмы и более - нифига. > Сложность заключается в кол-ве телодвижений от начала процесса и до > выкатки в бутовый конфиг за вычетом времени в menuconfig Когда тазиков оказывается не 1 а эн, начинает хотеться некоторого обобщения оных и урезания объема работ. Если у меня легион одноплатников - и я буду каждому кернел под микроскопом пилять - я тогда займусь только микро-оптимизациями, а на более полезные и интересные проекты времени не останется. И вот интеерсные проекты будут спущены в угоду 2% перфоманса. А оно того точно стоило? Эти 2% никто не заметит - и я уж точно не упирался в 2% перфоманса в задачах которые там были. Иначе я бы выбрал более мощную железку, для более разумных сроков проекта.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от maximnik0 (?), 14-Янв-24, 21:51
	>Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее. Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.С выкидыванием всякого хлама,там такого всего накопилось ...... Вообще удивительно как это еще собирается.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	63. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 14-Янв-24, 23:43
	> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка. > С выкидыванием всякого хлама,там такого всего накопилось ...... Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	458. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (452), 16-Янв-24, 00:13
	И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
	Ответить \| Правка \| Наверх \| Cообщить модератору