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

"Дискуссия об использовании языка C++ для разработки ядра Linux"	+/–
Сообщение от opennews (??), 14-Янв-24, 21:43
В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60436
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

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

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

3. Сообщение от Аноним (3), 14-Янв-24, 21:46	–11 +/–
> В списке рассылки Шёл 2024 год...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #10, #16, #109, #160

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

5. Сообщение от Аноним (3), 14-Янв-24, 21:47	–5 +/–
П.с. Так там ещё и 80 символов ограничение 🤦‍♀️
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #9, #72

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

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

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

9. Сообщение от Аноним (9), 14-Янв-24, 21:53	+5 +/–
> checkpatch/coding-style: deprecate 80-column warning https://lkml.org/lkml/2020/5/31/326
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

10. Сообщение от nich (ok), 14-Янв-24, 21:58	+/–
Да вообще тупые.  Пора уже на слак перейти, или накрайняк на дискорд.  Я уже устал читать их многостраничные сообщения в рассылке.  В слаке или в дискорде каждое сообщение будет не более двух-трех строчек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #137

11. Сообщение от Аноним (11), 14-Янв-24, 21:59	+3 +/–
> "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax Это он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #81, #248, #406

12. Сообщение от Витюшка (?), 14-Янв-24, 21:59	+7 +/–
Легендарная битва. Интересно чем закончится. Но сразу и Rust и C++ одновременно - это совсем не good. Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #17, #602

13. Сообщение от Аноним (13), 14-Янв-24, 22:04	+6 +/–
Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости наговорил глупостей. Но из-за такого китайского концепта как "потеря лица" он не может признать, что говорил глупости. Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений (да, я знаю, они тяжёлые. Но в C++ есть модули, в них такие вычисления закешируются). Но необходимо ввести жёсткую конвенцию по написанию кода о том, что должно линковаться на уровне хэдеров, что - статически, а что - динамически, и разработать линтер. Без линтера тут никуда. За header-only нужно сразу от разработки отлучать с волчьим билетом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #79, #86, #132, #133, #150, #351

15. Сообщение от Витюшка (?), 14-Янв-24, 22:05	+2 +/–
У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. Но за Rust хайп и очень фанатичное комьюнити, которое толкает его куда только можно. Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #21, #29, #67, #135

16. Сообщение от Аноним (16), 14-Янв-24, 22:05	+/–
... и до сих пор не придумали ничего лучше, чем форум. Даже в виде рассылки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

17. Сообщение от Аноним (6), 14-Янв-24, 22:06	+/–
>Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра). Возможно потому что его компилятор работает только на последних версиях систем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #23

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

19. Сообщение от Аноним (19), 14-Янв-24, 22:11	+1 +/–
>В качестве минимальной упоминается использование спецификации C++14 Не, нужно сразу 26 в редакции clangа на сегодняшний день брать. Потому что без ranges делать compile-time вычисления невесело. Хоть в шланге и нет ещё полноценных ranges, уже то что есть - очень полезно и убирает кучу того, что либо вручную приходилось держать в актуальном состоянии или скриптом генерировать (напр. индекс максимального элемента массива из фиксированных compile-time значений). magic_enum вообще офигенно полезная либа. Она хоть и header-only, но она не приводит к оверхеду на каждый включённый экземпляр, как если бы nlohmann json включили в один модуль, а потом во второй, и всё header-only. Другая офигенна полезная либа - это ctre.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #195, #289

20. Сообщение от Аноним (20), 14-Янв-24, 22:12	+4 +/–
А зачем вы его постоянно пересобираете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #40, #60, #77, #277

21. Сообщение от Аноним (11), 14-Янв-24, 22:12	+2 +/–
Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

22. Сообщение от Placeholder (ok), 14-Янв-24, 22:14	+9 +/–
Как раз схожесть синтаксиса это скорее надостаток, потому что внешнее соходство вообще не означает что под капотом будет схожее поведение. Этакие "ложные друзья переводчика".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #28

23. Сообщение от Витюшка (?), 14-Янв-24, 22:15	+/–
Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig. https://docs.kernel.org/kbuild/llvm.html Да и ядро и так компилится с помощью llvm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #41, #68

24. Сообщение от Аноним (173), 14-Янв-24, 22:21	+1 +/–
Ну если хруст завозят, то и православные плюсики должны завезти.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #348, #398

25. Сообщение от Bottle (?), 14-Янв-24, 22:24	–9 +/–
Плюсы очень нужны в ядре, потому что поддержка модулей в Си даже не планируется, а хедеры очень сильно замедляют компиляцию.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74, #92, #299

26. Сообщение от Аноним (173), 14-Янв-24, 22:25	+1 +/–
Так и си этого не гарантирует как и большинство высокоуровневых языков с >1 компиляторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #216

27. Сообщение от Аноним (27), 14-Янв-24, 22:27	+2 +/–
опять огульные выдуми кро скорость сборки. когда же вы успокоитесь, выдумщики
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

28. Сообщение от Bottle (?), 14-Янв-24, 22:28	+/–
Главные различия, которые следует запомнить: В стандарте C++ нет Value Length Array (хотя GCC, Clang поддерживают их), приведение типов немного иное, ABI отлично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #31

29. Сообщение от jjklh (?), 14-Янв-24, 22:28	+3 +/–
По моим, наверное, второе дыхание было с C++0x/C++1y. А вот уже с C++1z/C++2a и дальше язык просто рванул в космос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

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

31. Сообщение от Аноним (31), 14-Янв-24, 22:34	+/–
В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте  опциональным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #58

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

33. Сообщение от Ivan7 (ok), 14-Янв-24, 22:36	+3 +/–
Наконец-то С++! Архаика Си - это конечно круто, но технологии идут вперёд!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #183, #537

34. Сообщение от Аноним (36), 14-Янв-24, 22:40	+1 +/–
>Запаримся пересобирать же! Си собирается намного шустрее. А что вы про Rust запоёте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #179

35. Сообщение от Аноним (35), 14-Янв-24, 22:40	–1 +/–
Пусть пихают и раст и зиг и сипипи сразу. И вейланд с системдой тоже сразу в ядро. Ресукликс-Биникс!
Ответить | Правка | Наверх | Cообщить модератору

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

37. Сообщение от Аноним (37), 14-Янв-24, 22:44	+2 +/–
И Carbon, и VLang - тоже !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59, #327

39. Сообщение от Аноним (37), 14-Янв-24, 22:46	–1 +/–
Не забывая про Zig и Seed   (ElenaLang -тоже неплохо )) )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #300, #409

40. Сообщение от Аноним (36), 14-Янв-24, 22:46	+3 +/–
2.6.32 работает - не трожь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

41. Сообщение от Аноним (41), 14-Янв-24, 22:50	+2 +/–
Вот только для ядра будет требование сборки с использованием gcc. Для раста из-за этого начали делать gccrs, было утверждено добавление GCC 13 (https://www.opennet.ru/opennews/art.shtml?num=57491) в виде беты и так далее. А что у Зига? Разве есть хоть какие-то подвижки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #54

42. Сообщение от Аноним (42), 14-Янв-24, 22:52	+2 +/–
> Rust > C++ Бедный Linux, как же упорно туда всякую гадость пихают...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #83

43. Сообщение от Анонимбус 2000 (?), 14-Янв-24, 22:54	–1 +/–
Поддерживаю данное начинание!
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от Антонимусс (?), 14-Янв-24, 22:55	+3 +/–
Это ядро уничтожит энтропия и тогда GNU Hurd всех победит. Осталось подождать ещё лет 10.
Ответить | Правка | Наверх | Cообщить модератору

45. Сообщение от Аноним (45), 14-Янв-24, 22:57	+/–
Хм, я от с/с++ отошел лет так 15 назад. Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Тогда как в чистом с можно было линковаться между разными компиляторами, потому что есть бинарная совместимость. Для расширений питона это вроде до сих пор актуально. Не будет ли из-за этого проблем с ядром? Гарантировать что все блобы в ядре и сторонние модули будут скомпилированы одним компилятором никто не может.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #49, #57, #380

46. Сообщение от 3draven (ok), 14-Янв-24, 22:58	–3 +/–
Скоро ядро перепишет ИИ. В бинарных кодах сразу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #125, #263

47. Сообщение от Аноним (-), 14-Янв-24, 23:00	–1 +/–
Это не тот самый разраб из Интела, который прислал такой пачт, который даже не скомпилился? И бедяге пришлось выражаться %^!@$%, тк высказаться прямо он уже не может((( And why the %^!@$% does a header file include a C file? That's wrong regardless of this bug. https://lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypM.../
Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от Аноним (48), 14-Янв-24, 23:03	+/–
Ведро беспокоит что-либо, кроме gcc?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

49. Сообщение от Аноним (-), 14-Янв-24, 23:15	+/–
А разве с СИ не так же? Пришлось делать гну-тые расширения, чтобы собирать ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от Информатика (?), 14-Янв-24, 23:18	+/–
Машинный код
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

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

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

53. Сообщение от Ilya Indigo (ok), 14-Янв-24, 23:22	–4 +/–
Ну наконец-то об этом заговорили!
Ответить | Правка | Наверх | Cообщить модератору

54. Сообщение от Витюшка (?), 14-Янв-24, 23:26	+1 +/–
Ну, вот и нужны кто будет двигать Zig и возьмётся за добавление к gcc. Это должны быть компании, но таких пока нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

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

57. Сообщение от Аноним (57), 14-Янв-24, 23:33	+1 +/–
>Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать не могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #374

58. Сообщение от Аноним (58), 14-Янв-24, 23:38	+/–
А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #70, #165

59. Сообщение от Аноним (58), 14-Янв-24, 23:39	+1 +/–
Cabron.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #276

60. Сообщение от anonymous (??), 14-Янв-24, 23:39	+/–
Потому что оно багованное. Проверяем, есть ли баги в новых версиях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #104

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

62. Сообщение от _kp (ok), 14-Янв-24, 23:42	–24 +/–
Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо сизифов труд.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #78, #90, #236, #270

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

64. Сообщение от cheburnator9000 (ok), 14-Янв-24, 23:43	+/–
давно пора.
Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от anodymus (?), 14-Янв-24, 23:44	+1 +/–
А я согласен на плюсы в ядре. Благодаря изменениям под встраиваемые системы там теперь можно исключения не использовать. И более строгая проверка типов чем в С. Плюс, выразительнее языковые конструкции можно делать. А Раст - это просто попытка корпорастов под себя "поляну" подмять. Они же, наверняка, весь это "хайп" вокруг языка и разводят за бабло. Чтобы потом одним прекрасным утром поставить специальный блоб (как пример) в зависимостях и никто никуда уже не слезет. И с упорностью осла лезут в проект в который их никто не звал, вместо того, чтобы свой делать и показать как надо. Инфоцыгане. У C++ хотя бы комитет стандартизации существует. Да, он тоже многими корпорастами спонсируется, но там тяжелее свою волю навязывать. Приходится уже договариваться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87, #123

67. Сообщение от Аноним (-), 14-Янв-24, 23:47	+2 +/–
> Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig. Как там у него с портабельностью и вообще готовностью к проду? Вот представьте что завтра билдим кернел им для вашего десктопника. Как, прокатит? Без факапищ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #101

68. Сообщение от Аноним (-), 14-Янв-24, 23:48	+1 +/–
> Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig. Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в git, ибо LLVM не особо то кроссплатформенная штука и далеко не все архитектуры поддерживает. Здорово сливая GCC по поддержке железа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #76

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

70. Сообщение от Аноним (-), 14-Янв-24, 23:54	+1 +/–
> А в чём проблема VLA? Лучше с alloca и указателями для того же самого > геморроиться и статическому анализатору палки в колёса ставить? В том что... 1) Никогда не знаешь когда этот код навернется. 2) Способов узнать навернется ли он - нет. 3) В стандартах "C" нет слова "стэк" от слова вообще. 4) Поэтому вы в душе не и...те сколько его доступно и плохо ли arr[n] или прокатит. А теперь представьте что у вас по рандому будет грохаться ЯДРО по причине "переполнение стека". Как вам такая перспектива? Этот аспект конечно существует всегда но с именно VLA он вылезает наиболее зло и часто. Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При том вы даже узнать не можете ок ли такой n или нет. В отличие от мануальной аллокации где хотя-бы зввернут. А тут - сразу SIGSEGV какой бу, или что там. Круто, да?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #99

72. Сообщение от Аноним (115), 14-Янв-24, 23:57	–3 +/–
Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменяли бы их на пробелы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #118, #291, #315

73. Сообщение от Аноним (-), 14-Янв-24, 23:58	+/–
> в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++ скорее потому, что с++ - надстройка над с >  один из ключевых разработчиков ядра в компании Intel того самого intel, который патчи даже не компиляет перед отправкой?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #278

74. Сообщение от Аноним (75), 15-Янв-24, 00:01	+/–
Модули в рабочем состоянии пока что только в компиляторе от микрософта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #98

75. Сообщение от Аноним (75), 15-Янв-24, 00:03	+2 +/–
О чем речь? С++ может инициализировать структуры
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

76. Сообщение от Аноним (-), 15-Янв-24, 00:03	–5 +/–
У LLVM все прекрасно с поддержкой платформ. Это GCC поддерживает всяких хлам и некроплатформы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #145, #390

77. Сообщение от Аноним (77), 15-Янв-24, 00:06	+/–
> А зачем вы его постоянно пересобираете? Потому что его постоянно правят. Вот бы заморозили его разработку, да? Тогда можно было бы переписывать на любые языки и не заботиться о том, что кто-то захочет его собрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

78. Сообщение от Аноним (75), 15-Янв-24, 00:07	+1 +/–
struct A {   int a;   int b; }; A a1{1, 2}; работает в C++20 (может и в более ранних версиях)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #244

79. Сообщение от Аноним (115), 15-Янв-24, 00:09	+1 +/–
Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Ты как тогда не хотел понимать какие претензии были к с++, так сейчас не будешь разбираться что же изменилось в лучшую сторону. > Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за... Кроме из-за ещё есть и аргументы против. Твоё выдёгивание только из-за' ничего не стоит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #94

81. Сообщение от Аноним (81), 15-Янв-24, 00:13	–5 +/–
А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #100, #170, #490

83. Сообщение от Аноним (115), 15-Янв-24, 00:14	+6 +/–
Если плюсы таки завезут, то rust там быстро сдохнет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #184, #604

86. Сообщение от Синий попугай (ok), 15-Янв-24, 00:18	+1 +/–
Разрешите поинтересоваться? Что именно подразумевает header only и почему это настолько плохо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #97

87. Сообщение от asaaddxasaadd (ok), 15-Янв-24, 00:22	–1 +/–
А каких, собственно, корпорастов? Тех, которые GCC разрабатывают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #88, #89

88. Сообщение от Аноним (75), 15-Янв-24, 00:28	+/–
В гугле забанили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

89. Сообщение от Аноним (75), 15-Янв-24, 00:30	+/–
https://isocpp.org/std/the-committee
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #181

90. Сообщение от Аноним (-), 15-Янв-24, 00:42	+1 +/–
> Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо > сизифов труд. Эй, это даже в си работает?! Вы там что-то совсем тормоз не отпустили? Черт, даже можно присваивать однотипные структуры. Одна из причин по которым gcc в freestanding надо memcpy - конечно же такое присвоение это вот оно будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #115, #149, #249

92. Сообщение от Аноним (-), 15-Янв-24, 00:47	–2 +/–
модули - проприетарный рак от майкрософт. хидеры ничего не замедляют, если мозгами хоть иногда пользоваться, что в случае майкрософт невозможно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #159, #287

94. Сообщение от Аноним (94), 15-Янв-24, 00:53	–2 +/–
>Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Он высказался не о языке. Он не подумав (зачем ему думать, он же диктатор-хозяин-барин и ядро - его собственность! правда потом спонсоры ему пояснили, who is who.) ляпнул, что недопуск C++ в ядро - это мера по недопуску в ядро программистов N-го сорта - программистов на C++. Если теперь он допустит в ядро программистов на C++, то ему придётся признавать 3 вещи: 1. что программисты на C++ - это не программисты N-го сорта 2. что Линус необоснованно из личной гордыни задел достоинство программистов на C++ 3. что оттолкнув по мотивам личной гордыни и неприязни определённую группу программистов Линус проявил непрофессионализм и замедлил развитие проекта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #110, #318, #587

95. Сообщение от Аноним (95), 15-Янв-24, 01:14	+2 +/–
Потом все равно на Carbon переписывать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #116, #404

96. Сообщение от Аноним (96), 15-Янв-24, 01:18	+/–
Подскажите, это начало конца или второе рождение?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #103, #245, #629

97. Сообщение от Аноним (97), 15-Янв-24, 01:21	+/–
>Что именно подразумевает header only Либа со сложным и/или большим кодом (а если код простой и небольшой, который вообще каждый может написать влёгкую за пару строчек - то нафига либа?), которую позиционируют как удобную для включения в проект за счёт того, что она представляет собой один или несколько несколько h-файлов, содержащих реализацию алгоритма. Сюда для целей "вон из профессии" не включаются небольшие header-only либы, предназначение которых есть compile-time вычисления. Пример такого хлама - nlohmann/json и CLI11. Такие либы действительно в некотором смысле удобно включать проект, путём простого копирования их в папку с хедерами и подключения хедера, или путём использования git-подмодуля. >почему это настолько плохо? a.cpp <- lib1.hpp b.cpp <- lib1.hpp c.cpp <- lib1.hpp В результате у нас тормоза при компиляции, и в каждый бинарь включена своя копия реализации. Это если a.cpp, b.cpp, c.cpp дают отдельные бинарники. Если всё линкуется в один бинарник, то вообще может быть ошибка линковки в случае криворукости разраба header-only либы. Если же он додумался сделать всё с inline, то ошибки линковки не будет, но копирование реализации и тормоза никуда не денутся. Любое изменение реализации либы приведёт к полной перекомпиляции проекта, а в случае отдельного хэдера с интерфейсом и линковке как OBJECT изменение реализации приведёт только к перекомпиляции файла с реализацией и перелинковке. Разумеется, при header-only либе ни о каком динамическом связывании, когда перелинкуется только бинарник либы, и версия либы вообще выбирается пользователем и не требует перекомпиляции зависящей от либы программы (необходимо для эффективной работы пакетного менеджера) даже и речи не идёт. Программист свою программу должен писать так. чтобы пользователям этой пртграммы было удобно. Так как в опенсорсе программист зачастую сам пользователь, то тут это должно проявляться особенно. Но многие предпочитают срать на головы пользователям, даже не осознавая, что насрали на голову себе. Вон из профессии таких.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #164, #486

98. Сообщение от Аноним (98), 15-Янв-24, 01:25	+/–
В шланге давно в рабочем состоянии. И в CMake с недавнего времени. Но ядро Linux продолжает жрать makefile-кактус вместо CMake+Ninja.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #111

99. Сообщение от Аноним (99), 15-Янв-24, 01:30	–1 +/–
От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти. > Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #106, #124, #166, #251

100. Сообщение от Витюшка (?), 15-Янв-24, 01:35	+8 +/–
Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода. Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. Это как раз для передачи json по http синтаксис не столь важен, "можно потерпеть", не критично. Попробуй разобрать алгоритм на brainfuck.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #573

101. Сообщение от Витюшка (?), 15-Янв-24, 01:37	+/–
К сожалению, нет. Я и говорю что некому топить за него. Топить - не только в рассылках писать "а давайте zig", а именно допилить до применения в ядре. Основа там заложена очень крутая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #385

103. Сообщение от bulbasalo (?), 15-Янв-24, 01:44	+/–
Время переходить на  NetBSD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #280, #630

104. Сообщение от Аноним (20), 15-Янв-24, 01:49	+1 +/–
Так это ж надо желать один раз, когда хочется попробовать новую версию. А один раз - какая разница, сколько оно собирается? Это ж не 200 тысяч запросов в секунду где время обработки имеет значение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

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

106. Сообщение от Аноним (115), 15-Янв-24, 02:08	–1 +/–
Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #126, #297

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

108. Сообщение от Аноним (105), 15-Янв-24, 02:10	–8 +/–
Я за ядро на Java. Заколебали уже. Там тоже синтаксис  аналогичный. И вообще все есть интернет. У них вон 8-я версия много лет в продакшене и жабомашина может запускать разные версии когда надо. Чего к плюсам привязались? Солянка - так солянка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #265, #281, #330

109. Сообщение от Аноним (107), 15-Янв-24, 02:12	+4 +/–
Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки и их архивы будут на месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

110. Сообщение от Аноним (115), 15-Янв-24, 02:14	+/–
Не знаю о каком именно высказывании говоришь, я видел только где в основном обсуждался ЯП
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #189

111. Сообщение от Аноним (115), 15-Янв-24, 02:20	+2 +/–
CMake сам по себе кактус. И у тебя вообще хватает инженерного интеллекта, чтобы догадаться, что система сборки, полностью заточенная под юзерспейс, для ядра не подходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #141

113. Сообщение от Аноним (113), 15-Янв-24, 02:20	–6 +/–
Пока линуксом управляет один единственный до*боеб, способный забаррикадироваться в своих 80-ых, и единолично принимающий судьбоносные решения, вашему красноглазому сообществу никакой прогресс не грозит. Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #117, #120, #121, #136, #152, #157, #187, #264

115. Сообщение от Аноним (115), 15-Янв-24, 02:23	+5 +/–
В смысле, 'даже'? В плюсах эта фича полноценно появилась только в C++20, когда как в Си с C99 https://en.cppreference.com/w/cpp/language/aggregate_initial...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

116. Сообщение от Аноним (107), 15-Янв-24, 02:30	+/–
А вот кстати про Carbon почти никто не пишет, а он развивается просто бешеными темпами. Так что может быть и не шутка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #122

117. Сообщение от Аноним (107), 15-Янв-24, 02:32	+2 +/–
Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть на примере Мозиллы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #652

118. Сообщение от Аноним (107), 15-Янв-24, 02:37	+/–
А лучше трем символам. Или может восьми, видел и такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #296, #313

119. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:42	+1 +/–
Останавитесь!
Ответить | Правка | Наверх | Cообщить модератору

120. Сообщение от Аноним (120), 15-Янв-24, 02:42	+4 +/–
>Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков. Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #372

121. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:43	+/–
Посмотри вот это видео https://www.youtube.com/watch?v=YyRVOGxRKLg Торвальдс говорит за внедрения раста как раз из-за этого. Но лично он ему не нравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

122. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:46	+/–
> почти никто не пишет, а он развивается просто бешеными темпами Понятное дело, что если обратную совместимость не блюсти, то можно все менять как хочешь. Другой вопрос: вот раст в ядро завезут, должен же быть фриз на версию компилятора, чтобы каждый раз новое ядро не пересобирать новой версией компилятора раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #171

123. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:49	+/–
> Плюс, выразительнее языковые конструкции можно делать. С другой стороны понаделают "выразительных конструкций", а потом разгребать. В большом проекте с большим кол-вом участников чем прямолинейнее конструкции, тем лучше имхо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #237, #631

124. Сообщение от Аноним (-), 15-Янв-24, 02:49	+2 +/–
> От переполнения стэка ни один код не защищён. И ни один код > не защищён от исчерпания памяти. Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора. Есди я динамически аллоцирую память и ее ен было - то там по крайней мере вернут ошибку и я могу ее прочекать. И что-то сделать по этому поводу. Но если это будет void func1 (uint32_t n) {   uint8_t arr[n]; // VLA!   // do something with arr[] here } ...и вызывать func1(10); func1(100); func1(100500); ...  то я вообще не знаю на каком n оно грохнется. И нет никаких способов это узнать, кроме как грохнувшись. Если *alloc еще фэйлить хотя-бы могут, то тут о фэйле узнаем только путем краха/системного факапа. Круто, да? Особенно в кернеле. Вы же будете очень рады что кернел в панику $%^нется без предупрежления, да?! Вместо фэйла внутренних операций, retry выделения памяти и прочих глупостей. >> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. > При таком n, даже если всё в куче будет, на большинстве компов грохнется. В случае динамической аллокации я как бы могу проверить успех операции. А тут сразу крах в репу, обработать нехватку памяти вообще совсем никак нельзя. И поскольку это рантайм параметр - получается код который очень ненадежный, скажем так, и может просто грубо навернуться если параметр неудачный. Без какой либо адекватной обработки этого вообще. > И всё тут. И там и там надо ограничивать разрешённые значения N. Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #138, #139, #140, #146

125. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:50	+/–
Пусть хотя бы драйвер напишет рабочий. А потом сможет в нем баг поправить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

126. Сообщение от Аноним (126), 15-Янв-24, 02:51	+/–
Тьфу, действительно мегабайт, перепутал с гигами. >Тем более запрос через аллокатор никогда не приведёт к сваливаю С выделением на стеке тоже можно проверять, не случится ли переполнения. Но built-inа для этого в компиляторах нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #127

127. Сообщение от Аноним (115), 15-Янв-24, 02:56	+/–
Но почему-то проверок места на стеке нигде нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

128. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:57	+1 +/–
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat. Round 2... Fight! Как бы в отчасти правда, но и ложь тоже. Пустив С++ в ядро им надо будет рядом гайдлайнов накатать какие фичи использовать, а какие нет. Хотя вон гугл в хромиуме вроде смог. Но оно вам надо?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #153

132. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:03	+4 +/–
> За header-only нужно сразу от разработки отлучать с волчьим билетом. Взял и boost опозорил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #151

133. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:04	+/–
> Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений Почему бы это просто в C не добавить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #194, #238, #298

134. Сообщение от Аноним (-), 15-Янв-24, 03:04	–1 +/–
AUTOBOT - это блочит (и я не знаю почему): А как они собираются исключения туда затянуть? (этого сделать вероятно не получится, да и не нужно) А без исключений затянут - это будет не C++, а просто "подмножество" C++ - типа "чуть улучшенный C". Ах да - это они всё ради темплэйтов наверное! P.S. А в Расте есть исключения?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #154, #207

135. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:05	+1 +/–
> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные всем вещи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #175, #387

136. Сообщение от Аноним (105), 15-Янв-24, 03:12	–2 +/–
Че ты несешь? Совет директоров даже если и принимает решения, то не о каждом элементе и в каждой крупной конторе есть жесткая иерархия. Это типо император мать их японии, а это простолюдин. Простолюдин императору нихрена указывать не может потому что лидер может быть только один. Вам дают кость из раста которую разумно можно использовать ради фич типа написания драйверов без ошибок в памяти. То что есть извращенцы которым так проще -хрен с ними. Но каждый червь со своими советами лезущий это не принятие важных решений. То что ты неспособен осилить хоть что-то не значит что кто-то есть твой не так чтобы зашифрованный мат. Черви ничего Линусу не докажут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

137. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:14	+4 +/–
Лучше в твиттер (или как она там называется теперь)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

138. Сообщение от jjklh (?), 15-Янв-24, 03:25	+1 +/–
>Просто крах без предупреждения, в рантайме, кто сказал раст?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

139. Сообщение от Аноним (149), 15-Янв-24, 03:28	–2 +/–
>Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе. Сишечка не системная - также можно исчерпать стек, вызывая функции. Особенно если где-то там, в глубине вызовов, будет на стеке буфер, не VLA, но и не очень маленький - есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда столько, что хватит для переполнения стека. VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #283

140. Сообщение от Аноним (140), 15-Янв-24, 03:29	+1 +/–
В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где нет - его можно сделать. По-хорошему должен быть вариант alloca с проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Но Си - это не раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #292

141. Сообщение от Аноним (140), 15-Янв-24, 03:30	+1 +/–
Сфигали не подходит для ядра, если для сборки под голые микроконтроллеры без разделения на юзерспейс и кернелспейс подходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #158

145. Сообщение от jjklh (?), 15-Янв-24, 03:38	+/–
> У LLVM все прекрасно с поддержкой платформ. > Это GCC поддерживает всяких хлам и некроплатформы ну, ладно выкинут поддержку неподдерживаемых платформ из ядра, потому что, допустим, ядро пишут для llvm, а не наоборот. Но с этим https://clangbuiltlinux.github.io/ что делать? Оно ж тупо не собирает ядро трехлетней давности, Карл!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #226

146. Сообщение от Аноним (149), 15-Янв-24, 03:41	+/–
>Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора. Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта и они ничего не поймают, в продакшоне наконец-то в этот массив запишут из сети 10 байт, запись затрет канарейки и структуры планировщика FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и девайс ребутнется по ватчдогу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #290

147. Сообщение от Аноним (147), 15-Янв-24, 03:41	+/–
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра Это такой лол, что я даже не знаю, что сказать. Но когда пропадёт калабуховский дом, с рожей вонки буду сидеть.
Ответить | Правка | Наверх | Cообщить модератору

148. Сообщение от bOOster (ok), 15-Янв-24, 03:48	+2 +/–
Здравый смысл, наконец-то берет верх..
Ответить | Правка | Наверх | Cообщить модератору

149. Сообщение от Аноним (149), 15-Янв-24, 03:49	+1 +/–
a = {.x = 1, .y = 2}; Вот такой синтаксис завезли только в 20е плюсцы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #240

150. Сообщение от fuggy (ok), 15-Янв-24, 04:44	+1 +/–
Зачем переписывать на C++ чтобы потом пришлось переписывать на Rust умалчивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #155

151. Сообщение от Аноним (115), 15-Янв-24, 04:57	+2 +/–
STL же, boost сама по себе помойка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #213

152. Сообщение от Аноним (115), 15-Янв-24, 05:05	+3 +/–
Линус понимает как нужно вести такой проект, а ты нет. Сейчас практически весь серверный рынок линуксовый, все другие ~юниксы давно на обочине.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #611

153. Сообщение от Аноним (115), 15-Янв-24, 05:07	+1 +/–
Гайдлайны, внезапно, в ядре и для Си есть. Уровень обсуждений далёких от разработки людей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #306

154. Сообщение от Аноним (115), 15-Янв-24, 05:08	+3 +/–
Разумеется, ведь самая главная фича плюсов это исключение
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

155. Сообщение от Аноним (115), 15-Янв-24, 05:13	–1 +/–
На rust переписывать не придётся. Его засунули в ядро чтобы шумные детишки наигрались молча с какой и потом остали от ядра сами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #173, #253

157. Сообщение от Аноним (75), 15-Янв-24, 05:22	+/–
Один процент на десктопах, а не на серверах. И проблема не в ядре
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

158. Сообщение от Аноним (115), 15-Янв-24, 05:25	+2 +/–
Если не подходит, то это же ещё не означает, что не найдутся упоротоые, которые будут готовить из буханки белого троллейбус. Ну и сравнил, конечно, гогнокод под голый контроллер с развесистым ядром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #411

159. Сообщение от Аноним (115), 15-Янв-24, 05:26	+1 +/–
Тогда вам стоит для начала поработать с большими проектами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #172, #250

160. Сообщение от Тот_Самый_Анонимус_ (?), 15-Янв-24, 05:36	–1 +/–
>Шёл 2024 год... О, кто-то календарь перевернул!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

161. Сообщение от Аноним (96), 15-Янв-24, 05:49	+1 +/–
Да уж, беда пришла откуда не ждали... Если что-то и может быть хуже С, то это С++.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #176

164. Сообщение от n00by (ok), 15-Янв-24, 06:45	+/–
> и в каждый бинарь включена своя копия реализации. Подтверждением в виде дизассемблерного листинга не порадуете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #267

165. Сообщение от n00by (ok), 15-Янв-24, 06:48	–1 +/–
> А в чём проблема VLA? Лучше с alloca и указателями для того > же самого геморроиться и статическому анализатору палки в колёса ставить? Проблема в том, что это ядро. Вот скажи, какой там размер стека?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

166. Сообщение от n00by (ok), 15-Янв-24, 06:49	–1 +/–
> От переполнения стэка ни один код не защищён. Дожили. А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #227

168. Сообщение от n00by (ok), 15-Янв-24, 07:07	–1 +/–
Единственная проблема плюсов в ядре -- это привычки и отношение к языку значительной части сишников. И вопрос тут не в том, кто прав, а кто нет. Люди годами писали ядро, потому их точка зрения имеет вес. Однако, после внедрения Rust этот аргумент превратился в тыкву.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #370

170. Сообщение от Аноним (170), 15-Янв-24, 07:22	+3 +/–
Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #197, #397

171. Сообщение от Аноним (175), 15-Янв-24, 07:32	+/–
И карго почти наверняка будет запрещено, а ведь это считай центральная фича языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #243, #440

172. Сообщение от Аноним (172), 15-Янв-24, 07:41	+/–
Насколько большими? Сколько строк?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #303

173. Сообщение от Аноним (173), 15-Янв-24, 07:41	+/–
Тоже так считаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

175. Сообщение от Аноним (175), 15-Янв-24, 07:45	+/–
Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-что от стула.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #317

176. Сообщение от Аноним (172), 15-Янв-24, 07:46	–1 +/–
Поправил, не благодари > Да уж, помощь пришла откуда не ждали... Если что-то и может быть лучше С, то это С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

178. Сообщение от freehck (ok), 15-Янв-24, 07:51	+/–
> Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat Это что, реклама Red Hat между делом? Данному разговору уже не первое десятилетие. > С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin) Сомневаюсь, что люди со стороны могут по предоставленному послужному списку оценить реальную авторитетность мнения данного разработчика. Напишите лучше новость, если Линус или Грег удостоят его мнение ответом. > Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++ А актуален ли вопрос вообще? Недавно читал, что ядро нынче нормально собирается Clang-ом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #402

179. Сообщение от Проходил мимо (?), 15-Янв-24, 08:00	+2 +/–
Судя по комментариям, большинство из тех, кто "поет" на OpenNET про Rust разбираются в нем примерно как свинья в апельсинах. Хотя, возможно, свинья разбирается все же лучше. Хейтеры, которые ниАсилили. Естественно, что у любого, кто в теме вопли всяких криворуких рукожопов вызывают лишь гомерический смех. PS Это не значит, что Rust идеальный и у него нет проблем. Некоторые вещи там сделаны не лучшим образом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

181. Сообщение от Аноним (175), 15-Янв-24, 08:06	+/–
Одни белые лица и в основном мужики, никакого диверсити.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #414

182. Сообщение от Аноним (182), 15-Янв-24, 08:32	+6 +/–
Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. Чтобы не было никакого неявного тормозного кода - лучше юзать char*. Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Они и PHP его бы на писали, если бы можно было.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #185, #220, #268, #332

183. Сообщение от Герман (??), 15-Янв-24, 08:51	–1 +/–
Внедрение плюсов - такой себе шаг вперед
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

184. Сообщение от Герман (??), 15-Янв-24, 08:52	+6 +/–
Вместе с Си и ядром целиком
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

185. Сообщение от Аноним (36), 15-Янв-24, 08:55	–2 +/–
>По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. Можно, но костыльно очень. Или хотите в ядро нечто, наподобие Glib? >На структурах и прописывая весь скрытый в ООП код ручками. Это человеконечитаемо, лапшакод. И зачем для каждого "класса" проделывать ручками одни и те же действия?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

186. Сообщение от awoland (ok), 15-Янв-24, 08:59	+2 +/–
Это у Red Hat всё шуточки первоапрельские, а между тем Эпол, например, вполне успешно и уже давно применяет Embedded С++ для написания системных Kernel extensions (драйверов) в ядре XNU для всей линейки своих OS (macOS, iOS, iPadOS & e.t.c.) ...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #196

187. Сообщение от Аноним (187), 15-Янв-24, 09:00	+/–
Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других. Ничего нового.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

188. Сообщение от poulch (??), 15-Янв-24, 09:09	+1 +/–
Вообще вопрос надо ставить глобально. Зачем ограничения на язык для разработки модулей ядра? Далеко не всякие модули включаются в состав поставки ядра. Если так хочется, то пусть ядро и комплектные модули  будут на С, но сторонние разработчики должны иметь возможность писать на любых языках. Я 20 лет страдал как единственный разработчик на фирме. Либы для разных платформ на С++ с общим кодом практически, а с драйверами вечная боль С++ под вин и С под  линукс. причем лет 15 назад были патчи на ядро которые финские студенты написали емнип которые давали возможность собирать ядро с++ компилятором...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #205, #459

189. Сообщение от 11 (?), 15-Янв-24, 09:18	+1 +/–
«C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.» Linus Torvalds
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #211

191. Сообщение от Аноним (191), 15-Янв-24, 09:23	–1 +/–
Зачем? ибо когда придёт какой-нибудь С++50, который наконец-таки превратится в Rust, - все с недоумением будут чесать репу! ПС: Современный С++, можно охарактеризовать примерно тем, что написано в каждой книге по этому самому современному С++, например: You can use whichever C++ compiler you like. At the time of this writing, no compilers were fully C++XX-compliant yet. Some new features were only supported by some compilers and not others, while other features were not yet supported by any compiler. Compiler vendors are hard at work to catch up with all new features, and I’m sure it won’t take long before there will be full. Это я к тому, нафиг он нужeн, когда уже есть готовый Rust!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #229, #595

192. Сообщение от d_kazbek (?), 15-Янв-24, 09:40	+1 +/–
давно пора
Ответить | Правка | Наверх | Cообщить модератору

193. Сообщение от Noname (??), 15-Янв-24, 09:43	+/–
Руст действительно будет интереснее, а кресты уже показали несостоятельность за годы существования. Когда-то думал, что взлетит D-шка, но увы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #233, #628

194. Сообщение от Аноним (194), 15-Янв-24, 09:44	–1 +/–
Давно есть. Человек просто поумничать хотел
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #361

195. Сообщение от Аноним (194), 15-Янв-24, 09:49	–1 +/–
вот честно... чем пользоваться этой синтаксической ахинеей проще написать в 5 строк скрипт на том же питоне для предвычислений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #279

196. Сообщение от Noname (??), 15-Янв-24, 09:50	+2 +/–
У эппла анально-ректальные стайлгайды и референсы. Во-вторых, эпплы сами выпускают железо и сами пишут под него. В отличии от линпус-зоопарка, у них чёткий список устройств, которые должны работать с теми или иными компонентами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #210, #307

197. Сообщение от Советский инженер (ok), 15-Янв-24, 09:55	+/–
>... но определённо лучше Rust и C++ с этим тоже можно поспорить, т.к. на читиаемость влияет и количество строк и goto всякие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #582

203. Сообщение от Tron is Whistling (?), 15-Янв-24, 10:07	+/–
Ну вообще плюсы в ядре - здраво, но с оговорками. Исключения придётся вымести, по понятным причинам. STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора. С другой стороны, отсутствие STL кстати как раз отпугнёт целую массу тех, кто в не-плюсовый C не осилил.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #239, #274, #285, #334

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

205. Сообщение от Аноним (205), 15-Янв-24, 10:09	+/–
Та же мысль. В Сишный интерфейс функций умеют почти все языки, пусть ядро остается на Си, а модули пишут кто на чем хочет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #246

207. Сообщение от Пряник (?), 15-Янв-24, 10:11	+/–
Пока нашёл там обработку ошибок. То есть функция может вернуть либо результать, либо ошибку. И ошибка при этом вполне себе конретный тип данных, с которым можно дальше работать, например, завершив программу с сообщением или продолжить дальше работать, решив проблему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

208. Сообщение от Пряник (?), 15-Янв-24, 10:16	+/–
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код Я, конечно, не участвую в разработке ядра и не мне решать (как и многим комментаторам тут), но синтаксис С++ будет в разы хуже, чем Rust. Но, к сожалению, ядро пилит кучка ретроградов-неосиляторов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #222, #282

210. Сообщение от beck (??), 15-Янв-24, 10:23	+/–
Винда написана на С++ и работает на огромном зоопарке устройств.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #218

211. Сообщение от n00by (ok), 15-Янв-24, 10:23	+2 +/–
> a lot of substandard programmers use it Линус знатно потроллил. Никто ведь не заставлял принимать "a lot" на свой счёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

212. Сообщение от beck (??), 15-Янв-24, 10:24	+3 +/–
Ядро windows написано на С++. Вопрос об использовании С++ давно закрыт. Это работает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #215, #228, #261, #354, #529

213. Сообщение от n00by (ok), 15-Янв-24, 10:26	+/–
> STL же Любопытно, сколько из присутствующих видели библиотеку Степанова и Ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #275

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

215. Сообщение от Пряник (?), 15-Янв-24, 10:29	+/–
Но даже windows переходит на Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #230, #234

216. Сообщение от n00by (ok), 15-Янв-24, 10:31	+/–
Это гарантируют стандарты и Си, и Си++, а вот смешивание языков может привести к проблемам. Например, наверняка потребуют запретить перегрузку, что бы не вызвать у некоторых культурный шок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

218. Сообщение от Аноним (214), 15-Янв-24, 10:44	–1 +/–
Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось изначально. Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #221, #225, #485

220. Сообщение от n00by (ok), 15-Янв-24, 10:46	+1 +/–
Ядро писали на Си, потому что плюсов тогда толком и не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #329

221. Сообщение от Аноним (214), 15-Янв-24, 10:46	+/–
Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые блобы с кучей костылей чтобы хоть как-то работало. В линуксе на помойные драйвера смотрят криво.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

222. Сообщение от banonymous (?), 15-Янв-24, 10:47	–3 +/–
Как раз неосиляторы и впариают новые языки. Писать на них они тоже не умеют, но в резюме такие детали можно упустить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #256

225. Сообщение от beck (??), 15-Янв-24, 10:51	+/–
Какие полтора типа? Минимум шесть. > её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать Windows не виновата в том, что у тебя лапки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #232

226. Сообщение от Аноним (41), 15-Янв-24, 10:53	–2 +/–
> ну, ладно выкинут поддержку неподдерживаемых платформ из ядра При чем тут все платформы? Зачем тебе новейший драйвер напр. сетевухи на 100Гб на PDP-11 или System/370? Сильно убудет если он не будет там поддерживаться, если он не компилится из-за шланга? Шланг даже m68k тяшет. Приведи пожалуйста пример, отсутствие какой архитектуры - блокер. > Оно ж тупо не собирает ядро трехлетней давности А ты обратил внимание, что андроиды собираются все, кроме android15‑6.6 старыми шлангами? Не задумался почему так? Может просто гугл следит за этим и исправляет в ядре/шланге что нужно? Вот если и в ядре будут следить, то компилится будет. Или ты думаешь что gcc просто самом собой начинает поддерживать все без проблем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

227. Сообщение от n00by (ok), 15-Янв-24, 10:54	+/–
Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #509

228. Сообщение от Аноним (41), 15-Янв-24, 10:56	+/–
> windows > работает Ну, работать та работает. Но вот как работает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #231

229. Сообщение от Аноним (459), 15-Янв-24, 10:58	+1 +/–
Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C++ и почему Раст для них не подходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #284

230. Сообщение от beck (??), 15-Янв-24, 10:58	+2 +/–
В винде архитектура гибридная. Они могут позволить себе какие-то независимые части сделать на более других языках. Поэтому и С, и С++ и С#. И вот даже Rust. С линуксом и его монолитной архитектурою...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #339

231. Сообщение от beck (??), 15-Янв-24, 11:00	+1 +/–
Нормально работает. Десятки миллионов серверов и сотни миллионов десктопов по всему миру. Не говоря уже про например медицинскую технику, управлялки станками и прочие кошерные вещи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #266

232. Сообщение от Аноним (214), 15-Янв-24, 11:01	+/–
>Минимум шесть. Суть в том, что они там были испокон времён, ничего нового, и то на хлам с армом пришлось влить миллиарды миллиардов 15 лет назад, который всё равно оказался нежизнеспособным. >Windows не виновата в том, что у тебя лапки. Ну, тут виноваты windows update и неквалифицированные некомпетентные кадры в microsoft, не сама windows, понятное дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225

233. Сообщение от Аноним (459), 15-Янв-24, 11:01	–1 +/–
Интереснее побаловатся на раз, а так С++ зрелый язык промышленной разработки и продожает активно использоватся, особенно в коммерческой разработке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

234. Сообщение от Аноним (459), 15-Янв-24, 11:08	+/–
Не переходят, а пишут отдельные модули. Там же не идиоты переписывать работающий код в которй инвестированы миллионы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

236. Сообщение от Аноним (236), 15-Янв-24, 11:16	+/–
> ибо сизифов труд Есть же знатоки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #241

237. Сообщение от yet another anonymous (?), 15-Янв-24, 11:19	+1 +/–
Вот, ради интереса, поробуйте объяснить кому-нибудь (да хоть себе) как в Ядре списки и работа с ними сделаны. (это к "чем прямолинейнее конструкции, тем лучше").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #340

238. Сообщение от Аноним (238), 15-Янв-24, 11:20	+1 +/–
C с этими добавлениями называется C++ :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

239. Сообщение от ay8910 (?), 15-Янв-24, 11:22	+/–
Какие ещё целые массы тех, кто в не-плюсовый C не осилил - как они вообще окозались в разработчиках ядра-Линукс ???
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #271, #320, #407

240. Сообщение от _kp (ok), 15-Янв-24, 11:24	+/–
> > a = {.x = 1, .y = 2}; > > Вот такой синтаксис завезли только в 20е плюсцы. Ага.  А если не в исходнике было не {.x = 1, .y = 2, ...}, а в другом порядке { .y = 2, .x = 1, ...}, то надо править исходник, иначе не скомпилирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #363

241. Сообщение от _kp (ok), 15-Янв-24, 11:26	+/–
>> ибо сизифов труд > Есть же знатоки. А что не так? Если ни какими опциями компилятора нельзя избежать правки рабочего исходника и внесения новых опечаток, то вполне мартышкин труд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236 Ответы: #325

242. Сообщение от Вирт (?), 15-Янв-24, 11:26	–1 +/–
> и язык C++ стал лучше Вроде же не 1 апреля еще? Автор цитаты выше Перепил на новый год и думает что наступило 1 апреля? Основное возражение для С++ в ядре было, что он слишком много прячет от разработчика, а для ядра это неприемлимо. И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу. Как, как язык поддерживающий обратную совместимость может стать лучше? Или пометили как устаревшие std::auto_ptr и std::vector<bool> и все, все проблемы решены?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #286

243. Сообщение от yet another anonymous (?), 15-Янв-24, 11:27	+/–
В методичке написано, что это не часть языка и вы можете жить и без него. Но: таки да, r... тащат в ядро, чтобы оно паровозиком для cargo послужило. Без cargo цели достигнуты не будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

244. Сообщение от _kp (ok), 15-Янв-24, 11:30	–1 +/–
a1{1, 2}; Вот не надо подобного. Когда полей в структуре не один десяток, получим нечитаемый говнокод и хорошими шансами на вагон опечаток. a1{.v1=1, .v2=2} - работает в с++, но частично. Давится на порядок полей, и к тому что считает константами. И подобное с Си в С++ не переносится без правки исходника.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #513

245. Сообщение от Аноним (245), 15-Янв-24, 11:32	+/–
Это метастазы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

246. Сообщение от Советский инженер (ok), 15-Янв-24, 11:35	+/–
собственно, а кто запрещает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

247. Сообщение от nc (ok), 15-Янв-24, 11:47	+/–
Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование на шаблонах) попадет в ядро то туши свет. Rust хоть и имеет более непривычный синтаксис чем С++, но все же разработан с учетом опыта многих других языков.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #254, #335, #559

248. Сообщение от Аноним (248), 15-Янв-24, 11:47	+4 +/–
Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #258

249. Сообщение от _kp (ok), 15-Янв-24, 11:55	+3 +/–
Я сейчас почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу. Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов, и более того не требует временных переменных, что облегчает автоматизацию генерации кода. Вне ядра проблема "элегантно" решается мешаниной файлов C и C++ в одном проекте. Каких то причин, кроме религиозных убеждений, доя подобной несовместимости, и подобных - нет. И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С. О другой проблеме - совместемости вызовов. Частичное решение - extern "C". И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для API и библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #305, #341, #352, #367, #450, #554

250. Сообщение от Аноним (194), 15-Янв-24, 12:06	+1 +/–
так вы не делайта свои "большие" проекты в одну портянку....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

251. Сообщение от _kp (ok), 15-Янв-24, 12:17	+/–
> не защищён от исчерпания памяти. >> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. Хорошо, n=55666, но память процесса переполнена. Или переполнена иным, более естественным способом. Что сделает ПО безопасном языке? Да точно так же грохнется,толко некролог подробнее выдаст, но это не точно. Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области стека или его части, но не везде это делается очевидным и удобным способом. Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с частичным сохранением состояния.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #295

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

253. Сообщение от Аноним (253), 15-Янв-24, 12:38	+/–
Раст - навсегда в ядре. Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #302, #362

254. Сообщение от Аноним (253), 15-Янв-24, 12:39	+/–
Да, только раст спасёт ведро линукс!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #262

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

256. Сообщение от Аноним (253), 15-Янв-24, 12:42	+/–
Впарили раст в ядро - корпорации, их ядро, а не неосиляторы. У корпораций нет интересов писать на сишке, потому что им, по их причинам нужен раст. А обычные любители будь-то сишки или раста ничего не решают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #457

258. Сообщение от Аноним (258), 15-Янв-24, 12:45	+/–
Это объясняется легаси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #316, #322

261. Сообщение от Аноним (264), 15-Янв-24, 12:52	+/–
Если так хорошо работает, почему везде линукс? Фактически сиплюсы используются только для игр. Винды - ось для запуска игр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #288

262. Сообщение от nc (ok), 15-Янв-24, 12:53	+1 +/–
Да дело не в том что кто-то чего-то спасет. Языки программирования объективно развиваются. Когда создавали Си, многих возможностей просто не было. Си получился очень удачным, но все-же есть у него и недостатки, и чем сложнее проект тем чаще они вылезают. А вот тащить С++ я бы не стал. Именно потому, что он развивался эволюционно. Добавляли фичи, потом оказывалось что добавили не совсем удачно - добавляли поверх новые, а старые не совсем удачные оставляли... в результате получилось некое нагромождение всякого разного. Постоянное беспокойство за "обратную совместимость" до добра не доводит никогда. А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла. И для новых версий можно было бы не бояться ломающих изменений в языке. Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254 Ответы: #294, #338

263. Сообщение от Аноним (263), 15-Янв-24, 12:54	+/–
ИИ пока что даже простой код генерировать не научился. Если не считать измусоленные факторилы с фибонначи. Куда ему до ядра?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

264. Сообщение от Аноним (264), 15-Янв-24, 12:54	+/–
Форкни ядро и веди его в какое хочешь будущее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

265. Сообщение от aaaaa (?), 15-Янв-24, 12:55	+/–
с gc что будем делать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

266. Сообщение от Аноним (253), 15-Янв-24, 12:55	–1 +/–
по-дефолту в плюсах нет инструментов для безопасной работы с памятью. RAII и smart поойнтерс - это совсем недавно любители плюсов нашкрябали, плюсы - сплошной ансейф. УРА товарщи!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #364

267. Сообщение от Аноним (-), 15-Янв-24, 12:56	+/–
>> и в каждый бинарь включена своя копия реализации. > Подтверждением в виде дизассемблерного листинга не порадуете? Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы. А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #360, #523

268. Сообщение от freehck (ok), 15-Янв-24, 12:57	+/–
> Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. Никакого -- утверждение слишком сильное для сишки. Как минимум из-за неявного преобразования типов. Впрочем, по сравнению с крестами, я склонен согласиться: с крестами неявного кода было бы на порядки больше. > По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Я кстати пробовал так писать на сях. В силу их синтаксиса, к сожалению, получается весьма многословно, и работать с этим не так удобно, как хотелось бы. Впрочем, я склонен считать, что это проблема не собственно Си, а самой концепции ООП в целом. А так, как описываете Вы, ООП успешно добавляется в более высокоуровневые языки: Lisp-ы, ML-и, тот же Perl вон... То есть поинт тут в том, что так делать удобно только в случае использования языков более высокого уровня: причём крайне желательно, чтобы они обладали встроенными инструментами изменения своего синтаксиса. > Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. О том и речь: высокоуровневым языкам -- высокоуровневые задачи, и наоборот. > Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Вот-вот. Тут та же логика, как когда тебя приглашает зайти на чай красивая девушка, но ты не идёшь, потому что она работает в стриптиз-клубе. В том смысле, что выбор инструмента -- это в частности вопрос социальный: архитектор смотрит не только на сам инструмент, но и на сообщество, которое вокруг инструмента сформировалось. И если сообщество ему не нравится -- то и инструмент выбран не будет. По части самого вопроса, тут на самом деле ни черта не ясно, зачем это нужно. Как бы, крестовики спокойно могут и на голом си написать модуль, если им потребуется, ибо всё-таки в некотором смысле одно является субсетом другого. Так и зачем тогда напрягаться, поддерживать какой-то дополнительный интерфейс? Статус-кво вполне удовлетворяет нуждам проекта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #444

270. Сообщение от leap42 (ok), 15-Янв-24, 12:57	+2 +/–
>> Пока с++ не осилит инициализацию структур С++ поддерживает 25 способов инициализации, и это уже само по себе проблема)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #293

271. Сообщение от Аноним (253), 15-Янв-24, 12:58	+/–
Человек не понимает, что ядро пишется корпорациями на деньги корпораций. Им и решать, какой язычок использовать, а какой - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

272. Сообщение от Аноним (263), 15-Янв-24, 13:01	–1 +/–
>метапрограммирование >произвольные вычисления во время компиляции >безопасная работа с памятью Чего только не сделают, лишь бы переизобрести лисп в своем языке... Отправляйте всех любителей оного в нашу палату, пусть лучше на человеческом языке Mezzano OS пилят, а не гробят Линукс своими прогрессивными франкенштейнами.
Ответить | Правка | Наверх | Cообщить модератору

274. Сообщение от Аноним (293), 15-Янв-24, 13:19	+/–
Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает. Например, Vector и Array - большая польза. Хотя бы, чтобы за пределы буфера не выходить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

275. Сообщение от Аноним (293), 15-Янв-24, 13:21	+/–
Покажи, посмотрим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #421

276. Сообщение от Аноним (293), 15-Янв-24, 13:23	+1 +/–
Cartoon
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

277. Сообщение от pv (?), 15-Янв-24, 13:23	+1 +/–
> А зачем вы его постоянно пересобираете? https://bellard.org/tcc/tccboot.html а ведь когда-то можно было и так, игрушечным компилятором размером в 100кБ, написанным изначально вообще для ioccc. да и чего мелочиться, в ядре просто необходим питон, яваскрипт, го, и вижуалбэйсик! и систему сборки ещё обязательно поменять, а то несовременно как-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

278. Сообщение от Аноним (278), 15-Янв-24, 13:25	+2 +/–
> скорее потому, что с++ - надстройка над с Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих на "C с классами" у C++ плохая репутация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #378, #456, #491

279. Сообщение от Аноним (279), 15-Янв-24, 13:25	+/–
И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того же на разных языках и гемороиться с интеграцией питоньего скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, я лучше ranges поюзаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #309

280. Сообщение от Аноним (293), 15-Янв-24, 13:26	+/–
Если и переходить на то семейство, то уж на Стрекозу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

281. Сообщение от Аноним (293), 15-Янв-24, 13:28	+/–
А JVM под чем крутить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #308

282. Сообщение от Аноним (278), 15-Янв-24, 13:28	–1 +/–
> синтаксис С++ будет в разы хуже > к сожалению, ядро пилит кучка ретроградов-неосиляторов И кто же это тут несолилятор, лол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

283. Сообщение от Аноним (-), 15-Янв-24, 13:29	+1 +/–
> Сишечка не системная - Да? А кто у нас тогда системный то? На сях что-то большая часть системщины, бутлоадеры, кернелы, фирмвари, либы, вот это все :). И у других - failure mode еще больше так то. В сях они простые и понятные как правило и их немного. > также можно исчерпать стек, вызывая функции. Особенно если > где-то там, в глубине вызовов, будет на стеке буфер, не VLA, > но и не очень маленький - Одна из причин по которым жирное использование стека в функциях считается чем-то нехорошим, и кернел собирается с варнингом на размер стекфрейма, если что. По моему если у функции стек более кило - нате вам варнинг, во! Кстати с современным компилером допустим сожрать стек рекурсией не так то просто, gcc допирает убрать сохранение-восстановление, копирование объекта и проч - и лианеризует рекурсивный вызов до чего-то типа цикла, с потреблением стека O(1) и временем выполнения O(n). И вот я вкатил рекурсию чтобы проверить работает ли мой детект stack overflow на мк и.. это не падает?! Ах ты ж блин, какой умный компилер! А чо, ассемблерщики, сможете оптимизнуть так же? :) > есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда > столько, что хватит для переполнения стека. Поэтому... 1) Там где это важно чекают stack usage функций. 2) MISRA запрещает рекурсивные вызовы например, и системный софт должен намотать на ус эту идею и так не делать. > VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например. Ну вы то нам покажете что-то лучше? А то уж рекурсию можно на чем угодно, даже на асме, и тот кстати без оптимизаций - не будет линеаризовывать рекурсивный вызов до более плоского цикла и там все грохнется куда охотнее :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

284. Сообщение от Аноним (293), 15-Янв-24, 13:34	+/–
"Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

285. Сообщение от Аноним (278), 15-Янв-24, 13:35	+/–
> STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора. Во всех контейнерах STL можно передавать собственные аллокаторы. Можно хоть для каждого аллокатора сделать свой набор классов, и это будет намного чище и безопасней дёрганий кошмарных malloc'ов и бесконечной ручной проверкой высвобождения всех сырых указателей. STL это вообще по большей части набор шаблонизированного кода, странно это не знать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #319

286. Сообщение от Аноним (278), 15-Янв-24, 13:41	+/–
> И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу. Все способы выстрелить себе в ногу в C++ - это исключительно наследие C. На чистом плюсовом коде (без сырых указателей, сишных строк и функций) выстрелить себе в ногу очень сложно. Правда сишники начинают беситься от ошибок компилятора, и начинают в обход компилятора фигачить свой сишный код, это да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242 Ответы: #314, #454

287. Сообщение от Аноним (293), 15-Янв-24, 13:42	+2 +/–
А модули в Python, D и ещё много где, тоже Microsoft ввела?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

288. Сообщение от beck (??), 15-Янв-24, 13:43	–1 +/–
Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда. Смартфон соединить с ноутом? Производители делают только для винды. Нормальный офис? Винда. Нориальный почтовый клиент с календарями, встречами и прочими плюшками? Опять винда. Управление зоопарком десктопов? Винда. Удалённый доступ с аппаратными ключами? Винда. 99% промышленных софтов, на которых работать можно, опять винда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #312, #342, #343, #392

289. Сообщение от Аноним (293), 15-Янв-24, 13:45	+/–
Засуньте ваш Шланг в... Ядрописатели требуют обязательность сборки GCC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #371

290. Сообщение от Аноним (-), 15-Янв-24, 13:45	+/–
> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта > и они ничего не поймают, в продакшоне наконец-то в этот массив > запишут из сети 10 байт, запись затрет канарейки и структуры планировщика > FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и > девайс ребутнется по ватчдогу. Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно. ...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers. ...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #345, #358

291. Сообщение от Аноним (293), 15-Янв-24, 13:49	+1 +/–
Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, следовательно, не едет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #304, #311

292. Сообщение от Аноним (-), 15-Янв-24, 13:50	+1 +/–
> В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где > нет - его можно сделать. По-хорошему должен быть вариант alloca с > проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Просто вопрос был почему VLA не рекомендуют в системщине. Ну вот потому. В сях вообще нет ни слова про "stack" в спеках. И, в принципе, VLA не обязан жить именно в стеке. Однако проблема того что память не бесконечная а какая-то реакция на ее нехватку невозможна - остается в любом случае. > Но Си - это не раст. Что-то мне подсказывает что у хруста других failure modes - на десяток си хватит. Они вон там свой panic любимый едва законопатили, меняя чуть не сорц компилера аж когда оказалось что в ядре panic это не оч хороший способ реакции на нехватку памяти. Там же и сказочные костыли с try-вариантами конструкций. Господи, какой бастардизированый гибрид сей с которыми боролись и чего-от из плюсоты, все хучшее от обоих миров - в один яп?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #375

293. Сообщение от Аноним (293), 15-Янв-24, 13:52	+/–
В 20 сишную .fild_name=100 запилили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

294. Сообщение от Серб (ok), 15-Янв-24, 13:57	–1 +/–
> А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла. А опция --std компилятору не подойдет? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #331

295. Сообщение от Аноним (-), 15-Янв-24, 14:00	+1 +/–
>> не защищён от исчерпания памяти. >>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. > Хорошо, n=55666, но память процесса переполнена. > Или переполнена иным, более естественным способом. Я знаю что сделает нормальный системщик. 1) Запретит такую конструкцию если без нее можно обойтись. 2) Если нельзя, аллоцирует динамически - и проверит успех. А если неуспех, что-то сделает по этому поводу, от вываливания из программы до retry через некоторое время в надежде что память освободилась (так например некоторые БД делают, вместо того чтобы сразу завернуть, предпринимают несколько попыток, и сдаются только если за энное время не полегчало). > Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области > стека или его части, В обычных программах примерно то же самое известно как какой-нибудь SIGSEGV и в POSIX эта модель по сути и остается. Проц получает исключение от MMU, и кернел в общем то гейтует его программе как сигнал SIGSEGV. Дефолтный хэндлер просто вырубает прогу, но можно и свой прицепить и сделать что-то более продвинутое. Однако если вам приехал fault handler по причине "стек кончился" - ну, э, удачи в корректном возобновлени работы программы. Ведь стека уже не хватило, состояние в "основном потоке" в общем то уже урыто. Корректного гарантированого способа вернуться их хэндлера в основную тушку на этот момент уже не существует в общем случае. > Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с > частичным сохранением состояния. Окончание стека это весьма грубый системный факап. Ведуший к очень голимым последствиям. Тойота проверяла. Получив class action lawsuit от злющих родственников усопших водил и тех кому острые ощущения от вождения не понравились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

296. Сообщение от Аноним (296), 15-Янв-24, 14:03	+1 +/–
В ядре как раз-таки 8
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #451

297. Сообщение от Аноним (-), 15-Янв-24, 14:10	+/–
> Всего лишь 100Мб, не грохнется. 1) Ну попробуй так на AtMega какой-нибудь :). Правда, грохаться этот убогий не умеет чисто технически, ибо хардварных exceptions у авр нет как класса - но каким-нибудь интересным глюком в корчах в его фирмваре наверное воздастся. 2) Даже если это ОС - а ты уверен что сто мегов в вот именно стеке процесса таки дадут? > Тем более запрос через аллокатор никогда не приведёт к сваливаю Это не обязан быть запрос через аллокатор... одна из причин по которым операции на стеке быстрее операций в heap. Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Антифича состоит в том что вы не можете узнать прокатило это или нет иначе как fault handler'ом "все пропало шеф!" в тыкву (или жесткими глюками если оно так не умело).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #326, #533

298. Сообщение от Аноним (115), 15-Янв-24, 14:16	+/–
Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си как был бревном, так им и остался.  С другой стороны, плюсы постепенно движутся куда нужно, но медленно. Скорее уж в плюсах появится ABI, чем в Си занесут новые фичи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

299. Сообщение от Аноним (299), 15-Янв-24, 14:26	+2 +/–
header-only библиотеки конечно можно написать так, чтобы они замедляли компиляцию. но так обстоит дело с чем угодно почти. так что просто нужно писать грамотно и ничего замедлятся не будет. такая байка, что компиляция будет очень долгой из-за ho пошла еще со времен кода в духе александреску. ситуация уже давно изменилась а байка осталась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #377, #418

300. Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 14:26	+/–
Marusya на подходе :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #324

301. Сообщение от Аноним12345 (?), 15-Янв-24, 14:28	+2 +/–
хруст до добра не доведет
Ответить | Правка | Наверх | Cообщить модератору

302. Сообщение от Аноним (115), 15-Янв-24, 14:28	+1 +/–
Ничего нигде не бывает навсегда, ты сам тут не навсегда. Как засунули, так и уберут. Тем более если говорить о языке в ядре, на котором пока что ничего важного нет кроме hello world. И если оно уже на Си и хорошо работает, значит вполне себе альтернативы есть - тот же Си. Учись рассуждать у мастера логики. >  А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие. Несёшь какую-то чушь, но можно поговорить об интеграции. Как уже заметили в обсуждении, c++ проще интегрируется в существующий код - точнее, интегируется, а rust - нет. У rust в лучшем случае какое-то время будет ниша штучных драйверов. Если рядом с rust появятся плюсы, то большинство разработчиков просто пойдёт по пути наименьшего сопротивления и выберет c++. А объяснить зачем нужно менять правильно приготовленные плюсы на rust уже намного сложнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #310

303. Сообщение от Аноним (115), 15-Янв-24, 14:31	+/–
Настолько, что какой-нибудь sloccount не посчитает за разумное время
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

304. Сообщение от rmh (?), 15-Янв-24, 14:34	+2 +/–
>Лучше пробелы Не лучше. Таб = 1 байт, пробелы >1 байта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #521

305. Сообщение от Аноним (-), 15-Янв-24, 14:35	+1 +/–
> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, На самом деле очень зависит от. И может являть собой и memset или memcpy в определенных случаях. Одна из ключевых причин по которым gcc требует от freestanding memset и memcpy - операции с структурами. Если не предоставить вон то, билд фирмвари может отвалиться с ошибкой линковки в взявшемся "изниоткуда" вызове memcpy/memset. > в отличии от конструкторов, На сях можно вполне сравнимо: typedef struct my_data_t {     uint32_t a;     uint16_t b;     uint8_t arr[10]; } my_data_t; my_data_t defaults(void) {     my_data_t ret;     ret.a = 10;     ret.b = 20;     ret.arr[5] = 42;     return ret; } ... my_data_t someting = defaults(); // constructor-like entity. Нужно ли так делать - "on case by case basis" конечно же. Причины те же что и у плюсеров, т.е. вкатить в "начальные значения" что-то "активно вычисляемое" что не удалось оформить компилтайм выражениями. Скажем нечто вычисляемое в зависимости от runtime переменных. > и более того не требует временных переменных, что облегчает автоматизацию генерации кода. Опять же - это все сильно зависит от того что и как сделает программер и не является универсальным неотъемлимым и безусловным свойством "си вообще". Сишка забевен тем что в силу простоты, он - мультипарадигменный. Куда хотите, туда и вертите. > И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С. Ну вот кстати да. Чтобы C был именно subset БЕЗ оговорок. > И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для > API и библиотек. В конечном итоге хруст, а вроде еще D, и кто там еще умеющие вызывать плюсоту что-то такое и делают :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #505

306. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 14:36	+1 +/–
Для с++ они увеличатся на порядок из-за возможных фич языка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #328, #356

307. Сообщение от awoland (ok), 15-Янв-24, 14:37	+/–
Во-первых, стайлгайды и референсы не имеют никакого отношения к технологиям программирования. Это чистая политика компании. Во-вторых, пример успешного написания кучи драйверов энтузиастами-хакинтошниками для железа, которого никогда отродясь не было в железе Эппле чётко доказывает, что и второй ваш довод является примером газификации луж...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #349

308. Сообщение от Аноним (115), 15-Янв-24, 14:37	+1 +/–
Под lisp-машиной
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #388

309. Сообщение от Аноним (-), 15-Янв-24, 14:47	+1 +/–
> И огрести на ровном месте проблем, в частности тащить 2 реализации одного > и того же на разных языках и гемороиться с интеграцией питоньего > скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, > я лучше ranges поюзаю. А потом через полгода выйдет новый пихон - и вообще сборочница сломается. Питонженетормозит и у него отличная совместимость между версиями. Вам что, впадлу чтоли код подправить? Да, блин, знаете, когда начинает сыпаться с 9000 разных сторон - таки, впадлу!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279 Ответы: #357

310. Сообщение от Аноним (253), 15-Янв-24, 14:51	+/–
Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали раст. Платиновым спонсорам нужен раст, а плюсы им не нужны. Вот так вот...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302 Ответы: #323

311. Сообщение от Аноним (313), 15-Янв-24, 14:52	–2 +/–
> не зависит от настроек редактора кода и, следовательно, не едет. Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #391

312. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 14:55	+/–
Не хочется тебя расстраивать, но это не от того, что винда хорошо работает. Это бизнес, ничего личного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #336, #353

313. Сообщение от Аноним (313), 15-Янв-24, 14:58	+/–
Яваскриптеры голосуют за два пробела. В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

314. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 15:00	+/–
> начинают беситься от ошибок компилятора А кто не начнёт, когда в шаблонном коде  получаешь ошибку в коде кишок?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286

315. Сообщение от Аноним (313), 15-Янв-24, 15:01	+/–
Вы бредите. Табуляция - это табуляция, ОДИН символ. Что значит "равной 4 символам"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #321

316. Сообщение от Аноним (313), 15-Янв-24, 15:05	+2 +/–
Могу назвать ещё минимум две причины, по которым ls -l Лучше, чем list-files-and-directories --show-as-much-details-as-possible
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #382

317. Сообщение от Аноним (313), 15-Янв-24, 15:07	+4 +/–
> заставил оторвать кое-что от стула Пару ножек?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

318. Сообщение от Аноним (313), 15-Янв-24, 15:11	+/–
> то ему придётся признавать 3 вещи: - что теперь программисты N-го сорта допущены в ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #368

319. Сообщение от Tron is Whistling (?), 15-Янв-24, 15:11	+/–
Соглашусь только за C++20. Хотя да, в принципе о нём и речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285

320. Сообщение от Tron is Whistling (?), 15-Янв-24, 15:12	+/–
Цель как раз в том, чтобы они в них и не оказались :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

321. Сообщение от Аноним (115), 15-Янв-24, 15:17	+2 +/–
TAB это терминальный опкод, а не символ. Ровно как и все ASCII символы до 0x20 не символы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315 Ответы: #376

322. Сообщение от Аноним (115), 15-Янв-24, 15:23	+/–
Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #439

323. Сообщение от Аноним (115), 15-Янв-24, 15:28	+/–
Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо С++ и Go, тогда можно будет считать что  выбрали. Пока что это местячковые потуги, как и со всеми остальными модными технологиями. И опять таки, ничего не бывает навсегда, особенно у корпораций: у них бабла много и не жалко выкинуть игрушку на помойку в любой момент
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

324. Сообщение от Аноним (293), 15-Янв-24, 15:30	+/–
Сначала Алиса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300 Ответы: #333

325. Сообщение от Котофалк (?), 15-Янв-24, 15:30	+1 +/–
Строго говоря разница усматривается. Сизифов труд это бесконечное наказание, мартышкин труд - бесполезное развлечение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

326. Сообщение от Аноним (115), 15-Янв-24, 15:34	–1 +/–
Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? Речь про кучу, если вдруг проблемы с чтением > Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны железа самая топорная
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297 Ответы: #405, #426

327. Сообщение от Котофалк (?), 15-Янв-24, 15:35	+/–
а вот VLang мысль и в самом деле интересная. Но, но что там с архитектурами, отличными от x86?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #498

328. Сообщение от Аноним (293), 15-Янв-24, 15:35	+1 +/–
Пусть определятся, какие фичи в ядре допустимы. По тем и пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #306

329. Сообщение от Аноним (293), 15-Янв-24, 15:37	+/–
Ну были, конечно, уровня Borland C++. А вот был ли свободный g++ в 1991, не знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220 Ответы: #412, #547

330. Сообщение от Котофалк (?), 15-Янв-24, 15:39	+/–
> Я за ядро на Java. Только на java-процессоре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #384

331. Сообщение от nc (ok), 15-Янв-24, 15:40	+/–
Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не подойдет. Кроме того, хранение версии языка отдельно от исходника само по себе плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #337, #346

332. Сообщение от Аноним (115), 15-Янв-24, 15:43	+1 +/–
c++ это не либа работы со строками. Причины совершенно в ином - нет API и нет гарантий на оптимизации сахара. Тем более если ещё брать c++ образца начала 2000, то вообще ужасный ЯП с минимум оптимизаций сахара компилятором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

333. Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 15:46	+/–
> Сначала Алиса такими темпами не видать нам Katyusha :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #324

334. Сообщение от Аноним (115), 15-Янв-24, 15:47	+/–
Вместо STL будет своя либа с примитивами в c++ стиле. STL для ядерных целей не подходит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

335. Сообщение от Аноним (115), 15-Янв-24, 15:52	+3 +/–
rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хотелось подёргать хипстерам из команды разработчиков. Другими словами, разработан с учётом опыта языков с низким практическим применением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

336. Сообщение от Аноним (-), 15-Янв-24, 15:55	+/–
Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду? 2 самых распространенных DE копируют решения из МАС оси и винды. Или ты хочешь, чтобы бедный врач пердолился с гентой или другими маргинальными дистрами? Искал дрова к специфическому оборудованию типа ЭЭГ/ЭКГ? В цивилизованных странах будет еще какая-то платформа для командной работы. Назови какое-то нормальное опенсорс решение (без шуток было бы интересно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312 Ответы: #344

337. Сообщение от Аноним (115), 15-Янв-24, 15:56	+/–
Это само по себе хорошо т.к. не нужно править дохринилиард прагм во всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать каждый исходник версией, просто невозможно придуамать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331 Ответы: #561

338. Сообщение от Аноним (115), 15-Янв-24, 15:58	+1 +/–
> Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код. В результате программисты просто бы никуда не переходили. Совместимость со старыми стандартами и так достаточно глубокая по вермени. Проблемы обычно возникают с некорректным использованием поюсов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262

339. Сообщение от Аноним (115), 15-Янв-24, 16:00	+/–
Пиши драйвера в пр-ве пользователя на чём угодно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

340. Сообщение от Аноним (194), 15-Янв-24, 16:27	+/–
вы точно программист ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

341. Сообщение от Аноним (341), 15-Янв-24, 16:29	+1 +/–
> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов А можно пример, чтобы это было так не только с -O0? Зачем компилятору вызывать конструктор, когда он может применить оптимизации? Можно этот переделать: https://godbolt.org/z/Y4G554zdr
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #580

342. Сообщение от Tron is Whistling (?), 15-Янв-24, 16:32	+1 +/–
Всё очень просто. На интерфейсе для врача - винда. В МРТ, на рентгене, в аппарате УЗИ. А вот внутри аппарата - либо линуха, либо RTOS'ы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #427

343. Сообщение от Tron is Whistling (?), 15-Янв-24, 16:33	+/–
То есть винда тебе только картинку рисует, всеми же серьёзными задачами занимаются совершенно другие ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #435

344. Сообщение от Tron is Whistling (?), 15-Янв-24, 16:35	+/–
Путаешь интерфейс и подложку. На подложке в этих же аппаратах - далеко не винда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #336 Ответы: #350

345. Сообщение от Tron is Whistling (?), 15-Янв-24, 16:42	+/–
Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта на обоих модулях - основном и запасном...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #413, #431

346. Сообщение от Серб (ok), 15-Янв-24, 16:49	+/–
> Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не > подойдет. Странно, но именно для этого его и используют. Конечно там включается до.. гхм... очень много дефайнов, которые можно учесть в исходниках. > Кроме того, хранение версии языка отдельно от исходника само по себе плохо. Чем? Вносимые в язык изменения продуманы так, что если что-то работает - то будет работать. Если что-то не работает - то оно не соберётся и ты вынужден будешь внести изменения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331

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

348. Сообщение от PnD (??), 15-Янв-24, 17:00	+/–
Немного не так. Зашкварился на rust? Всё, теперь c++ отказать — не по понятиям. (Далее, остальные в очередь.) </trollFace>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

349. Сообщение от Noname (??), 15-Янв-24, 17:03	+/–
> хакинтошниками И ты ещё что-то там про газификацию луж пишешь? Лол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #307

350. Сообщение от Аноним (-), 15-Янв-24, 17:18	+/–
Возможно, но например банкоматы я встречал на винде. Винда IoT Core вполне достаточно большому кол-ву медицинской техники. Я уже молчу про Windows CE) Хотя объективно для серьезного аппарата (типа радиотерапия или КТ) я бы постремался использовать ядро линукс. Уж лучше пусть будет какой-нибудь РТОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #344 Ответы: #365

351. Сообщение от Аноним (341), 15-Янв-24, 17:20	+1 +/–
Помимо политики была ещё одна причина - исключения в C++, хотя Линус тогда* не говорил, почему нельзя использовать плюсы без них. * https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.231.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #530

352. Сообщение от pavlinux (ok), 15-Янв-24, 17:21	+1 +/–
> ... почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу. >  аналогичное extern "CPP", Пейсатель,  CPP - это C PreProcessor,   CXX - для плюсов )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

353. Сообщение от Аноним (353), 15-Янв-24, 17:37	+/–
Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за минимальную стоимость, ничего личного. Будет это линукс, винда, или ещё что-то - бизнесу неважно. А построением мирового open-source коммунизма пусть занимается кто-то другой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312

354. Сообщение от Аноним (115), 15-Янв-24, 17:39	+2 +/–
Ядро винды написано на Си
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

355. Сообщение от Миллион глаз (?), 15-Янв-24, 17:53    Скрыто ботом-модератором	+/–
https://habr.com/ru/articles/786366/ Забавное в комментах, все что нужно знать
Ответить | Правка | Наверх | Cообщить модератору

356. Сообщение от Аноним (115), 15-Янв-24, 17:56	–2 +/–
Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #306 Ответы: #425

357. Сообщение от Аноним (115), 15-Янв-24, 17:58	+/–
В пакетах всё ещё можно поставить второй питон. Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно - любая кодогенерация зло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309 Ответы: #394, #424

358. Сообщение от Аноним (341), 15-Янв-24, 17:59	+/–
Как я понял твои ответы. - Если мы используем массив со статическим временем жизни, то мы надеемся, что стек не переполнится. - Если мы используем обычный массив на стеке, то мы надеемся, что стек не переполнится. - Если мы используем VLA-массив, то много энергично говорим и надеемся, что стек не переполнится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #434

359. Сообщение от DEF (?), 15-Янв-24, 18:05	–2 +/–
Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. C++ такой же морально устаревший динозавр, как и C, просто еще более уродливый и окостыленный. Вот Rust, Carbon или Zig - более лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры этого языка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #369, #386, #558

360. Сообщение от Аноним (293), 15-Янв-24, 18:12	+/–
А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #461

361. Сообщение от Аноним (293), 15-Янв-24, 18:14	+/–
Шаблонов нет, а compile-time вычисления есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

362. Сообщение от Аноним (293), 15-Янв-24, 18:18	+1 +/–
>Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253

363. Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:23	+3 +/–
Все правильно, ибо нефиг создавать ложное впечатление, есть же строгий порядок инициализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240 Ответы: #469

364. Сообщение от Аноним (115), 15-Янв-24, 18:26	+1 +/–
> RAII ... was developed for exception-safe resource management in C++ during 1984–89 Очнись, наркоша. Смарт поинтеры в плюсовых проектах уже более 30 лет в том или ином виде, до стандартного STLя доехали лет 13 назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266 Ответы: #494

365. Сообщение от Tron is Whistling (?), 15-Янв-24, 18:27	+/–
Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта для кард-ридера и денег.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #350 Ответы: #366, #654

366. Сообщение от Tron is Whistling (?), 15-Янв-24, 18:28	+/–
В самом аппарате, который деньги выдаёт, контроллеры бывают разные, но они автономные. Где-то возможно и линуха даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #365

367. Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:29	+/–
Про 0 тактов - constexpr ctor.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #373, #471

368. Сообщение от Аноним (368), 15-Янв-24, 18:33	+/–
Тут у Линуса осталось 3 варианта действий: 1. покаяться за вред, нанесённый проекту, и извиниться перед крестовиками. Будет больно и неприятно, но возможно тогда его оставят. Возможно... Не значит, что гарантированно. Тут главное - грамотно обосновать, почему смена руководства нанесёт проекту больше вреда, чем пользы. Если обоснует - то останется. Но лицо потеряет. 2. играть в несознанку и дожидаться, пока всех доставшего эгоиста прирудительно не снимут. 3. одобрить включение C++ в проект и попытаться замять историю с балабольством. Не выйдет - история широко известная, тут же найдутся те, кто включит аргумент "раз программисты на C++ плохие, то зачем ты их в ядро допустил, лидер ты наш Акелла? если они вдруг стали хорошими, хотя мы все знаем, что с обыдлением всё становится хуже, то как же так получилось, что твои слова противоречат реальности, может ты просто не хочешь признавать свою ответствееность за свой базар и свои действия? Зачем нам такой лидер?" Линус загнал себя в цугцванг сам своим безответственным поведением. На мой взгляд ему наиболее выгодно идти по пути 1. Но это сторонний взгляд, что в башке у Линуса - никто не знает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318 Ответы: #410

369. Сообщение от Аноним (194), 15-Янв-24, 18:35	+1 +/–
Никаких новых парадигм в расте нету.Тогда уже лисп давайте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359 Ответы: #428

370. Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:36	+/–
То, что будет возможность писать на плюсах совсем не означает, что толпы молодёжи (уже смешно) побегут яростно переписывать все ядро. Так что как пилили деды свою сишную часть, так и будут, пока (если) не будет вытеснена чем-то более актуальным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #379, #543, #638

371. Сообщение от Аноним (371), 15-Янв-24, 18:39	+1 +/–
Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому анализу, удобству использования и скорости результирующего кода. Тех же концептов до сих пор нет, и это создаёт проблемы для кода, который написан под gcc. Если шлангоспецифичные расширения не юзать - то gcc соберёт то, что собирается шлангом. Поэтому ориентироваться надо именно на собираемость шлангом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289 Ответы: #383

372. Сообщение от Аноним (-), 15-Янв-24, 18:44	+/–
> Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не > грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Вас услышали! В новом нотпаде уже встроено. Он теперь поди по сети отсылает каждое нажатие клавиши с 100% легитимной отмазкой :). Вы же не могли жить без AI в нотпаде, правда?! :) > Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится. Вон вам чудный новый нотпад от майкрософта. Зато глаза правильного цвета, и стыд их видимо не ест :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

373. Сообщение от Аноним (115), 15-Янв-24, 18:45	+/–
consteval
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367

374. Сообщение от Аноним (293), 15-Янв-24, 18:47	+/–
Да чё там думать, пусть берут эту схему из g++. Кстати, кто-то как-то приводил документ из недр Мелкомягких, где они это и предлагали сделать на уровне языкового стандарта. Сейчас не могу найти ту ссылку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

375. Сообщение от Аноним (375), 15-Янв-24, 18:48	+/–
>VLA не обязан жить именно в стеке Локальные переменные живут в стеке. VLA в принципе может жить где угодно, но нужен он именно на стеке. >Они вон там свой panic любимый едва законопатили panic!ует код тогда, когда не обработана ошибка, в частности наиболее распространённый случай - когда на std::result вызывают unwrap. В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, либо к kernel panic. rust это просто подсвечивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #429

376. Сообщение от VladSh (?), 15-Янв-24, 18:50	+1 +/–
Ну пусть будет 1 оп. код вместо четырёх; есть же разница?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #321 Ответы: #453, #520

377. Сообщение от Аноним (375), 15-Янв-24, 18:50	+/–
Это не байка. Ты на своей шкуре это сможешь заценить, подключив в программу CLI11.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299

378. Сообщение от Аноним (375), 15-Янв-24, 18:52	+/–
Давайте классы на GовноObject делать, так определённо лучше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278

379. Сообщение от Аноним (379), 15-Янв-24, 18:56	+/–
Толпам молодёжи (и немоложёжи) вообще срать на ядро, они от него в принципе с удовольствием подальше держаться будут. Но не всегда есть такая опция. Драйвер сам не напишется... Нужен нормальный плюсовый фреймворк для драйверов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370 Ответы: #545

380. Сообщение от Аноним (293), 15-Янв-24, 18:56	+1 +/–
Зачем конкретному ядру бинарная совместимость? Эту версию ядра или другую можно полностью с модулями пересобрать другой версией компилятора. Стороннние модули тоже можно пересобрать нужной версией. Про какие блобы речь? Если загружаемые прошивки в девайсы, то пофиг, чем оно там для них собиралось. Оно с кодом ядра линковаться и не будет. Если блободрайверы, так это же хорошо. Мейнтейнеры ядра и так всеми силами борются с блободрайверами. Это им только в помощь. Пусть вендоры приучаются выпускать открытые драйвера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #416

381. Сообщение от Товарищ (?), 15-Янв-24, 18:57	+2 +/–
Нет, к чёртовой матери таких товарищей.
Ответить | Правка | Наверх | Cообщить модератору

382. Сообщение от Аноним (-), 15-Янв-24, 18:59	+2 +/–
> Могу назвать ещё минимум две причины, по которым > ls -l > Лучше, чем > list-files-and-directories --show-as-much-details-as-possible Вы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #316 Ответы: #393, #586

383. Сообщение от Аноним (293), 15-Янв-24, 19:01	–1 +/–
Если разработчики ядра захотят обязательно эти концепты, то разработчики GCC пойдут навстречу. Почему нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #371 Ответы: #467

384. Сообщение от Аноним (293), 15-Янв-24, 19:03	–1 +/–
А Lisp-машину на чём? Гусары, молчать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #515

385. Сообщение от Аноним (-), 15-Янв-24, 19:03	+/–
> К сожалению, нет. Я и говорю что некому топить за него. > Топить - не только в рассылках писать "а давайте zig", а именно > допилить до применения в ядре. > Основа там заложена очень крутая. Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #423

386. Сообщение от Аноним (386), 15-Янв-24, 19:04	+1 +/–
1. Раст требует грёбанного тулчейна. 2. Хотя-бы потому, что на крестах доступны растопримитивы и это позволит инкрементно переводить код на раст. То есть сначала потихоньку сишный код переписывается на кресстовый. Потом крестовый приводится к растоподобному стилю. Потом переписывается на раст, фиксятся баги компиляции, фиксы бэкпортируются на кресты. Каждый патч проходит ревью. Тем самым обеспечивается преемственность, последовательность и контроль на каждом этапе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359 Ответы: #496, #508

387. Сообщение от Аноним (-), 15-Янв-24, 19:06	+3 +/–
>> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. > Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные > всем вещи? А в rust что-то вообще СТАНДАРТИЗОВАНО?! У него ж ни единой версии стандарта нет. По крайней мере от нормальных standard body. Не, куча хипстеров хаотично корежащих синтаксис под заскоки левой своей пятки и приказ своего корпо-хозяина - это не оно. Вообще совсем. И вот как-то так получается что у хруста нет вообще ни 1 стандарта. В отличие от C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #395

388. Сообщение от Аноним (293), 15-Янв-24, 19:10	+/–
А Lisp-машину на чём? Гусары, молчать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308 Ответы: #417

390. Сообщение от Аноним (-), 15-Янв-24, 19:12	+/–
> У LLVM все прекрасно с поддержкой платформ. > Это GCC поддерживает всяких хлам и некроплатформы BSDшники уже пробовали рассказывать сказку про (не)нужные всем фичи. И где они теперь? Вот и вы туда же с этим всем отправитесь. По тем же причинам. Мне вот например не нужны тулчейны где так внаглую лечат что мне (не)нужно. Я и не буду такими тулчейнами пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

391. Сообщение от Аноним (391), 15-Янв-24, 19:14	+1 +/–
едет, если умственно-ограниченные начинают использовать табуляцию не для индентификации кода (и использовать этот символ строго в начале строки до первого не-пробельного), но и пытаются табуляцией что-то форматировать в середине строки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311 Ответы: #420

392. Сообщение от Аноним (293), 15-Янв-24, 19:17	+/–
>Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда. Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки? А то и ваще б/у.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #484

393. Сообщение от Аноним (341), 15-Янв-24, 19:24	+1 +/–
Наоборот же, powershell показывает, что можно всем угодить изкоробочными алиасами и parameter name matching'ом (-def ниже, как одна из недвусмысленных подстрок, с которых начинается параметр -Definition). > get-alias ls Alias           ls -> Get-ChildItem > get-alias -def get-childitem Alias           dir -> Get-ChildItem Alias           gci -> Get-ChildItem Alias           ls -> Get-ChildItem
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #382 Ответы: #446

394. Сообщение от Аноним (-), 15-Янв-24, 19:27	+/–
> В пакетах всё ещё можно поставить второй питон. Это в каких бы таких пакетах? Поддержку питона2 вынесли сами питоняши еще сколько там назад. Линуксные дистры и вынесли его - они быть святее папы римского не собираются, майнтайня софт за питоняш. > Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно > - любая кодогенерация зло. Оно и видно что там не сломается. В дебиане 12 было аж 3000 чтоли багов на эту тему. Всего-то, блин. Они и задропали половину софта к хренам, им что, больше всех надо?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

395. Сообщение от Советский инженер (ok), 15-Янв-24, 19:35	+/–
типа на стандартном С можно ядро написать!? вот умора, язык разработан для написания ядер и прочей системщины более 50 лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не собираются. и эти же "стандартизаторы" вещают про стандарты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #387 Ответы: #445

397. Сообщение от warlock66613 (ok), 15-Янв-24, 19:53	+/–
И Rust и C++ более выразительные языки чем C, и именно поэтому код на них гораздо проще читать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #585, #635

398. Сообщение от warlock66613 (ok), 15-Янв-24, 20:02	+/–
Это уже помойка будет какая-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

402. Сообщение от ИмяХ (ok), 15-Янв-24, 20:08	+/–
>>ядро нынче нормально собирается Clang-ом. Это как раз именно потому, что в нём нет С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

404. Сообщение от Аноним (293), 15-Янв-24, 20:21	+/–
Гугель говорил, что Carbon будет собирать и код писанный для C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

405. Сообщение от Аноним (-), 15-Янв-24, 20:23	+/–
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326

406. Сообщение от Аноним (-), 15-Янв-24, 20:25	–1 +/–
> First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax Или это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #499, #574

407. Сообщение от Аноним (293), 15-Янв-24, 20:26	+/–
Сходи к попам, посмотри на их кресты. Пойми, чем плюс отличается от креста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

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

409. Сообщение от Аноним (293), 15-Янв-24, 20:35	+/–
Seed это вот этот https://ru.wikipedia.org/wiki/Seed7 ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

410. Сообщение от Аноним (-), 15-Янв-24, 20:38	+/–
Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?" Более того, а за что каяться? От добавления С++ ядро лучше бы не стало, по аналогии с Сишкой С89 сидели бы на С++98 до 2022 года( Так что никаких смартпойнтеров и прочих даров цивилизации. Более того подозревая, что дудуки пилящие ядро начали бы писать в стиле "как умеют". ИМХО тогда стало бы еще хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368 Ответы: #460

411. Сообщение от Аноним (-), 15-Янв-24, 20:42	+/–
Но, но ведь троллейбус делается из буханки ржаного! В любом случае чистые make файлы это уже анахронизм (кроме некрофагов из ядра)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

412. Сообщение от 22 (?), 15-Янв-24, 20:45	+/–
Был где-то с 87-го: https://gcc.gnu.org/releases.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329

413. Сообщение от nothingaboutdog (?), 15-Янв-24, 20:45	+/–
А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 раз больше, чем искандер-4 (и памяти для искандер-4 строго говоря не хватало, но с учетом ограничений ТТХ кулибины как-то зарелизились)???
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #345

414. Сообщение от Аноним (-), 15-Янв-24, 20:49	+2 +/–
Ты лучше посмотри где они работают) Сплошные майкрософты, гуглы и прочие корпорации. Так что, "что они скажут - так и будет".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

416. Сообщение от ТвойКопетанОчевидность (?), 15-Янв-24, 21:05	–1 +/–
Например, какая-нибудь nvidia тебе поставляет драйвер готовым модулем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #380

417. Сообщение от Аноним (115), 15-Янв-24, 21:06	+/–
Так она уже машина. Или не знаешь что это такое? Тогда википедия в помощь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #388 Ответы: #593

418. Сообщение от Bottle (?), 15-Янв-24, 21:24	+/–
Это не байка. Погугли патчи ядра от Инго Молнара.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299

420. Сообщение от Аноним (313), 15-Янв-24, 21:29	+2 +/–
Фанаты пробелов - это потомки тех, кто в 90-х в офисе вместо настройки первой строки абзаца отбивали этот отступ пробелами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #391

421. Сообщение от Аноним (421), 15-Янв-24, 21:52	+/–
Если долго вглядываться в бездну, бездна начнет вглядываться в тебя. А вообще, всё зависит от прямоты рук. # Непустых строк: $  grep -c \. /usr/include/c++/*/vector /usr/include/c++/13.2.1/vector:131  # GCC /usr/include/c++/v1/vector:3045  # LLVM # Включений: $  grep -c \#include /usr/include/c++/*/vector /usr/include/c++/13.2.1/vector:10  # GCC /usr/include/c++/v1/vector:50  # LLVM
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275 Ответы: #422, #526

422. Сообщение от Аноним (421), 15-Янв-24, 21:55	+/–
$ pacman -Qo /usr/include/c++/*/ /usr/include/c++/13.2.1/ is owned by gcc 13.2.1-3 /usr/include/c++/v1/ is owned by libc++ 16.0.6-1 /usr/include/c++/v1/ is owned by libc++abi 16.0.6-1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #421

423. Сообщение от Витюшка (?), 15-Янв-24, 22:01	+1 +/–
В основном языки имеют одну реализацию. С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты. Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385 Ответы: #442

424. Сообщение от Аноним (421), 15-Янв-24, 22:04	+/–
Итерация свойственна человеку, кодогенерация божественна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

425. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 22:35	+4 +/–
> Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек Вот дока по стилю С в ядре https://www.kernel.org/doc/html/v4.10/process/coding-style.html - в печати 21 страница А4 Вот для примера С++ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines - в печати 679 страниц! С++ гугла https://google.github.io/styleguide/cppguide.html - 89 страниц. Chromium https://chromium.googlesource.com/chromium/src/+/refs/heads/... https://chromium.googlesource.com/chromium/src/+/refs/heads/... https://chromium.googlesource.com/chromium/src/+/refs/heads/... - вот тут 50 страниц Qt https://wiki.qt.io/Coding_Conventions https://wiki.qt.io/Qt_Coding_Style https://doc.qt.io/qt-6/best-practices.html Лень все расписывать, но видно невооруженным взглядом, что там явно не "пару новых страничек"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356 Ответы: #436, #437

426. Сообщение от Аноним (-), 15-Янв-24, 22:45	+/–
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326

427. Сообщение от beck (??), 15-Янв-24, 22:55	+/–
Внутри аппаратов чистое железо с прошивкаме. Накой там ОС?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #342 Ответы: #430

428. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 22:55	+/–
> Никаких новых парадигм в расте нету.Тогда уже лисп давайте Путались в указателях, теперь будут путаться в скобочках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369

429. Сообщение от Аноним (-), 15-Янв-24, 23:02	+/–
> Локальные переменные живут в стеке. VLA в принципе может жить где угодно, > но нужен он именно на стеке. Читайте стандарты си. Там вообще нет упоминания стека, никак и нигде. То что конкретные реализации решили делать так - ну, окей, однако если кто-то сделает это иначе, он - в своем праве. Это implementation defined хрень. Вы не можете уповать на это при написании программы. Поэтому если кто-то вывесит VLA через heap или что там у него - а они в своем праве были. У си довольно интересные стандарты - и далеко не всегда это именно похвала комитету. Спихнувшему более 9000 своих проблем на других. >>Они вон там свой panic любимый едва законопатили > panic!ует код тогда, когда не обработана ошибка, Я так понимаю что паника была дефолтовой реакцией на неуспешные потуги аллокации крупных массивообразных штук, box чтоли, они там называются. И дошли они в результате до костылирования с тем же названием с довеском try отличающим по поведению эту сущность. Я честно говоря не понял почему все так костыльно и почему они так героически заборов дракона вдруг заметили что без него что-то стало хреново - и немедленно превратились в еще более стремного на вид дракона. Пппростите, а чем ЭТО отличалось от *alloc и сотоварищи? Можне мне этот высококонцептуальный пируэт объяснить? В результате маркетинг оказался, как бы это, не совсем правдой. Ибо в итоге пришли к тому с чем боролись. Фэспалм. > в частности наиболее распространённый случай - когда на std::result вызывают unwrap. А в кернеле и вообще embedded, etc вот именно тот std вообще будет? Ибо врядли дефолтовый, из супер-дупер-либы на все оказии делает именно то что уместно делать в недрах кернела. И скорее всего подразумевает работу в нормальной ос. А что если этой нормальной ос еще нет?! > В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, > либо к kernel panic. rust это просто подсвечивает. И я не понимаю почему в wannabe-системном яп потребовались вон те костылищи с отдельными сущностями. Появившимися вот именно после потуг в кернел влезть. И там аж компилер постоянно патчат под это все. Представьте себе что для написания кернела требовалось бы постоянно патчить GCC. Вы бы вообще смогли кернел написать в результате? Да и Торвальдс, пожалуй, тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375

430. Сообщение от Tron is Whistling (?), 15-Янв-24, 23:04	+/–
Прошивки прямо в металле? :D Вы недооцениваете современные прошивки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #427

431. Сообщение от Аноним (-), 15-Янв-24, 23:08	+/–
> Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта > на обоих модулях - основном и запасном... Если это важно - это решается другими методами. См. как это кажется, боинг сделал. Две тимы писали 2 разные программы, запущенные на 2 разных процах, ... вот как раз чтобы вероятность этого была ниже плинтуса. ...у меня, к счастью, не настолько крутые требования, и все же мне охота залезть в довольно требовательные применения, где факап управления может чего-нибудь пожечь и проч, что как бы не прикольно. В этом смысле fail fast с приведением системы в безоапсное состояние лучше чем ждать вачдога в абы каком состоянии, делая хзчто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #345 Ответы: #503, #504

434. Сообщение от Аноним (-), 15-Янв-24, 23:21	+/–
> Как я понял твои ответы. > - Если мы используем массив со статическим временем жизни, то мы надеемся, > что стек не переполнится. И мы можем более адекватно эту идею проверить. Частично даже в компилтайме, смотрением на размер стекфрейма. > - Если мы используем обычный массив на стеке, то мы надеемся, что > стек не переполнится. Это допущение опять же более просто проверить, если нет рекурсии. > - Если мы используем VLA-массив, то много энергично говорим и надеемся, что > стек не переполнится. VLA - это еще хуже чем динамическая аллокация памяти. Потому что это та же динамическая аллокация памяти - но еще и без возможности сделать что-либо осмысленное, и без известного на момент компила upper bound что вообще совсем рубит любой компилтайм анализ этого. Вы вообще не знаете worst case размер стекфрейма этой функции теперь. И таки си - мультипарадигменный. Если ну вот капец как надо - можно сделать "fully static allocation", распределив вообще все статически. Ну то-есть все переменные сделать либо static в функциях, либо глобальными. И тогда - если все выделено сразу на старте, оно не может закончиться вот хоть как. Единственное что остается это глубина вложенных вызовов функций. Это неоптимально по ресурсам - потому что все и вся выделено всегда. Зато гарантии лучше. Вот и выбирайте. Примерно такой же tradeoff существует и в оверкоммите памяти в случае линуха. Можете не оверкомитить и обеспечивать все выделеные адреса физической оперативой. Но тогда сможете намного меньше программ на том же RAM запускать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358 Ответы: #462

435. Сообщение от Аноним (482), 15-Янв-24, 23:22	+/–
Совершенно другие ОС даже не в состоянии нарисовать картинку, ОК.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343 Ответы: #501

436. Сообщение от Аноним (341), 15-Янв-24, 23:29	–2 +/–
> Вот дока по стилю С в ядре "Табы это 8 пробелов..." > Вот для примера С++ "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам библиотеку." > Qt *Что-то не тянущее на 21 страницу*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #425 Ответы: #443

437. Сообщение от Аноним (115), 15-Янв-24, 23:32	+1 +/–
Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь? Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине. В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать чтобы понять что от тебя нужно. CS в хроиуме и Qt как раз несколько страничные и, как в случае с ядерным CS, читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие выводы... 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут чтения 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде гугла, то из этого не следует, что все CS по плюсам будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя подборка показывает обратное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #425 Ответы: #438, #441, #448

438. Сообщение от Аноним (115), 15-Янв-24, 23:33	+/–
^  Так и не понял куда приклеился ответ, он был анониму с ссылками
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #437

439. Сообщение от fuggy (ok), 15-Янв-24, 23:35	+/–
То-то наверно лучше в C++ когда звёздочка обозначает сразу 4 разных операции. А без функциональщины, лямбд современный язык уже не язык. В Rust итераторы более читабельные, чем императивная возня с указателями. В C++ между прочем тоже лямбды есть со своим специфическим синтаксисом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

440. Сообщение от Аноним (-), 15-Янв-24, 23:39	+/–
> а ведь это считай центральная фича языка. Агаблин, обеспечивает вендорлок на гугл, амазон и майкрософт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

441. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 23:45	+/–
>[оверквотинг удален] > горизонтально. И если даже его нормально распечатаешь, а не как ты > через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 > страница ядерного CS читается за пару минут потому что там на > самом деле не 21 страница, по такой же причине. > В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать > чтобы понять что от тебя нужно. CS в хроиуме и Qt > как раз несколько страничные и, как в случае с ядерным CS, > читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому > CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие > выводы... Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут > чтения Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. > 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде > гугла, то из этого не следует, что все CS по плюсам > будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя > подборка показывает обратное. У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем". Конкретно, в хромиуме, одну и ту же вещь можно сделать по разному, используя как std так и тамошний base. Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #437 Ответы: #466

442. Сообщение от Аноним (446), 15-Янв-24, 23:47	–1 +/–
> В основном языки имеют одну реализацию. ...гарантирующую 100% вендорлок, что после си и си++ как бы нефиговый регресс, есчо. > С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Да, нашлись те кого вендорлоки заколебали. И я вовсе не для того пришел в опенсорс чтобы наслаждаться вендорлоками. Сюрприз! Never again! Так что у меня будет или так - или я поюзаю си и си++, мне хватит. > Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят > какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты. Однако вон там уже и borrow checker прорезается. Во всяком случае я вижу какие-то коммиты связанной инфраструктуры. А так Столлман написал первую версию gcc, Торвальдс накатал в 1 лицо Linux, упрямец Кент cow файлуху своротил. Большие вещи начинаются с малого. > Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда > (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄 Ну он так пропихан что пока на него ничего реально не завязано. И кмк решение будет ли на него что-то завязано более плотно - ощутимо зависит от того будет ли gccrs юзабельным или нет. Майнтайнеры линуха тертые калачи и влопаться в вендорлок? Ну, эт, Торвальда уже пробовали так лохануть в Bitbaker. И где этот их bitbaker теперь?...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #423

443. Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 23:50	+1 +/–
>> Вот дока по стилю С в ядре > "Табы это 8 пробелов..." >> Вот для примера С++ > "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам > библиотеку." Мой оригинальный комментарий https://www.opennet.ru/openforum/vsluhforumID3/132575.html#128 содержит слово guideline. Если https://www.kernel.org/doc/html/v4.10/process/coding-style.html мешает понятия code style и guideline, то я не виноват. Для примера гугл также делает. Смотри тогда с ним. Но я говорил именно про гайдлайн и для плюсов там сильно больше надо будет писать. Хотя бы имея ввиду сколько всего добавляется в новых стандартах. Для примера можешь посмотреть доку хромиумуа по ссылке выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #436

444. Сообщение от fuggy (ok), 15-Янв-24, 23:50	+1 +/–
Rust тоже не ООП язык. Вполне себе можно писать крупные проекты и в процедурном стиле, и в ООП, и в функциональном стиле. ООП переоценён, это не золотой молоток. А уж взглянув на Java Enterprise FizzBuzz страшно смотреть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #470

445. Сообщение от Аноним (446), 15-Янв-24, 23:50	+1 +/–
> типа на стандартном С можно ядро написать!? Ну, почти. Режим freestanding официально специфицирован с C99 аж. Там правда пары вещей не хватает, это таки вот именно гнутые экстеншны. > вот умора, язык разработан для написания ядер и прочей системщины более 50 > лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не > собираются. и эти же "стандартизаторы" вещают про стандарты. Потому что в целом код conformant, плюс-минус очень небольшое число мест. А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Наверное так и надо...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #395 Ответы: #500

446. Сообщение от Аноним (446), 15-Янв-24, 23:57	+/–
> Наоборот же, powershell показывает, что можно всем угодить > изкоробочными алиасами и parameter name matching'ом Он мне так угАдил своим синтаксисом, километровыми командами и очешуенным временем старта на виртуалках что я как раз и развидел маздайку к хренам. И назад уже никогда не вернусь, хоть там что. Простите но какую задачу решает (ba)sh я понимаю. Какую задачу решает это индусское месиво я не понимаю. Мне такой шелл - без надобности. Совсем. Одно это уже бьет наповал ваше "всем"  наличием конкретного контрпримера. Не, я в принципе не собираюсь столько на клаве печатать в шелле. А когда там еще и автодополнение такое как там, пути с пробелами, и брейнфак с типизацией (в шелле!!!) - ну, знаете, вот пусть авторы этого и пользуются им.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #393 Ответы: #476

448. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 00:00	+/–
> Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. Оригинально я писал про гайдлайн, а не cs. Если ядро смешивает их, то ко мне какие вопросы. Вон гугл тоже смешивает, сравнивай с ним. > И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине. Ну выстави нужный шрифт и пришли результат. Мне влом этим заниматься. Но там явно не "на пару страничек больше". Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #437 Ответы: #468

450. Сообщение от InuYasha (??), 16-Янв-24, 00:03	+/–
А что плохого в extern "C"? Очень часто используется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

451. Сообщение от InuYasha (??), 16-Янв-24, 00:04	+/–
*стирает исходники ядра пры..линукса* фу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #296

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

453. Сообщение от InuYasha (??), 16-Янв-24, 00:07	+/–
когда я в подном большом проекте заменил все отступы на табы (вместо 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376 Ответы: #477, #482

454. Сообщение от Аноним (-), 16-Янв-24, 00:09	+/–
> Все способы выстрелить себе в ногу в C++ - это исключительно наследие > C. На чистом плюсовом коде (без сырых указателей, сишных строк и > функций) выстрелить себе в ногу очень сложно. А дебильные классические типы целых чисел там как? Их так то и в си неплохо бы выпилить к хренам и сделать по уму, на основе C99 - и с "well defined behavior". Это спасло бы от дохреналиона багов и вулнов на ровном месте. И да - вообще забанить к хренам "int" (signed) как индексы. С расстрелом из реактивного г@вномета за это. Чтобы господам даже чисто теоритически в голову не приходило что в массив можно отрицательный индекс, бдаж!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #502, #514

456. Сообщение от InuYasha (??), 16-Янв-24, 00:10	+/–
как раз наоборот - современный ++ выглядит порой как несто среднее между растом и brainfuck.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278

457. Сообщение от Аноним (459), 16-Янв-24, 00:11	+/–
Что-то по вакансиям не сильно этого заметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #493

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

459. Сообщение от Аноним (459), 16-Янв-24, 00:16	+/–
Тогда как собирать всю эту мозаику? У инструментов будут свои зависимости, а у тех еще зависимости... А так-то я сам не против.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

460. Сообщение от Аноним (460), 16-Янв-24, 01:14	+/–
>Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?" Какой третий? Весь сишный код фиксится до совместимости с clang++  и объявляется плюсовым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410

461. Сообщение от Аноним (460), 16-Янв-24, 01:18	+/–
Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорных инструкций. Нетривиальные находятся в libstdc++.so.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #360 Ответы: #522, #524

462. Сообщение от Аноним (341), 16-Янв-24, 01:39	+/–
Я почему шучу про "много энергично говорим" - потому что идеи assert'ов для размера VLA,  тестирования худшего случая отметаются как немыслимые и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - вот, фрагментация кучи уже лучше, чем VLA. Даже не "так же плоха", как написала бы MISRA, а хуже. > Это неоптимально по ресурсам - потому что все и вся выделено всегда В принципе на этот случай есть union'ы, но с ними придётся следить не за стеком, а за тем, чтобы не было обращений к неактивным полям и чтобы инициализация активного поля нигде не пропускалась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #434 Ответы: #651

466. Сообщение от Аноним (115), 16-Янв-24, 02:03	+/–
> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. Нет гайдлайна, раньше туда тупых не брали. Сейчас пытаешься приклеить документацию по внутреннему устройству проектов к CS по плюсам. Всё же давай начнёшь включать мозг, а? > Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему дизайну либ, вроде как у них устроены координатные сетки - вот это прямо таки самые настоящие СS и guideline-ы по С++ для Qt. Начни всё же включать мозг, если, конечно, он есть. > У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"... Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", а не тратить 80% от CS на трёп с размышлениями каким образом гугл докатился до такого CS-а. Ты же на ревью хочешь чтобы клиент просто затнулся и сделал как принято, а не рассуждал на тему верно это или нет? Потому у гугла CS построен неверно, его только спасает выделение рассуждений в визуально отдельный блок и опытный читатель может его пропускать. Тем более рационализация гугла во многих местах смехотворна, лучше бы просто написали ~ заткись и делай как тут показано. > Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать. Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где исторически в разных местах появились разные CSы. Типичному разработчику всё же хватает интеллекта посмотреть как было до и сделать аналогично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #441 Ответы: #472, #473

467. Сообщение от Аноним (460), 16-Янв-24, 02:10	+/–
в шланге нет концептов, в gcc они есть. Если задействовать код на концептах - то шлангом собираться не будет. А собирать лучше шлангом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #383 Ответы: #590

468. Сообщение от Аноним (115), 16-Янв-24, 02:13	–2 +/–
Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c++ в нём. А значит и рассматривать должен ровно то, что там есть. Логично же, не так ли? > Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна. Можно, но придётся опять включать мозг: большая часть изменений касается STL, которого в ядре не будет если туда завезут плюсы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #448

469. Сообщение от _kp (ok), 16-Янв-24, 02:21	+/–
> нефиг создавать ложное впечатление, есть же строгий порядок инициализации. Если сам с нуля пишешь то обычно да, логичнее писать по порядку, но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок меняется. И конечно уже существующие исходники. Не забываем, что инициализацию структур только только добавили. И еще недавно можно было для больших структур делать или нечитаемую портянку, и как дурак считать каждый раз элементы, что б что то исправить, или мешать с и c++ файлы в проекте. Шаг в сторону улучшения есть, что хорошо, но пока полумеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #363 Ответы: #643

470. Сообщение от Аноним (115), 16-Янв-24, 02:27	+/–
В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в самом деле не киллер фича, но на задачах, где оно нужно, без поддержки ООП тяжко
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #444 Ответы: #478

471. Сообщение от _kp (ok), 16-Янв-24, 02:31	+/–
> Про 0 тактов - constexpr ctor. 1. Да, я это использую. Но не так и редко бывает на ровном месте и constexpr variable must be initialized by a constant expression Особенно во встраиваемом ПО,что по духу ближе к ядру, чем пользовательские приложения. 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей и читаемей? Поэтому, использую не в всегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367 Ответы: #474, #642

472. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:32	+/–
>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > Нет гайдлайна, раньше туда тупых не брали. Просто в конторе не любят писать доку - признай это. Поэтому кичиться cs на 1 страницу не нужно. На самом много где не любят. Спорить на тему ее нужности и самодокументированного кода я не собираюсь:) >  Сейчас пытаешься приклеить документацию по > внутреннему устройству проектов к CS по плюсам. Совсем нет. Я вроде ясно выразился, что для C++ гайдлайны (не кодстайл) придется наисать гораздо больше чем для С. Вот это и нужно обсуждать. В качестве примеров я привел существующие документы проектов.   >> Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. > У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в > основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему > дизайну либ, вроде как у них устроены координатные сетки - вот > это прямо таки самые настоящие СS и guideline-ы по С++ для > Qt. Начни всё же включать мозг, если, конечно, он есть. Ты начинаешь порядком надоедать своей глупостью. По поводу qt есть страница про исключения https://doc.qt.io/qt-6/exceptionsafety.html Но ведь ты даже не удосужился прочитать. Если тебе это не нравится, то сравнивай с гугловским документом.   >> У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"... > Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", > а не тратить 80% от CS на трёп с размышлениями каким > образом гугл докатился до такого CS-а. Ты же на ревью хочешь > чтобы клиент просто затнулся и сделал как принято, а не рассуждал > на тему верно это или нет? Потому у гугла CS построен > неверно, его только спасает выделение рассуждений в визуально отдельный блок и > опытный читатель может его пропускать. Тем более рационализация гугла во многих > местах смехотворна, лучше бы просто написали ~ заткись и делай как > тут показано. Ну может у тебя есть ссылка на твой замечательный документ, который описывает как надо делать. Покажи его нам. >> Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать. > Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где > исторически в разных местах появились разные CSы. Типичному разработчику всё же > хватает интеллекта посмотреть как было до и сделать аналогично. Выше уже ответил по теме доке. Вижу, что проблема осталась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #466

473. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:41	+/–
>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > Нет гайдлайна, раньше туда тупых не брали. А в гугл берут тупых по твоей логике раз у них есть гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как только получают офер?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #466 Ответы: #653

474. Сообщение от Аноним (-), 16-Янв-24, 02:47	+/–
> constexpr variable must be initialized by a constant expression На сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 тактов получится. За 0 тактов только то что удалось в константу сколлапсить, для чего оно должно быть вычисляемо на этапе компила. Иначе фиг тебе, золотая рыбка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #471 Ответы: #492

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

476. Сообщение от Аноним (341), 16-Янв-24, 02:54	+1 +/–
> Какую задачу решает это индусское месиво я не понимаю. > брейнфак с типизацией (в шелле!!!) Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно быть понятно, зачем линуксоиды делают свой powershell в виде nushell.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #446 Ответы: #479

477. Сообщение от Аноним (-), 16-Янв-24, 02:55	+/–
> когда я в подном большом проекте заменил все отступы на табы (вместо > 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это > всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором... А еще на несколько мегов меньше читать и парсить (компилеру whitespaces до лампочки, это ж не питон). Тоже так то аргумент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #453

478. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:58	+/–
> В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в > самом деле не киллер фича, но на задачах, где оно нужно, > без поддержки ООП тяжко В каких задачах нужно ООП?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #470 Ответы: #497

479. Сообщение от Аноним (-), 16-Янв-24, 03:04	+/–
> Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно > быть понятно, зачем линуксоиды делают свой powershell в виде nushell. В результате самое крутое что есть в шелле ака мелкая автоматизация системной рутины по месту - здесь и сейчас - там по сути и невозможна. Эффективного интерфейса к системе - нет. Печатать километровые команды и параметры, с почти неработающим автодополнением, а вишенкой на торте еще и пути с пробелами и проч везде (хотели же длинно и интуитивно?) - это здорово, конечно, только в результате я то же самое в лине раз в 5 быстрее делаю. А если еще типизация начнет делать мозг... эээ... ну в общем сделать пайплайн там чаще всего не получается. А если я хотел похардкорить с мощным программизмом - не совсем понятно зачем это в вот именно шелле делать. Оно ж не ide, и с автодополнением джеппа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #476 Ответы: #546

480. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 03:18	+/–
Не узнаю вас, анонимы. Ловко вас провели. Что, уже идея с растом не так плоха как раньше?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #495

482. Сообщение от Аноним (482), 16-Янв-24, 06:37	+1 +/–
Производительность взлетела до небес, наверное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #453

484. Сообщение от Аноним (482), 16-Янв-24, 06:47	+/–
Закупаем такие современное оборудование (с условием, что нам его кто-то продаст)… а там опять винда. Да что ж такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #392

485. Сообщение от Аноним (482), 16-Янв-24, 06:52	+1 +/–
> Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень. Выкинь уже свой зион с али, с «ECC»-памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #488

486. Сообщение от Аноним (486), 16-Янв-24, 07:32	+1 +/–
>Если всё линкуется в один бинарник, то вообще может быть ошибка линковки чудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #589

488. Сообщение от Аноним (214), 16-Янв-24, 09:45	+/–
Твои фантазии унылые, фиксация какая-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #485

490. Сообщение от scriptkiddis (?), 16-Янв-24, 10:01	+/–
Ну и че ты не переписал еще все ядро на brainfuck?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

491. Сообщение от Аноним (341), 16-Янв-24, 10:02	+1 +/–
>> скорее потому, что с++ - надстройка над с > Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих > на "C с классами" у C++ плохая репутация. Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится. Например, type punning через union зачем-то сделали UB. На практике этот приём в плюсах широко используется и если он вдруг где-то сломается, это будет проблемой скорее компиляторописателей, чем пользователей компилятора. Реальный результат изменения - плюсовики бегают и стращают друг друга неопределённым поведением на смех растовикам. Вот сейчас в компиляторах сломать не рискуют, а через 50 лет? То-то же! Но это настолько удобный приём, что UB здесь как первородный грех. Но программирование - не религия, чтобы заниматься догматическим внушением вины перед Комитетом. Может, ему лучше убрать из текста бесполезный де-факто несуществующий UB?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278

492. Сообщение от _kp (ok), 16-Янв-24, 10:13	+/–
constexpr и задумано для этого. Не спорю. Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее. Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники Си без их правки. Это не тяжелое изменение. А переезд могло бы сильно облегчить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #474 Ответы: #600

493. Сообщение от Аноним (253), 16-Янв-24, 10:13	+/–
Какие такие вакансии? Ты о чём? Речь про ведро, корпорациям-хозяйкам ведра не нужны никакие вакансии, разрабы уже есть у них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #457

494. Сообщение от Аноним (253), 16-Янв-24, 10:17	+/–
Ну ты и оболтус. Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто не пользует. Твои плюсеги - сплошной ансейф, а когда находятся cve в плюсовых опенсорсах - разрабы отвечают: ну я забыл заюзать эту фичу. Ахахаха, плюсовеки, такие плюсоеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364

495. Сообщение от Аноним (499), 16-Янв-24, 10:36	+2 +/–
Судя по реакции, скорее наоборот. Под угрозой включения Rust в ядро все уже согласны и на C++. Тем более что его последние стандарты сильно продвинулись по вопросу безопасности памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #480

496. Сообщение от Аноним (499), 16-Янв-24, 10:38	+1 +/–
Именно, а Раст без тулчейна и с unsafe теряет свои главные преимущества и принципиально ничем не отличается от Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386

497. Сообщение от Аноним (499), 16-Янв-24, 10:45	+1 +/–
Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #478 Ответы: #511

498. Сообщение от Аноним (499), 16-Янв-24, 10:52	+/–
Он вроде в С компилируется, значит считай поддерживает считай что все. В отличии кстати от очень ограниченного набора платформ у Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #327

499. Сообщение от Аноним (499), 16-Янв-24, 11:14	+2 +/–
Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #406

500. Сообщение от Советский инженер (ok), 16-Янв-24, 11:20	+/–
> Там правда пары вещей не хватает ... дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то другое. Отличные стандарты! 🤣 >А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Именно поэтому компиляция ядра клангом периодически отваливается? ведь так? Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах? СТАНДАРТ !!! о таком только мечтать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #445 Ответы: #650

501. Сообщение от Tron is Whistling (?), 16-Янв-24, 11:25	+/–
Там программеры другие, они занимаются не рисованием картинок, а работой со сложным железом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #435 Ответы: #507

502. Сообщение от Tron is Whistling (?), 16-Янв-24, 11:26	+/–
Ты не поверишь, но отрицательный индекс в массиве по указателю - очень даже востребован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #454 Ответы: #512, #655

503. Сообщение от Tron is Whistling (?), 16-Янв-24, 11:27	+/–
Не гидравлический пресс надеюсь? А то fail fast может в fall fast перейти :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #431

504. Сообщение от Tron is Whistling (?), 16-Янв-24, 11:28	+/–
Мне у некоторых софтсвитчей вот этот fail fast нравится. Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст в сессию шум океанов марса. Нежели все 100500 звонков разом лягут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #431 Ответы: #677

505. Сообщение от _kp (ok), 16-Янв-24, 11:37	+/–
Вы предлагаете в структуры напихать методов на все случаи? Только описывать их придется в одном месте, а вызывать из другого. Ну удобно же, и читаемо.  :) А подобную инициализацию в портянки переписывать? C++ это не переваривает.   test1("Test1", &(const rqtm_t){.base = 1000, .answer1 = 150, .reaction = 2000, .transfer = 0, .rw = 0 });   test1("Test2", &(const rqtm_t){.base = 500, .answer1 = 50, .reaction = 100, .transfer = 80, .rw = 32 });   .. > В конечном итоге хруст, а вроде еще D, и кто там еще Так, идея в поддержке Си - исходников, а не переписывании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305 Ответы: #581, #599

507. Сообщение от Советский инженер (ok), 16-Янв-24, 12:15	+/–
ви таки недооцениваете сложность рисования картинок по данным, полученным от сожного железа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #501 Ответы: #516, #518

508. Сообщение от Советский инженер (ok), 16-Янв-24, 12:20	+/–
> Раст требует грёбанного тулчейна. а с или с++ не требуют грёбанного тулчейна !? как же тогда текстовые файлы с исходным кодом преобразуються в выполняемые бинари/библиотеки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386

509. Сообщение от freehck (ok), 16-Янв-24, 12:30	+/–
> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают. > Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k... И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, потому что переполнение приведёт к фатальной ошибке системы".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227 Ответы: #534

511. Сообщение от freehck (ok), 16-Янв-24, 13:05	–1 +/–
> Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. > Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их. На самом деле ООП там нужен только потому, что ООП является отдельной индустрией-в-себе: это своя особая экосистема, свой собственный мир, у него свои разработчики, свои проблемы и своя головная боль. По существу, он нужен только там, где разработка уже в этой экосистеме живёт. Поскольку в высокоуровневых языках объекты первого порядка давно являются само собой разумеющимися вещами, то кроме выше названной социальной -- потребности в ООП-е как таковой нет: код на фанкторах пишется и понимается куда проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #497 Ответы: #594

512. Сообщение от Fyjy (?), 16-Янв-24, 13:41	–1 +/–
В производстве овно кода и CVEшек? Верю! Можно просто открывать новости пенька и каждый 2 недели читать про очередную уязвимость от любителей поиграться с индексами. Но вот для надежных систем это только во вред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #502 Ответы: #519

513. Сообщение от Аноним (-), 16-Янв-24, 13:43	+2 +/–
>  a1{1, 2}; > Вот не надо подобного. Когда полей в структуре не один десяток, получим > нечитаемый говнокод и хорошими шансами на вагон опечаток. И хотя это правда, стоит добавить: когда в структуре столько полей - мы знаем что программер/архитект где-то сказочно облажались. Когда у вас столько полей, линейным списком, вы что-то сделали не так. Что, даже вложенный struct не смогли? Или это и правда плоский список такого размера? Что бы это могло быть в легитимном виде, когда того кто это сделал не надо бы уволить с треском за вот это все?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #525, #578

514. Сообщение от Fyjy (?), 16-Янв-24, 13:44	+/–
> сделать по уму, на основе C99 - и с "well defined behavior". Хахахаха, ты предлагаешь невозможное. Сейчас набигут фанатики и объяснят тебе, что UB это лучшее что есть в дыряшке, приведут кучу примеров где оно ну обязательно и без них даже кушать нельзя. Самое глупое оправдание которое мне тут попадалось было "если напишут без уязвимостей, как мы будем рутовать телефоны"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #454

515. Сообщение от Советский инженер (ok), 16-Янв-24, 13:45	+/–
на эмуляторе поверх явапроцессора
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384

516. Сообщение от Tron is Whistling (?), 16-Янв-24, 13:48	+/–
Картинки рисовать - тоже сложно, не спорю, но это больше математика. Ну и плюс весь видеовывод и т.п. как раз винде и отдаётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #507

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

518. Сообщение от Tron is Whistling (?), 16-Янв-24, 13:49	+/–
Короче есть разница: тупо на CPU процессить данные или работать с кучей датчиков и актуаторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #507

519. Сообщение от Tron is Whistling (?), 16-Янв-24, 13:51	+/–
Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер на какой-то указатель в этом индексе. Мне надо предыдущий взять. Далее чего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #512 Ответы: #527, #656

520. Сообщение от Аноним (115), 16-Янв-24, 13:53	+/–
Что такой тугой, TAB равен изначально 8-и символам и это неудобно. Что породило со временем кастомные настройки размера TAB-ов, например, более практичный 4 символа. И по факту теперь это плаваяющая единица из-за чего при разных настройках едет форматирование текста. Потому TAB в современном мире непригоден для использования. Ситуацию можно починить если вхерачить в UTF специальные коды для TAB-ов разного размера или же инструкцию с заданием длины TAB-ов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376 Ответы: #531, #584

521. Сообщение от n00by (ok), 16-Янв-24, 14:11	+/–
> Не лучше. Таб = 1 байт, пробелы >1 байта. И что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

522. Сообщение от Аноним (115), 16-Янв-24, 14:18	+/–
Большинство основных STL частей чисто шаблонные. Например, тот же std::map генерирует разный код для всех используемых комбинаций типов. В so-ке только темплейтнонезаисимые части и некоторые заранее сгенерированные шаблоны для типичных типов. Во время компиляции весь это код всё равно генерируется для каждого c++ исходника и дубликаты выкидываются только на стадии линковки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #461

523. Сообщение от n00by (ok), 16-Янв-24, 14:22	+/–
>>> и в каждый бинарь включена своя копия реализации. >> Подтверждением в виде дизассемблерного листинга не порадуете? > Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали > - все три проги поюзают один shared lib, если либу так > собрать. Будет реюз кода либы. Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная библиотека для ядра header-only была 15 лет назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #663

524. Сообщение от n00by (ok), 16-Янв-24, 14:26	+/–
STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли. Для стандартной библиотеки лишь RTTI затруднительно реализовать как header-only, но оно и не надо в ядре. Все эти сказки про .so оставьте идеологам GPL, в ядро код и без них принимается только под этой лицензией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #461

525. Сообщение от Аноним (525), 16-Янв-24, 14:32	+1 +/–
Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а только добавят скобочек в визуально случайных местах инициализации структуры. Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число полей в каждой из них. Это вам не Ява, где шаг вправо-шаг влево - и у вас сонаркуб заругается, что в структуре больше двух полей, давайте, разбивайте на несколько структур, даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую половину - во вторую. И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #513 Ответы: #644

526. Сообщение от n00by (ok), 16-Янв-24, 14:34	+/–
Это не то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #421

527. Сообщение от Аноним (115), 16-Янв-24, 14:45	+/–
Так твой пример сам по себе небезопрасный. И на этот случай есть унарный --, знак тут всё ещё не нужен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #519 Ответы: #577

529. Сообщение от хрю (?), 16-Янв-24, 14:53	+1 +/–
>Ядро windows написано на С++. Откуда вы эту муйню все копируете? Ядро винды написано и продолжает писаться на C. Так же там есть asm и якобы его там достаточно много. Никакого С++ и чего-то ещё там нет и скорее всего не будет. Винду далеко не идиоты пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #596

530. Сообщение от n00by (ok), 16-Янв-24, 14:54	+/–
Линус и не развернул тему "fundamentally broken". В ядре NT возможно использовать исключения на IRQL PASSIVE_LEVEL, если очень захочется разрешить политикой проекта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351

531. Сообщение от Аноним (525), 16-Янв-24, 14:56	+1 +/–
Ещё раз, специально для вас. Форматирование при использовании табов едет только у тех, кто между табом и пробелом выбирает, бросая игральные кости. У тех, кто использует табы только для отступов, ничего не едет, а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #520 Ответы: #565

532. Сообщение от хрю (?), 16-Янв-24, 14:57	+/–
Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #544

533. Сообщение от n00by (ok), 16-Янв-24, 15:00	+/–
>> Всего лишь 100Мб, не грохнется. > 1) Ну попробуй так на AtMega какой-нибудь :). Это и на AMD64 не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297

534. Сообщение от n00by (ok), 16-Янв-24, 15:13	+/–
>> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают. >> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k... > И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так > старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, > потому что переполнение приведёт к фатальной ошибке системы". Надо перевести на понятный? Стек крайне осторожно используется для хранения адресов возврата, ни слова про размещение там array, а тем более variable length.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #509 Ответы: #536

535. Сообщение от Аноним (-), 16-Янв-24, 15:25	+1 +/–
Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс запретить. Всё! Такие вопросы вообще не должны обсуждаться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #552, #556

536. Сообщение от freehck (ok), 16-Янв-24, 15:27	+/–
Боюсь, что это ты не понял. Данная статья просто предостерегает разработчиков о том, что стек имеет весьма ограниченный размер, и даёт указания, как с ним следует работать. Ни о какой защите речи не ведётся. Это самый обычный стек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #534 Ответы: #550

537. Сообщение от Аноним (-), 16-Янв-24, 15:29    Скрыто ботом-модератором	+/–
Си плюс-плюс - это шаг назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

543. Сообщение от n00by (ok), 16-Янв-24, 15:43	+/–
На деле, плюсы в ядре повышают порог вхождения по сравнению с Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370

544. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 15:43	+/–
> Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю. * Нужна поддержка сбоки модулей на другом языке. * Нужно выработать единый интрефейс для модулей на языке. Сейчас ядро про эти языки ничего не знает. Вот если сделать чтобы модули можно было писать независимо на любом языке. Насколько я понимаю для WASI (https://wasi.dev/) - это одна из целей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #532 Ответы: #607

545. Сообщение от n00by (ok), 16-Янв-24, 15:47	+/–
Под фреймворком обычно понимается что-то тяжёлое. На плюсах возможно реализовать библиотеку без лишних накладных расходов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #379

546. Сообщение от Аноним (546), 16-Янв-24, 15:53	+/–
Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с PSReadLine ты оппрыгаешься с башем. Алиасы давно по умолчанию сделаны и выглядят практически как в баш. Если ты в пайплайны не умеешь в ps - иди в дворники. А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же в 5 раз быстрее сделаешь в лине. Покажи примеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #479 Ответы: #649

547. Сообщение от n00by (ok), 16-Янв-24, 15:56	+/–
Гипотетически они может и были, а практически стандарт языка принят в 98-м.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329

550. Сообщение от n00by (ok), 16-Янв-24, 16:10	+/–
Очевидно, это ты не понял смысл "таких ... не подпускают". Защита стека в Windows выполняется административными методами. И вот таких, кто ничего не написал под ядро, но чему-то учит относительно стека, там не подпускают тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #536 Ответы: #553, #637

552. Сообщение от Аноним (499), 16-Янв-24, 16:20	–1 +/–
Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода ядра на C++ продолжается, а ты можешь и дальше писать свои бессильные гневные комментарии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #535

553. Сообщение от freehck (ok), 16-Янв-24, 16:27	+/–
> Защита стека в Windows выполняется административными методами. Ух едрить как же всё запущено. Ну, с тем же успехом можно сказать, что код защищён от багов, потому что все MR-ы проходят обязательный code review. =) Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #550 Ответы: #564

554. Сообщение от анон (?), 16-Янв-24, 16:27	+1 +/–
> в отличии от конструкторов это не совсем так. placement new в C++ может инициализировать объекты по адресу в буфер. и также возможны свои реализации аллокаторов static char buffer[128]; new (buffer) Circle()
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #579

555. Сообщение от _oleg_ (ok), 16-Янв-24, 16:41	+/–
Что ж людям-то не работается спокойно. То rust с его кошмарным синтаксисом, то C++ - кромешное нагромождение всего и вся - пытаются запихнуть в ядро. Ёплки-палки, да работайте просто уже. Хернёй не страдайте.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #560

556. Сообщение от _oleg_ (ok), 16-Янв-24, 16:43	+1 +/–
> Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс > запретить. Всё! Такие вопросы вообще не должны обсуждаться. Да ладно бы ОО. C++ даже как ОО не очень. Просто страшное недоразумение какое-то. Сложный, запутанный и кривой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #535 Ответы: #588

558. Сообщение от _oleg_ (ok), 16-Янв-24, 16:47	+/–
> Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. > C++ такой же морально устаревший динозавр, как и C, просто еще > более уродливый и окостыленный. Вот Rust, Carbon или Zig - более > лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он > предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры > этого языка. Сам ты морально устаревший. C такой же устаревший как ложка с вилкой. Да что это за болезнь такая тащить всё модное всюду без разбора? А оно, вообще, в ядре надо? Надо ядру принципиально новая парадигма? Что за гуманитарный бред? C работает, справляется со своей задачей хорошо. Проще ЯП при его возможностях нет на данный момент. Сложнее и хуже - навалом. Нафига это всё тащить в ядро - непонятно. От скуки и скудоумия. Работой займись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359 Ответы: #627

559. Сообщение от _oleg_ (ok), 16-Янв-24, 16:48	+/–
> Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование > на шаблонах) попадет в ядро то туши свет. Rust хоть и > имеет более непривычный синтаксис чем С++, но все же разработан с > учетом опыта многих других языков. Про C++ согласен. Но и rust не нужен. Пусть пишут свои проекты. Зачем в ядро лезть. Там всё норм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

560. Сообщение от Аноним (-), 16-Янв-24, 16:53	+/–
>C++ - кромешное нагромождение всего и вся Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором есть всё в виде объектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #555 Ответы: #562

561. Сообщение от _oleg_ (ok), 16-Янв-24, 16:56	+/–
> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во > всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать > каждый исходник версией, просто невозможно придуамать. Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты туда _уже_ пойдёшь редактором. И поменять при этом pragma - не проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно и логично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #337 Ответы: #563

562. Сообщение от _oleg_ (ok), 16-Янв-24, 17:04	–1 +/–
>>C++ - кромешное нагромождение всего и вся > Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором > есть всё в виде объектов. Дело не в том, что там всё в виде объектов. Дело в том, что там просто кошмарный ужас из всего. Если хочется ООП, то надо смотреть на другие ЯП. C++ это не ООП. Это наркоманский приход. И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Он добился своего :-). Но мы этим пользоваться не обязаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #560 Ответы: #597

563. Сообщение от Серб (ok), 16-Янв-24, 17:14	+/–
>> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во >> всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать >> каждый исходник версией, просто невозможно придуамать. > Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты > туда _уже_ пойдёшь редактором. И поменять при этом pragma - не > проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно > и логично. Правильно и логично - когда не надо менять код под каждый новый стандарт. Любая необходимость менять должна быть исключением из правил. Вот эти исключения из правил и надо выявлять. Компилятор это делает. Можно было бы создавать отдельную утилиту, но зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #561 Ответы: #568

564. Сообщение от n00by (ok), 16-Янв-24, 17:45	+/–
>> Защита стека в Windows выполняется административными методами. > Ух едрить как же всё запущено. Ну, с тем же успехом можно > сказать, что код защищён от багов, потому что все MR-ы проходят > обязательный code review. =) > Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =) Я знаю, что некоторые умело подменяют тезис с целью превзойти собеседника. Вот только я не спорю, а сообщаю факт: вопросом про стек отсеивают всех умельцев работать лишь языком, в самом начале собеседования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #553

565. Сообщение от Аноним (115), 16-Янв-24, 17:52	+/–
Какой и ты тугой. Форматирование в общем случае едет всё равно потому что TABы конкурируют с обычным текстом в соседних строках. Например, это разбивка длинных аргументов у функций на строки, это многострочные комментарии с развёрнутыми пояснениями, это идиотский GNU стиль расстановки скобочек {. И многое другое. > а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2. Галиматью несёшь. Код сразу форматируется под конкретный размер TABа и с другими размерами форматирование едет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #531 Ответы: #566

566. Сообщение от Аноним (115), 16-Янв-24, 17:55	+/–
Типичный, кстати, пример, где всё это едет, как раз линуксовое ядро, которое пишется под стандартный TAB
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #565

568. Сообщение от _oleg_ (ok), 16-Янв-24, 18:06	+/–
> Правильно и логично - когда не надо менять код под каждый новый > стандарт. А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? Есть у тебя исходик с pragma version 2014 и на здоровье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #563 Ответы: #571

571. Сообщение от Серб (ok), 16-Янв-24, 18:18	+/–
>> Правильно и логично - когда не надо менять код под каждый новый >> стандарт. > А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? > Есть у тебя исходик с pragma version 2014 и на здоровье. Например, что бы оптимизации сработали. Смотри lto.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #568 Ответы: #572

572. Сообщение от _oleg_ (ok), 16-Янв-24, 18:51	+/–
>>> Правильно и логично - когда не надо менять код под каждый новый >>> стандарт. >> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? >> Есть у тебя исходик с pragma version 2014 и на здоровье. > Например, что бы оптимизации сработали. Смотри lto. Если pragma version относится только к синтаксической части, то оптимизации здесь ни при чём и их можно рулить параметрами командной строки компилятора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #571 Ответы: #617

573. Сообщение от Аноним (573), 16-Янв-24, 18:57	+/–
> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на это описание и, по необходимости, прокомментирована. В случаях когда реализация использует оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать с тем же успехом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #575

574. Сообщение от Аноним (573), 16-Янв-24, 19:03	+/–
Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #406 Ответы: #691

575. Сообщение от n00by (ok), 16-Янв-24, 19:09	+/–
>> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. > Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии > прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на > это описание и, по необходимости, прокомментирована. В случаях когда реализация использует > оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно > должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, > списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые > бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать > с тем же успехом. Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных прав по лицензиям типа GPL. Потому имеем, что имеем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #573 Ответы: #648

577. Сообщение от Tron is Whistling (?), 16-Янв-24, 20:00	+/–
Мне не нужно менять сам указатель :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #527

578. Сообщение от _kp (ok), 16-Янв-24, 20:06	+/–
>>Когда у вас столько полей... вы что-то сделали не так. Что значит мы? Это задачи такие. И не все делается в одиночку. Что требуется для работы с устройствами и протоколами. А в итоге, иногда, строки в исходнике распухают за 400 символов. ;) Отформатируешь, так будет каша, в которой не разобраться. Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #513 Ответы: #645

579. Сообщение от _kp (ok), 16-Янв-24, 20:19	+/–
> new (buffer) Circle() Благодарю. Жаль что с constexpr оно только с c++20 только, а то в embedded в ходу компиляторы и постарее. Но, уже лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #554

580. Сообщение от Аноним (341), 16-Янв-24, 20:20	+/–
А, методы, определённые в теле класса, неявно помечены как inline. Если определения конструкторов вынести - новое условие уже будет "чтобы это было так не только с -O0/-O1".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341

581. Сообщение от adolfus (ok), 16-Янв-24, 20:24	+/–
В С и С++ нет методов, не было никогда и не будет -- есть функции-члены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #505

582. Сообщение от adolfus (ok), 16-Янв-24, 20:33	+/–
В С++ есть большая проблема -- ссылки в перечне параметров функции. Это препятствует использованию там r-value. А как известно, любое l-value в программе добавляет +1 к пулу потенциальных проблем безопасности и программных ошибок. Что касается goto, то без него вы даже из вложенного цикла не выйдете. Вернее, выйдете, но через виртожопу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #609, #610

583. Сообщение от _kp (ok), 16-Янв-24, 21:47	+/–
> Так то g++ заметно тормознее gcc...   Это в прошлом было такое. А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc, в среднем, но не всегда.   Но нет дыма без огня. В разных сборках компиляторов скорость может отличаться в разы, например, бывает "хорошая" сборка g++ может быть заметно быстрее gcc или другой сборки g++. Такой бардак с компиляторами есть для esp32 и stm32, и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары компиляторов можно сделать неверные выводы.   При тесте на исходнике который могут переварить оба компилятора, нормальных сборок, то разница незначительна, и быстрее может оказаться и g++.   А  если понаворотите кода, то логично, что работы станет больше, и оптимизировать тоже  надо.   А еще некорректно сравнивать скорость компиляции в отрыве от результата компиляции, а то clang часто быстрее g++, но у g++ бинарник получше на мой взгляд выходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #603

584. Сообщение от _kp (ok), 16-Янв-24, 22:00	+/–
> ТAB равен изначально 8-и символам Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с шагом, а именно произвольно. Бардак был изначально, но на бумаге выходили пробелы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #520 Ответы: #676

585. Сообщение от _kp (ok), 16-Янв-24, 22:07	+/–
Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понимаемо, но не так. ;) То есть, в плане оформления исходника, позволяют "прострелить себе ногу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397

586. Сообщение от _kp (ok), 16-Янв-24, 22:10	+/–
> автодополнение в том уродце не работает по сути никак, А когда пишешь скрипт в любимом редакторе, то  никакого автодополнения для этого чудовища вовсе нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #382

587. Сообщение от _kp (ok), 16-Янв-24, 22:32	+/–
>>Линус может сказать, что уже прошло много времени и язык существенно изменился > Он высказался не о языке. Речь о c++ образца 2007г или ранних. Вы сами то хотите на них писать? Ладно, это мелочь.   А по существу. Тогда был подъем моды на объектное программированиее, причем где надо и ненадо, и даже там где это вредно.   И фраза про С++ "намного легче генерировать полную чушь" была не безосновательна. Дай дураку инструмет, на котором он легко сделает говнокод, и он именно его и напишет.   Аналогична ситуация с количеством говнокода на Делфи и Питоне, и совсем не потому что языки плохи, а потому что позволяют навалить кучу по быстрому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

588. Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 23:11	+/–
Не тролинга ради вопрос: в каком языке ООП сделано как надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #556 Ответы: #592, #612, #626

589. Сообщение от Аноним (589), 16-Янв-24, 23:13	+/–
Э... Очевидно имелось ввиду именно линковка. Один файл компилируется в объектник с включенным заголовочником. Другой файл генерируется объектник с включенным  заголовочником. Оба содержат одинаковые сгенерированные функции. Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #486

590. Сообщение от Аноним (589), 16-Янв-24, 23:16	+1 +/–
С чего вдруг лучше то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #467 Ответы: #636

592. Сообщение от DEF (?), 16-Янв-24, 23:26	+/–
Нормальное ООП должно быть основано на интерфейсах. Никакого наследования. Тем более множественного. Более-менее нормальное ООП в Java.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #588 Ответы: #608

593. Сообщение от Аноним (589), 16-Янв-24, 23:31	+/–
Пока это только умозрительная машина. Которую можно вертеть только на ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #417

594. Сообщение от Аноним (589), 16-Янв-24, 23:45	+/–
> код на фанкторах пишется и понимается куда проще. Если объекты (в плане понятий из предметной области) однотипные. Любая, даже минимальная, иерархия приводит к росту гемороя в геометрической прогрессии. Люди думают понятиями а не раздельно существующими матрицами свойств.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #511

595. Сообщение от Аноним (589), 16-Янв-24, 23:48	+/–
> какой-нибудь С++50, который наконец-таки превратится в Rust Ты думаешь, что в C++50 порежут все что можно по самые помидоры? Так что останется одна заготовка языка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

596. Сообщение от Аноним (589), 16-Янв-24, 23:57	+/–
Достаточно интервью в котором мелкомагкие переписывальщики на раст говорят о том, что занимаются переводом внутренних C++ типов в эквивалентные раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #529

597. Сообщение от Вы забыли заполнить поле Name (?), 17-Янв-24, 02:33	+/–
> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Можно ссылку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #562 Ответы: #598, #613

598. Сообщение от Полная отсебятина (?), 17-Янв-24, 02:57	+/–
В книге The C++ Programming Language, 4th Edition, подчеркиваеться что Страуструп, никогда не говорил что язык C++ это ООП язык, цитирую I wince when someone characterizes C++ exclusively through one of these styles (e.g., ‘‘C++ is an object-oriented language’’) or uses a term (e.g., ‘‘hybrid’’ or ‘‘mixed paradigm’’) to imply that a more restrictive language would be preferable. The former misses the fact that all the styles men- tioned have contributed something significant to the synthesis; the latter denies the validity of the synthesis. The styles mentioned are not distinct alternatives: each contributes techniques to a more expressive and effective style of programming, and C++ provides direct language support for their use in combination. дальше можно не читать этот жирный троллинг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #597

599. Сообщение от Аноним (-), 17-Янв-24, 04:04	+/–
> Вы предлагаете в структуры напихать методов на все случаи? Я лишь констатировал что на си можно делать весьма по разному - в том числе даже и фокус на манер конструктора, вот, отколоть. Иногда даже может иметь свой пойнт. Нужно ли делать именно так в конкретном случае - на усмотрение програмера. > удобно же, и читаемо.  :) Ну извините, в сях в общем случае принято допустим typedef в одном месте а фактическую инициализацию все же в другом. Ну вот так получилось. Это не очень хорошо, и если совсем не нравится то решаемо, но со своими граблями взамен. > А подобную инициализацию в портянки переписывать? Я иногда что-то такое могу как макро заколотить кстати. Т.е. вон то было бы как-то типа //     name, ..., ... ... rw TEST1("Test1", 1000, 150, 2000,  0,  0); TEST1("Test2", 500,   50,  100, 80, 32); ... и при этом кстати не так уж важно как TEST1 внутри сделано. Можно и C++ легко осчастливить если станет нужно. А если это что-то типа массива однотипной хни по смыслу то и массив можно скроить, да еще в виде когда нельзя его криво сделать. Т.e. как-то типа TESTS_START(whatever) TEST1(...); TEST1(...); TESTS_END ...при том так можно сделать парсер, фигарящий по массиву struct'ов от сих до сих, и что самое забавное - итерирование этого как массива - корректно работает. Даже на си. И да, при правильном подходе это и правда лишь пачка констант, вплоть до .rodata, в мк уйдет в флеху. С другой стороны работать с ними будет "итератор", а заполнять - макрос. Сишка так то позволяет делать довольно странные вещи. > C++ это не переваривает. Если не ощибаюсь так только с C++20 можно. >> В конечном итоге хруст, а вроде еще D, и кто там еще > Так, идея в поддержке Си - исходников, а не переписывании. Я даже как бы согласен, но если мир не идеален - упс, да, и чего? В C++ есть и еще пара отличий. Скажем auto до недавних пор в сях означало совсем другое. В C23 кстати это поменяли. C23 вооб ще довольно интрузивная штука. Но боюсь что комитета не хватит исправить наиболее жирные бестолковости сей. Типа, вот, дурных базовых типов и UB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #505

600. Сообщение от Аноним (-), 17-Янв-24, 04:09	+/–
> constexpr и задумано для этого. Не спорю. > Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее. Как бы плюсы мощнее сей. Но если повыпендриваться - то си можно основательно перекроить. Но не факт что нужно, ибо огорошивать посторонних кодеров экзотичным диалектом... не очень хорошая идея. Хотя о C++ ходит даже в общем то и не шутка что каждый програмер пишет на своем диалекте C++. > Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники > Си без их правки. На 100.0% это все же врядли получится. Скажем "register" в C++ нету. И auto означало нечто совсем другое до недавних пор. Хоть я и не понимаю чем им "register" так уж не угодил. > Это не тяжелое изменение. А переезд могло бы сильно облегчить. Вот конкретно там я тоже не понимаю почему вообще должно быть такое отличие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #492

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

602. Сообщение от Аноним (20), 17-Янв-24, 04:29	+/–
Да нет там никакой битвы, тем более легендарной. Очень вялая дискуссия где одни челы говорят, что Раст всё равно лучше, а другие челы обсуждают все причины, по которым С++ впилить в кернел не получится, во всяком случае что бы с++ при этом оставался полезным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

603. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #583 Ответы: #615

604. Сообщение от Аноним (20), 17-Янв-24, 04:35	+1 +/–
Это тебе так кажется. Раст "пихают" не потому, что "фанаты", а потому, что на то есть объективные причины. Те самые причины, по которым пихают его, а не С++. Это не вопрос того, что кому больше нравится. Это вопрос сугубо технический. И раст чисто по техническим причинам оставляет С++ далеко позади.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #624

605. Сообщение от Аноним (20), 17-Янв-24, 04:39	+/–
Майкрософт вот не тупит и на расте уже Винду переписывает: https://www.theregister.com/2023/04/27/microsoft_windows_rust/ А комментаторы опеннета всё живут умом где-то в в 90-ых.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #606, #625

606. Сообщение от Аноним (-), 17-Янв-24, 07:04	+3 +/–
Приводить Майкрософт (компанию, которую все презирают), как пример для подражания. Ну, это даже не шутка, это жирнейший троллинг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #605

607. Сообщение от Аноним (-), 17-Янв-24, 07:07	+/–
>Вот если сделать чтобы модули можно было писать независимо на любом языке Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. У них мышление не нормальное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #544 Ответы: #634

608. Сообщение от Аноним (608), 17-Янв-24, 07:34	+/–
>Никакого наследования. Да ты чё, сам придумал? Но тогда почитай, на каких столпах основано это самое ООП.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #592

609. Сообщение от Аноним (609), 17-Янв-24, 08:27	+/–
>Что касается goto, то без него вы даже из вложенного цикла не выйдете. Что касается "обычных непричин", нон-секвитуров и прочих нерелевантных доводов, выходы из вложенных циклов просто свидетельство каши в коде и в голове разраба. >Вернее, выйдете, но через виртожопу. Из через жопу написанного кода любой выход только такой. И с помощью goto в первую очередь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #582 Ответы: #614

610. Сообщение от Аноним (609), 17-Янв-24, 08:32	+/–
>Что касается goto, то без него вы даже из вложенного цикла не выйдете. "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #582 Ответы: #616

611. Сообщение от Школьник (ok), 17-Янв-24, 09:18	+/–
Потому что корпорации в эпоху Интернета быстро поняли, куда дует ветер, и решили скинуться человекочасами на разработку того, что само по себе уже не могло давать конкурентных преимуществ. Это и есть главная причина того, что Линукс взлетел. И уж точно не технологическое превосходство - до первой половины нулевых в бзде лучше было сделано почти всё, а про то, насколько лучше в это же время был солярис, даже и говорить особо не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

612. Сообщение от _oleg_ (ok), 17-Янв-24, 11:18	+/–
> Не тролинга ради вопрос: в каком языке ООП сделано как надо? smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, что видел. C++ и Java точно не из этого. Но в java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, выкинув некоторые извращения и ненужные усложнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #588 Ответы: #639, #682

613. Сообщение от _oleg_ (ok), 17-Янв-24, 11:22	+/–
>> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. > Можно ссылку? Не могу найти оригинал. Перепечатка тут: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all . Хз насколько это троллинг, но, зная C++ в сравнении с другими ЯП, охотно воспринимается за чистую монету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #597

614. Сообщение от adolfus (ok), 17-Янв-24, 12:04	+/–
Ну так пройдитесь просто по двумерному массиву. Когда-нибудь изображения обрабатывали? А гиперспектральные, которые трехмерные массивы? Парсер простой напишите без goto для какого-нибудь примитивного языка, например, для джейсона. Все без исключения FSM-алгоритмы, коими и являются эти самые синтаксические анализаторы, работают на goto безальтернативно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #609

615. Сообщение от _kp (ok), 17-Янв-24, 12:26	+/–
>>А зачем мне васянские сборки, опять же? Если например пересборка компилятора esp32s3 и системы сборки сократила время сборки проекта  с 40 до 8 секунд, то таких Васянов на руках носить надо. Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" дали подсказку куда копать, то и их труды не пропали. >>куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивны Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором. Но это справедливо для одной версии и сборки компиляторов clang и gcc. А разные версии и сбоки могут отличаться как угодно Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, свежие компиляторы в принципе медленнее старых версий их же самих. И разрыв между компиляцией си и с++ будет вполне заметен. А на среднемощном десктопе таки пофиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #603 Ответы: #673

616. Сообщение от adolfus (ok), 17-Янв-24, 12:34	+/–
>>Что касается goto, то без него вы даже из вложенного цикла не выйдете. > "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных > циклов... А главное, писать вложенные циклы. "Каше-френдли" программирование начинается прежде всего с безальтернативного использования статических библиотек вместо динамических и минимизации длинных переходов. Причем прежде всего это касается вызовов процедур, поскольку каждый call сопровождается еще и ret'ом. Итого два сброса всех кешей кода в одном вызове. А короткие переходы, которые в основном и генерируются из goto, кеши кода не портят, поскольку все это происходит в пределах одной страницы. Причем и кеши данных не сбрасывают тоже, поскольку к памяти данных/стека, в отличие от call/ret не обращаются. Кстати, обращение к любой функции в .so несколько раз сбрасывает все кеши, что есть. Сначала дальняя ссылка на GPT, потом дальний переход на процедуру и потом возврат из дальнего вызова. Есть несколько постулатов, используемых, в том числе, и в программировании, следование которым позволяет серьезно повысить качество программ. Это: 1) явное всегда лучше неявного; 2) административные проблемы плохо решаются техническими средствами, а технические -- административными, поэтому "Каждому свое", как было написано на воротах одного гуманитарного заведения. Эти два пункта относятся прежде всего к стилям програмирования, в том числе и к goto. Смысл состоит в том, что проблемы, проистекающие из-за хреновых навыков программирования (это всегда у нас и у них тоже называлось "логические ошибки"), невозможно адекватно решать с помощью каких-то особых и "безопасных" языков программирования. Все эти якобы "безопасные" парадигмы и языки поголовно работают поверх кода, написанного на сях, да и сами в 99% случаях написаны на них же, представляя просто фреймворк. Питон, например, один из них. Второй момент -- их использование не дает прграммисту расти. Он просто скачет от одной "технологии" к другой, оставаясь на уровне своего лучшего курсового проекта. Умение работать с памятью приходит только с опытом работы с ней и никак не иначе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #610 Ответы: #622

617. Сообщение от Серб (ok), 17-Янв-24, 12:46	+/–
>>>> Правильно и логично - когда не надо менять код под каждый новый >>>> стандарт. >>> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? >>> Есть у тебя исходик с pragma version 2014 и на здоровье. >> Например, что бы оптимизации сработали. Смотри lto. > Если pragma version относится только к синтаксической части, то оптимизации здесь ни > при чём и их можно рулить параметрами командной строки компилятора. Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах возможностей оптимизации меньше. Или в вашем любимом языке это не так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #572 Ответы: #618

618. Сообщение от _oleg_ (ok), 17-Янв-24, 13:20	+/–
> Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах > возможностей оптимизации меньше. Или в вашем любимом языке это не так? Оптимизации - расплывчатое понятие. Что я вижу в новых стандартах C и C++ это не какие-то скрытые оптимизации поверх старого синтаксиса, а как раз изменения в синтаксисе, добавление чего-то нового с целью упрощения чего-то старого. И для того, что бы повившиеся анонимные структуры, инициализация по именам полей структуры и т.п. работало, надо сделать таки изменения в исходном коде. Для этого туда надо зайти. И заодно поменять pragma version. Не вижу проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #617 Ответы: #619, #620

619. Сообщение от Серб (ok), 17-Янв-24, 13:43	+/–
На изменение обработки volatile смотрел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #618

620. Сообщение от Серб (ok), 17-Янв-24, 13:48	+/–
На расширение того, что при constexpr уйдет в компиле тайм смотрел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #618

621. Сообщение от Аноним (631), 17-Янв-24, 14:41	+/–
Заскорузлые мозги => устаревшие решения. Почему не D ?? Для кого развивали "преемника С++"? Там же всё по-уму сделано, а популяризация его в линукс-камьюнити только ещё больше поможет языку.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #632

622. Сообщение от n00by (ok), 17-Янв-24, 14:45	+/–
Предсказание и предвыборка команд работают для call/ret начиная с NetBurst (и для far call/ret работают, но эти команды не используются в плоской модели памяти). Но это не повод отказываться от статического связывания. Calls and returns are expensive; use inlining for the following reasons: • Parameter passing overhead can be eliminated. • A mispredicted branch can lead to performance penalties inside a small function that are larger than those that would occur if that function is inlined. • In a compiler, inlining a function exposes more opportunity for optimization. • If the inlined routine contains branches, the additional context of the caller may improve branch prediction within the routine.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #616

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

624. Сообщение от Аноним (623), 17-Янв-24, 17:06	+/–
Да, конечно, не потому что 'фанаты'. Давай посмотрим на объективные факты. Основа современного софтверного мира прекрасно существуют вообще на Си, даже не на плюсах. Прекрсно существует несмотря на все проблемы с Си. И rust в этом существовании ничего не может радикально улучшить. А именно не снизит существенно человеко-часы на разработку, ни увеличит кол-во решаемых проблем вообще. Т.е. проблема будущего развития ядра никак не упирается в проблемы Си в ядре. Технические вопросы это можно ли, и как, занести c++/rust в ядро. А нужно ли уже вопрос экономический если рассматривать в объективной плоскости. Оценок, естественно, профита от внедрения никто не делает т.к. это сложно и в реальности вопрос сводится в экспертную плоскость на уровень личных мнений. Если сравнение Си против rust более-менее можно увести в пользу rust, то с псюсами так не получится. Потому что плюсы это сбалансированный ЯП, а rust смещает внимание только на решение одной пробемы и заносит много мусорных решений из функциональщины вроде всё в ЯП выражения вместо высказываний. Выбор rust именно фетиш на единственную фичу и вера в её полезность, тут и близко нет никакого объективного технического выбора. В таком выборе в приниципе нет ничего плохого. Плохое это, будущи гуманитарием, пробовать замаскировать свои предпочтения под некий объективный и технический выбор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #604 Ответы: #670

625. Сообщение от Аноним (631), 17-Янв-24, 17:16	+1 +/–
То, что в M$ работают индусские м@к@ки, порождает и соотв. решения - вот Раст к примеру :)) Абсолютно необоснованное решение. Как и попытки заигрывания в Линукс внутри венды. Сейчас M$ далеко не "гигант ИТ" - это монстр, который полностью сгнил внутри и идёт чисто как зомби - по инерции. Венда-10-11 - это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание. На плаву держатся серверные системы и MS SQL (видимо, обезьян не подпускают к золотой курице). Другими словами, найдите пример поинтереснее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #605 Ответы: #657

626. Сообщение от Аноним (631), 17-Янв-24, 17:21	+/–
Например, в D (чистый преемник С++). Нет множ.наследования (порождающие больше проблем, чем решающие). Есть traits. Шаблоны. Да вообще ВСЁ, что может понадобиться адекватному ООПщику - чего не пишется, спрашивается??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #588 Ответы: #640

627. Сообщение от Аноним (631), 17-Янв-24, 17:25	+/–
>Да что это за болезнь такая тащить всё модное всюду без разбора? Обычная болезнь зумеров. Знаний - мало, энергии - много, страсть ко всему новому (для их мозга). Увидели - слюни потекли, побежали ставить/канпелять. Плюс, такие же клоуны как они подливают масла в огонь своими "хелловорлдными" статейками (которыми только подтереться). И вот уже кто-то всерьёз обсуждает Раст.... *фэйспалм*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #558

628. Сообщение от Аноним (631), 17-Янв-24, 17:27	+/–
А чем D не взлетел?! Что в этом языке такого плохого, что его нельзя использовать для ведра?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

629. Сообщение от Аноним (631), 17-Янв-24, 17:38	+/–
Это конвульсии трупа :) Фактически уже понятно - как только "добрый диктатор" сдохнет, начнётся полный коллапс (не по этой причине, а тупо из-за бестолкового, монолитного, плохо спроектированного ведра). И на каком языке писать ведро вопрос уже стоять даже не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

630. Сообщение от Аноним (631), 17-Янв-24, 17:39	+/–
Почему не QNX? Minix? Да даже BeOS была бы куда лучшей альтернативой!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

631. Сообщение от Аноним (631), 17-Янв-24, 17:42	+/–
Ну тут надвое сказано... Что именно "разгребать"?? ООП для того и придумали, что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь. Другой вопрос, что с ЛЮБЫМ ООП языком придётся тянуть и его рантайм (который просто нельзя выкинуть). И как рантайм одного модуля "дружить" с остальными? (включая ядерный) Вот где засада. На одном хелловорлде рантайм прекрасно работает. Но в сложной модульной системе - большой вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #633

632. Сообщение от Аноним (632), 18-Янв-24, 00:09	+2 +/–
Если бы его грамотно пиарили и больше людей в разработку включили, а так имеем что имеем. Но он еще вполне жив, так что посмотрим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #621

633. Сообщение от Вы забыли заполнить поле Name (?), 18-Янв-24, 02:46	+/–
> ООП для того и придумали, > что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. > без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь. А причем тут ООП? Хорошую декомпозицию и абстракцию можно сделать без него: lisp и erlang как пример.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #631

634. Сообщение от Вы забыли заполнить поле Name (?), 18-Янв-24, 02:53	+/–
>>Вот если сделать чтобы модули можно было писать независимо на любом языке > Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. > У них мышление не нормальное. Что плохого в идее WASI?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #607

635. Сообщение от wyry (?), 18-Янв-24, 18:20	+/–
Несмотря на то, что я топлю за C++, не могу не придраться, что C++ ОЧЕНЬ опасен в плохих руках и там легко допустить плохие решения (как по семантике, так и по читаемости кода). Но преимущество C++ в том (и об этом говорили многие задолго до китов), что C++ напрямую связан с C и всё можно переписывать плавно не боясь что-то сломать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397

636. Сообщение от Аноним (636), 18-Янв-24, 23:59	+/–
См. рис. 1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #590

637. Сообщение от Аноним (637), 19-Янв-24, 00:04	+/–
Размер стека можно задать каким нужно, вызвав соответствующую функцию. Это он по-умолчанию такой, потому что "12 килобайт хватит каждому". А кому не хватит - тот может затребовать больший.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #550 Ответы: #641

638. Сообщение от Гультай (?), 19-Янв-24, 09:03	+/–
Лол, молодёжь на javascript пишет, ей что сишечка что плюсы это древние рукописи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370

639. Сообщение от Серб (ok), 19-Янв-24, 14:37	+/–
>> Не тролинга ради вопрос: в каком языке ООП сделано как надо? > smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, > что видел. C++ и Java точно не из этого. Но в > java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, > выкинув некоторые извращения и ненужные усложнения. Набор микросервисов с динамической типизацией. В качестве примера ООП это лучше не приводить. Он был первым, который вступил на тропу. Но свернул совсем не туда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #612

640. Сообщение от Серб (ok), 19-Янв-24, 14:40	+/–
> Нет множ.наследования (порождающие больше проблем, чем решающие). Тут только одна проблема - это самое порождение проблем родит их для разработчика языка. Пользователя этого языка эти проблемы не должны касаться. Для пользователя это звучит как: "Ну не смогла я, не смогла".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #626

641. Сообщение от n00by (ok), 19-Янв-24, 14:58	+/–
> Размер стека можно задать каким нужно, вызвав соответствующую функцию. Формулировка некорректна. Можно _попробовать_ задать размер. KeExpandKernelStackAndCallout ... Returns success if the stack allocation is successful and the callout has been called. Otherwise, returns a failure status. > Это он по-умолчанию > такой, потому что "12 килобайт хватит каждому". А кому не хватит > - тот может затребовать больший. А кому в итоге не хватит? Running out of kernel stack space causes a fatal system error. Therefore, it is better for a driver to allocate system-space memory than to run out of kernel stack space. Если даже до этого не дочитали, то до описания KeExpandKernelStackAndCallout и понимания, зачем она вообще нужна, тем более не дошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #637

642. Сообщение от ДаНуНафиг (?), 19-Янв-24, 16:29	+/–
> 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей > и читаемей? > Поэтому, использую не в всегда. Красивее - нет, но оно и не всегда нужно, а когда и вовсе нужно убирать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #471

643. Сообщение от ДаНуНафиг (?), 19-Янв-24, 16:38	+/–
>> нефиг создавать ложное впечатление, есть же строгий порядок инициализации. > Если сам с нуля пишешь то обычно да, логичнее писать по порядку, > но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок > меняется. Все это прекрасно выделяется блоками комментариев. Не могу представить ситуации с перестановкой блоков инициализации, чтобы это выделить. > И конечно уже существующие исходники. В существующих исходниках ничего не поменяется. А если уж хочется их "освежить" подобной инциализацией, то можно же предварительный корректирующий коммит сделать. > Не забываем, что инициализацию структур только только добавили. И еще недавно можно > было для больших структур делать или нечитаемую портянку, и как дурак > считать каждый раз элементы, что б что то исправить, или мешать > с и c++ файлы в проекте. > Шаг в сторону улучшения есть, что хорошо, но пока полумеры. Для сложных случаев всегда можно было каждый инициализатор сопровождать маленьким блочным комментарием с имененем инициализируемого члена класса. Больше забот, но в сопровождении уж насколько проще. Хотя если разобраться, что в комментарии написать /* id */, что так написать .id=0  - практически один фиг ведь по количеству символов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #469 Ответы: #646

644. Сообщение от Аноним (-), 19-Янв-24, 18:18	+1 +/–
> Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а > только добавят скобочек в визуально случайных местах инициализации структуры. Вообще-то сделают данные более структурированные - и - вот - менее подверженными тому классу ошибок. Если вы это не понимаете - что я там про архитектов то говорил? Вывалить более 9000 сущностей линейным списком не больно какая архитектура. > Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число > полей в каждой из них. Это вам не Ява, где шаг > вправо-шаг влево - и у вас сонаркуб заругается, Ну так правильно заругается. Нефиг гамнокодить. Структуры с дохреналионом полей уж точно не признак мастерства архитекта и изящества архитектуры. > что в структуре больше двух полей, давайте, разбивайте на несколько структур, > даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую > половину - во вторую. Со своей стороны я буду считать что более ~десятка полей в структуре - "кодер был неадекватен и делал какую-то фигню или не смог в архитектуру, гамнякая в режиме питоняши". > И закончим на соседней новости, где просто изменением порядка полей в большой > структуре добились увеличения производительности на 40%. А вот там господа таки - понимают что делают - и структур  с более 9000 полей не заводят. И вложенные структуры юзать не гнушаются. Такая ерунда. > В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне > от "выглядит бредово" до "это невозможно". С чего бы это вдруг? А 1 из примеров - заменили struct на u32. Стало даже проще. На самом деле есть tradeoff между нуждами оптимизации кода и изящностью и логической консистентностью апи. Не всегдя изящное логичное апи хорошо маппится на конкрерику оптимизера вот тут. Тот кто не джун и уже умеет в архитектуру и управление проектом немного - понимает что нужен какой-то разумный баланс. Если у вас более 9000 полей в структуре, очевидно, это профачено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #525

645. Сообщение от Аноним (-), 19-Янв-24, 18:33	+1 +/–
> Что значит мы? Это задачи такие. Ну да, вы такие особенные на всю планету, наверное. > И не все делается в одиночку. Значит общее управление проектом оставляло желать. То что факап по чуть другой линии не означает что это офигенная идея и так и надо было. > Что требуется для работы с устройствами и протоколами. > А в итоге, иногда, строки в исходнике распухают за 400 символов. ;) Типа, когда это УГ надо скроллить даже на здоровенном мониторе - намного понятнее и читабельнее? Более того - это нехило ограничений на конфиги тех кто в проекте будет копаться. В опенсорсе чревато тем что вам вообще патчей не пришлют, решив что скроллякать ваши простыни на вон том лаптопе - нафиг надо, лучше другой код взять, менее отшибленый. > Отформатируешь, так будет каша, в которой не разобраться. ORLY? У меня другие идеи на этот счет. Сорри. В случае опенсорса, если я где-то такое встречу, я просто немедленно сотру это как непотребное, если есть замена, или жестко отрефакторю, если по другому совсем никак. Потому что такой гамнякинг для меня приемлимым не является. > Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;) Ну дык, иногда бывает что ну вот оставляет желать, но это ж не пример как надо делать. А пример как делать НЕ надо. Чтобы другие потом не матерились на такой код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #578

646. Сообщение от _kp (ok), 19-Янв-24, 18:34	+/–
> Все это прекрасно выделяется блоками комментариев. Да это ж это же костылизм. Впрочем, сейчас оно уже в прошлом. > Не могу представить ситуации с перестановкой блоков инициализации Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и что теперь собирающийся под разные варианты исходник корежить, и делать несколько его вариантов. А в embedded это не редкость, и при сборке под разные платформы тоже. И туда же, как писал выше, генерация макросами. И так же, заполнение не всех полей балластом, когда их много.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #643 Ответы: #672

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

648. Сообщение от Аноним (-), 19-Янв-24, 18:50	+/–
> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить > хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных > прав по лицензиям типа GPL. Потому имеем, что имеем. В каком месте GPL лишает кого-то имущественных прав? Цитату?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #575 Ответы: #659

649. Сообщение от Аноним (-), 19-Янв-24, 19:03	+/–
> Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с > PSReadLine ты оппрыгаешься с башем. Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. > Алиасы давно по умолчанию сделаны и выглядят практически как в баш. А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Ну я и не понял зачем мне такой шелл надо, не разгоняет мою эффетивность и создает больше проблем чем решает. Не, я не хотел хардкорить в шелле. Для этого другие яп есть. > Если ты в пайплайны не умеешь в ps - иди в дворники. Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Можно сделать что хотел а не пытаться косплеить лучшие практики мега-иде зачем-то бжаж в шелле, где для этого инструментации нет. > А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же > в 5 раз быстрее сделаешь в лине. Покажи примеры. Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Конечно для KVM и QEMU, нахрен мне вмварь? Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. У вас там уровень сцаного эксплуатанта. А я кастомдев, мне больше надо. На баше я это забацал минут за 10. А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #546 Ответы: #684

650. Сообщение от Аноним (-), 19-Янв-24, 19:17	+/–
> дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то > другое. Отличные стандарты! 🤣 Хрустики даже и так не смогли. Все познается в сравнении... которое они и не выдерживают пока, демонстрируя шоу "хаотичная помойка имени питоняш". >>А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. > Именно поэтому компиляция ядра клангом периодически отваливается? ведь так? В хрусте системщина вообще в зачаточном состоянии и там вообще не привалилось еще толком - чтобы вообще начать отваливаться. Иногда удается что-то на проволоку и изоленту примотать, чуть ли не с gcc'шным, мля, линкером на страпоне, ибо свой - УГ. Но это видимо не пахнет. Но конечно вы можете скачать ночнушку, высокобезопастным инновационным curl | sh. Там может быть если повезет, уже почти, вот вот, ых, ых, ых... как как грите, фукмсию решили отменить когда как раз почти треть переписали? Ну, во, все правильно сделали. Сразу видно wannabe-успешный проект. Успешно присоединится к Wave, Plus, Picasa и кому там еще в Валхалле. > Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах? > СТАНДАРТ !!! о таком только мечтать! "Но тут снизу постучали" - это были хрустики.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #500 Ответы: #660

651. Сообщение от Аноним (-), 19-Янв-24, 19:38	+/–
> Я почему шучу про "много энергично говорим" - потому что идеи assert'ов > для размера VLA,  тестирования худшего случая отметаются как немыслимые Не то что немыслимые - а "еще хуже чем динамическая аллокация". Ибо еще менее defined и еще меньше возможностей для корректной реакции. А что должен кернел сделать по assertion failed? В панику брякнуться? Ну, зашибись реакция, конечно. Юзерям понравится. Retry выделения в этой парадигме вообще не получится (смысл повторять тот же assertion?!), вернуть caller'у ошибку - наверное не assert тоже было. И получается как вон то - только еще хуже, ибо грабель больше и контроля над ручкой нет, грабля автоматически подпрыгивает и лупит в лоб всех кто проходит мимо. > и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - > вот, фрагментация кучи уже лучше, чем VLA. Внезапные крахи и почти полная невозможность их адекватного парирования спускают си до уровня питоняш и нафиг нам такой си вперся вообще? > В принципе на этот случай есть union'ы, но с ними придётся следить > не за стеком, а за тем, чтобы не было обращений к > неактивным полям и чтобы инициализация активного поля нигде не пропускалась. Я даже примерно так (изредка и немного) делаю - но при этом желательно сделать некий interlock ресурса, для проверки использования, иначе так окажется что мы тут храбро юзали массив - а вон там сетапнули DMA, забыли про это, все счастливо пахало... пока DMA не добрался до нас и не протер все к хренам другими данными... а мы не понимаем - откуда, блин, это вообще вот так?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #462

652. Сообщение от Аноним (-), 19-Янв-24, 19:59	+/–
> Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть > на примере Мозиллы. Есть пример лучще - Fuchsia и ее "вот, мы, ща, на десктопы, столица миоа - в нью-васюки!". Вон там в соседней новости, где гранд-план по захвату мира кажется немного обломался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

653. Сообщение от Аноним (-), 19-Янв-24, 20:02	+/–
> А в гугл берут тупых по твоей логике раз у них есть > гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как > только получают офер? Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #473

654. Сообщение от Аноним (-), 19-Янв-24, 20:07	+/–
> Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта > для кард-ридера и денег. У одной фирмы я видал там характерную лужайку с кнопкой Start. Или, не менее пафосный скринсейвер с логотипом XP. А у другой после проскока питалова - вся загрузка как на ладони, но там еще после старта антивирь пашет. И пока он пашет - тадам - можно шарахаться по морде банкомата жамкая сенсорный экран, проводник точно запускается. Потом конечно морда запускается и все вышибает, но пошариться проводником по банкомату... ээ... ну им так кто-нибудь и бабки снимет при случае наверное. В мои планы такой тупой кибекриминал не входил, чисто проверка "так можно было?!", но оказалось что таки - можно! :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #365

655. Сообщение от Аноним (655), 19-Янв-24, 20:12	–1 +/–
> Ты не поверишь, но отрицательный индекс в массиве по указателю - очень > даже востребован. А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали. Я все понимаю - но вот в именно таком стиле CVE получаются. Воон там зубр сабмитил отрицательный индекс массиву если вооон те параметры на вход дать. Не, так не задумано - просто он аргументы функции на вход не чекал, и получив воооон те параметры, лихо проматывал индекс не только до 0 но и за него. Ну, подумаешь, по чужой памяти пошарился, а то и в провод слил, "ишь ты, карманный вариант heartbleed'а". Гнать таких програмеров ссаными тряпками и ср@ной метлой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #502

656. Сообщение от Аноним (-), 19-Янв-24, 20:15	–1 +/–
> Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер > на какой-то указатель в этом индексе. > Мне надо предыдущий взять. Далее чего? Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #519 Ответы: #658

657. Сообщение от Аноним (-), 19-Янв-24, 20:20	+2 +/–
> внутри и идёт чисто как зомби - по инерции. Венда-10-11 - > это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в > ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание. Да это вы просто не видели что они с виндофоном вытворяли. Еще и нокию за собой утопили, угробив все наработки UI/UX от нокии, с...ки!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #625

658. Сообщение от Tron is Whistling (?), 19-Янв-24, 21:41	+/–
Да не, я не против, чтобы ты вместо одного сервера у меня 10 купил, но ты ведь не купишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #656 Ответы: #665

659. Сообщение от n00by (ok), 20-Янв-24, 08:36	+/–
>> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить >> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных >> прав по лицензиям типа GPL. Потому имеем, что имеем. > В каком месте GPL лишает кого-то имущественных прав? В месте замены "право" на "лево". > Цитату? "copyleft"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #648 Ответы: #661

660. Сообщение от Советский инженер (ok), 20-Янв-24, 11:13	+/–
>Хрустики даже и так не смогли. Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог. Очередной пример, указывающий что стандарты это что-то бесполезное на практике. >чуть ли не с gcc'шным, мля, линкером на страпоне, нет никакого gcс'шного, мля, линкера. есть GNU Binutils. и тут хрустики тоже поступили практично, как и gcc'шники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #650 Ответы: #662

661. Сообщение от Аноним (-), 20-Янв-24, 11:26    Скрыто ботом-модератором	+/–
> В месте замены "право" на "лево". >> Цитату? > "copyleft" И где тут акт отчуждения прав происходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #659 Ответы: #669

662. Сообщение от Аноним (-), 20-Янв-24, 12:17	+/–
> Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог. Они пока так пробились что постоянно переделывают свое месиво, постоянно надо самую-самую ночнушку, иначе нихрена не получится, в общем, самый прод. Я допускаю что из этого постепенно может и получится что-то дельное. Но пока это выглядит весьма хаотично, а нужда постоянно тягать начнушки яп намекает на д@рьмовый дизайн где многое не предусмотрели. > Очередной пример, указывающий что стандарты это что-то бесполезное на практике. Ну да, намного лучше, когда кучка хайпующей хипстоты вываливает в синтакс какое-то уг для ублажения сиюминутных хотелок своего вендора. А в результате синтаксис корежат хуже чем у питона, без скачки ночнушки нихрена не работает, и полезные продукты на этом уже прямо захватили мир. Куда там плюсерам до этого, действительно. >>чуть ли не с gcc'шным, мля, линкером на страпоне, > нет никакого gcс'шного, мля, линкера. есть GNU Binutils. Как минимум это все - вообще не заслуга хрустиков. > и тут хрустики тоже поступили практично, как и gcc'шники. Ну вот я подожду gccrs и там подумаю - надо оно мне или нет. LLVMный змейгорыныч мне не приболел, я не фанат ни гугли ни эппла, это те еще кидалы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #660 Ответы: #679

663. Сообщение от Аноним (-), 20-Янв-24, 12:25	+/–
> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная > библиотека для ядра header-only была 15 лет назад. И это все круто и офигенно - потому что что? С чисто практической точки зрения, если вы завтра перестанете существовать, вместе со своей либой - для меня изменится ну вот например что? Ах, ничего? Тогда и смысла передо мной рисоваться со всем этим - примерно ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. Это не я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #523 Ответы: #668

665. Сообщение от Аноним (-), 20-Янв-24, 12:44	+/–
> Да не, я не против, чтобы ты вместо одного сервера у меня > 10 купил, но ты ведь не купишь. Я как махровый сишник готов поспорить что все то же самое можно было сделать значительно менее ректально. Без явно невалидных на глаз (и статический анализатор) действий. То что вы делаете что-то ректально и гордитесь этим намекает что хрустики все же имеют свой понйт в своем желании вас уйти. Той е#$%нины в коде лично я не желаю видеть в принципе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #658 Ответы: #666

666. Сообщение от Tron is Whistling (?), 20-Янв-24, 13:04	+/–
На самом деле пусть уходят - чище будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #665 Ответы: #678

667. Сообщение от Аноним (667), 20-Янв-24, 13:34	+/–
Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты с их шаблонной магией и прочими непотребствами стандарта на много тысяч страниц. Таким образом резко повышается порог вхождения.
Ответить | Правка | Наверх | Cообщить модератору

668. Сообщение от n00by (ok), 20-Янв-24, 15:28	+/–
>> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная >> библиотека для ядра header-only была 15 лет назад. > И это все круто и офигенно - потому что что? Потому что ты придумал тезис "круто и офигенно", что бы приписать его мне. В надежде на что? > С чисто > практической точки зрения, если вы завтра перестанете существовать, вместе со своей > либой - для меня изменится ну вот например что? Ах, ничего? > Тогда и смысла передо мной рисоваться со всем этим - примерно > ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. > Это не я. "Я три дня гналась за вами, чтобы сказать, как вы мне безразличны!" (ц)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #663

669. Сообщение от n00by (ok), 20-Янв-24, 15:36	+/–
>> В месте замены "право" на "лево". >>> Цитату? >> "copyleft" > И где тут акт отчуждения прав происходит? Наймите юриста, пусть он и разъясняет в подробностях, что такое copyright, и что такое copyleft. Мне в принципе не интересен данный разговор с тем, кто не может заявить "вот, смотрите, я создал проект под GPL", потому что такой -- материально заинтересованное лицо, не являющееся автором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #661

670. Сообщение от Илья (??), 20-Янв-24, 18:40	+1 +/–
Кресты это нехорошо. Одни и те же ошибки ошибки при завышенном чсв плюсовиков Не могу придумать никакой отрасли (кроме игр) где я бы согласился на плюсах проект начинать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #624

671. Сообщение от Аноним (671), 21-Янв-24, 03:53	+/–
С++ и С имеют множества недостатков от которых некоторые современные языки вылечены. Проблема в том что разработчики компиляторов и железа в первую очередь поддерживают С,С++ и в стандартизации — разных поставщиков и наборе инструментов. Поэтому выигрывает тот язык, который сумеет буквально его поглощать трансляцией в другой язык. Таких пока вроде нет и вряд ли будет — из-за множества ньюансов дешевле нанять команду разработчиков которые будут переводить из С на свой язык библиотеки и фреймворки. А вот локальные миссии по созданию цифровой экосистемы могли бы дать результат, если целенаправленно двигаться лет так 10–15. Но миссии это у американцев, потому что у них agile процессы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #693

672. Сообщение от ДаНуНафиг (?), 21-Янв-24, 07:41	+/–
>> Не могу представить ситуации с перестановкой блоков инициализации > Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и > что теперь собирающийся под разные варианты исходник корежить, и делать несколько > его вариантов. А в embedded это не редкость, и при сборке > под разные платформы тоже. > И туда же, как писал выше, генерация макросами. > И так же, заполнение не всех полей балластом, когда их много. Ничего не понял про собирающего. Если у него были старые исходники, то у него все поля инициализировались в строгом порядке вообще без указания поля, например: a{0, 2, 3}. Даже если ему придет в голову самолично переключить стандарт компиляции на C++20, то этот же код соберется без проблем, по крайней мере в этой части.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #646

673. Сообщение от Аноним (-), 21-Янв-24, 16:53	+/–
> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" > дали подсказку куда копать, то и их труды не пропали. Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому. > Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором. Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить. > Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, > свежие компиляторы в принципе медленнее старых версий их же самих. И > разрыв между компиляцией си и с++ будет вполне заметен. А на > среднемощном десктопе таки пофиг. У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #615 Ответы: #674

674. Сообщение от _kp (ok), 21-Янв-24, 19:21	+/–
Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а не переписывать, чем занята другая группа. Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные. Но случаи бывают разные. Банально что то поправить, и собрать не дома. Есть ещё командировки. И студенты в конце концов. >>плюсовые проекты заметно тормознее билдить. Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда по сути си проекты, с минимумом фич от с++, или их отсутствием, собирают с++ компилятором. И тут, взависимости от стиля исходника, бинарник может получиться и лучше, и контроль типов получше, а разница во времени компиляции минимальна в подобных случаях. Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, а то именно на мощных компах проекты "начинающих" и "консерваторов" не используют все ресурсы компа, и даже на мощной машине собираются неспешно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #673 Ответы: #675

675. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #674

676. Сообщение от Капитан О. (?), 21-Янв-24, 20:37	+/–
> Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с > шагом, а именно произвольно. > Бардак был изначально, но на бумаге выходили пробелы. На печатных машинках чужие исходники не отображали так что там проблема с тем что форматирование не то как задумано и не возникала...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #584 Ответы: #681

677. Сообщение от Аноним (-), 21-Янв-24, 20:56	+/–
> Мне у некоторых софтсвитчей вот этот fail fast нравится. > Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст > в сессию шум океанов марса. > Нежели все 100500 звонков разом лягут. Софт свич несколько отличается от печатки с силовухой, допустим. Одно дело по превышению тока сразу в safe state свалить, и совсем другое - подождать вачдога, который там дескать может ребутнет, но до того момента - силовые ключи - и половина платы - правратятся в чуть ли не кусок плазмы уже, и тогда х... толку с вачдога?! Даже если проц и перезагрузится - то чего? В этот момнет уже поздняк на превышение тока реагировать и что-то выключать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #504 Ответы: #680

678. Сообщение от Аноним (-), 21-Янв-24, 21:09	+/–
> На самом деле пусть уходят - чище будет. Инихрена себе уровень самокритики. Вот это вы круты. Я правильно понимаю что вы считаете что без вас в проекте станет лучше? O_O Да, это довольно необычно для опеннет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #666

679. Сообщение от Советский инженер (ok), 21-Янв-24, 21:44	+/–
> Они пока так пробились что постоянно переделывают свое месиво ... ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет. >Куда там плюсерам до этого, действительно. точно не в ядро. >> нет никакого gcс'шного, мля, линкера. есть GNU Binutils. >Как минимум это все - вообще не заслуга хрустиков. это как раз показывает что хрустики практичные. и да, это так же не заслуга приплюснутых. >Ну вот я подожду gccrs и там подумаю ага, держи нас в курсе. всем очень интересно (нет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #662 Ответы: #686

680. Сообщение от Tron is Whistling (?), 21-Янв-24, 22:17	+/–
Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочувствую, и да, можно название, чтобы это не брать никогда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #677 Ответы: #687

681. Сообщение от _kp (ok), 22-Янв-24, 18:23	+/–
TAB - был не символом, а кодом движения печатающей головки или руки оператора. Поэтому и проблем не возникало, потому что на экране или бумаге был текст с пробелами. А использовать TAB как символ в исходниках было ошибкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #676

682. Сообщение от fuggy (ok), 22-Янв-24, 23:49	+/–
В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного класса от default interface теперь не многие назовут. А вы эти static utils *anything видели. Анемичные модели. Это разве похоже на ООП? Типичный процедурный стиль уровня C, с той разницей что все функции должны в классах лежать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #612 Ответы: #683

683. Сообщение от _oleg_ (ok), 23-Янв-24, 11:36	+/–
> В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного > класса от default interface теперь не многие назовут. > А вы эти static utils *anything видели. Анемичные модели. Это разве похоже > на ООП? Типичный процедурный стиль уровня C, с той разницей что > все функции должны в классах лежать. Кто ж сказал, что java идеальна? C# в этом плане получше, по свидетельствам очевидцев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #682

684. Сообщение от Аноним (684), 23-Янв-24, 19:00	+/–
> Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. У тебя как 294й, с способностью понимать тексты? Проблема? Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в баш это круто. > Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. О, опять очередной передерг. Аж два сразу. Во первых бизнес-логика. Про неё тут никто и не говорил. Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает. > А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой же аргумент приводят на тему системд и другой системы инициализации. Только там лапша в баше у них. Ты про алиас то в поисковик можешь вбить болезный? Ну и показать насколько букв команда в баше cd больше цмдлета в пауршеле cd? Хотя у кого хаотическое мышление им действительно не понять - как это правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы. Ну про телегу разных шелов и разное поведение в разных ОС вообще промолчу. Переносимость это не про тебя. Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих. Проще в несколько команд прогнать объект и вытащить нужный процесс по тому же показателю памяти. Чем писать десятки строк под каждую ОС и шел. Мне своё время дороже. Но твоё ничего не стоит, поэтому пиши партянки с макаронинами под мак-вин-лин и разные шелы. > Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Ну так все и поняли что ты не умеешь в пайплайны. Сейчас в куче мест ушли все в курьеры. Мест для дворников полно. Сходи - пособеседуйся. Там твоё место. > Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с ардуинками, мелкими виртуалочками и прочим компостом. Нужна "плаформа" для возможности быстро решить задачу. Давай наналог PowerCLI для kvm. Тебя больного с баш-портянками в комплекте к сервису нормальным людям не надо. > Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь. >  У вас там уровень сцаного эксплуатанта. Бгыыых. Тебе то виднее у кого что. Гусар-одиночка с пердуинками на шеле пишет письмо сатья-наделле, картина маслом. >  А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! Да все уже поняли что ты головка от патефона. Не пробовал это сделать но мнение имеешь. > А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :) Ты не поверишь. powershell от этого никуда не денется. Как и модули к остальным виртуальным средам. Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост павлиний распушил. Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #649 Ответы: #685, #690

685. Сообщение от Аноним (-), 23-Янв-24, 21:48	+/–
> Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в > баш это круто. Меня от шелла интересует 2 сценария: oneliner руками на 1 раз, "here and now". Либо batch mode штука, управляемок параметрами командлайна. Зачем мне вон то я хз. Пытаться из шелла крутую среду программирования? Бессмысленно и беспощадно. > Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает. Я и смотрю, аж виндузеры WSL что-то полюбили. > Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой > же аргумент приводят на тему системд и другой системы инициализации. Странно что я ненавижу спагетти код независимо от яп? Но у баша в целом команды и параметры лаконичнее в разы. Печатать меньше -> трабл решается быстрее. Системд приветствуется ... по той же причине. У меня даже есть гибриды, где шелл и systemd играют в унисон, на пару. Скрипт прописывает и активирует юнит. Юнит потом тоже запускает скрипт. Я использую плюсы тулсов оставляя минусы за бортом. А в целом оркеструется забавное действо бутстрапа VM с минимумом возни. > Только там лапша в баше у них. А я ей ТАМ и не хочу пользоваться, если можно это урезать. Но кастом это кастом, там скрипт пригодится уже. Просто точек кастомизации 1-2, а остальное из фич системды и сделано. > Ты про алиас то в поисковик можешь вбить болезный? Ну и показать > насколько букв команда в баше cd больше цмдлета в пауршеле cd? Ага, костыли фичой объявить. Это в духе MS. > правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы. Шелл создан для автоматизации хаоса. Он хаотичен в 95% случаев. А концептуальную архитектуру проекта, клевые апи и структуры уместнее разводить где-то еще. > промолчу. Переносимость это не про тебя. Я могу в стандартный "posix shell" уложиться если это принципиально. А ps нигде кроме винды нет по сути. Но винда и мак для меня не в приоритете. Я инструментирую R&D линуха, это уместнее из линуха. > Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих. Майнтайнить шеллскрипты? Мсье знает толк... > Проще в несколько команд прогнать объект и вытащить нужный процесс по тому > же показателю памяти. Я не хотел крутое програмирование в шеле, я хотел мелкую автоматизацию по месту и быстрое решение насущных проблем. Если вам то проще, вы это и делайте. Мне это не надо от шелла. > Чем писать десятки строк под каждую ОС и шел. Я могу писать под posix shell, если надо. А ps на осях отличных от винды не в ходу вообще. > пиши партянки с макаронинами под мак-вин-лин и разные шелы. Пишу либо "под posix shell" - максимального компат, либо "под баш", 2 конфиги максимум. > Ну так все и поняли что ты не умеешь в пайплайны. У меня нет цели изобразить фантомаса в очках на аэроплане любой ценой из той кривули. > Сходи - пособеседуйся. Там твоё место. У кого что болит, видимо. > Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с > ардуинками, мелкими виртуалочками и прочим компостом. Оно меня интересует. А так в баш и позиксшелл многократно больше народа могет, есчо. > Нужна "плаформа" для возможности быстро решить задачу. Кому нужна - тому и карты в руки! С фига меня ваши задачи должны волновать больше моих хз. Для меня мои задачи приоритетнее, збс должно быть - там. > Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь. Дреппера vs arm напоминает. И вот где дреппер а где арм теперь? :) > пишет письмо сатья-наделле, картина маслом. Мне от этих раджа-насреддинов к счастью ничего не надо. > Не пробовал это сделать но мнение имеешь. Я много чего еще не пробовал, в этом мире много странной хни. > Ты не поверишь. powershell от этого никуда не денется. Как и модули > к остальным виртуальным средам. А вон то знание может вскоре стать бесполезным хламом. Да и быть придатком к 1 корпорации мне как-то так себе. А что и куда денется - решаете не вы а менеджмент этой корпы. И я видел как они росчерком пера проекты в утиль - хрясь. > Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост > павлиний распушил. А я и не собирался играть по вашим правилам. Поздравляю с прозрением. > Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить? Оно помогает мне находить единомышленников. Вместе мы надерем ваши задницы по полной программе. Есть такое ощущение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #684

686. Сообщение от Аноним (-), 23-Янв-24, 21:54	+/–
> ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет. В ядре много чего было. И не все из этого с нами сейчас. Так что это само по себе еще ничего не означает. С другой стороны - может из этого и выйдет что-то дельное постепенно. Но пардон, качать ночнушки компилера - не стандарт а хипста-треш. >>Куда там плюсерам до этого, действительно. > точно не в ядро. Они чем-то принципиально хуже хрустиков? > это как раз показывает что хрустики практичные. Если бы они были бы практиными, потратили бы немного больше времени на архитектуру и изучение чужих фэйлов, тогда не приходилось бы перекачивать постоянно компилер и корежить синтаксис. Но с этим кажется облом вышел. > и да, это так же не заслуга приплюснутых. А бинутилсам плюсы юзать не разрешили случайно? В гцц - точно можно. >>Ну вот я подожду gccrs и там подумаю > ага, держи нас в курсе. всем очень интересно (нет). Да вы и кернел линуха врядли трогаете даже трехметровой палкой, так что...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #679

687. Сообщение от Аноним (-), 23-Янв-24, 22:14	+/–
> Если у вас на плате нет защиты от превышения тока кроме софта По законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;) И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать "без причины". А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще. Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя. По причинам выше - быстродействующий предохранитель, "на грани" - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя в курсе, startup это или авария, допустимо ли столько времени, или уже перебор, и так далее. И можно вон те неудачные соотношения несколько обойти. > - я вам очень сочувствую, и да, можно название, чтобы это > не брать никогда? ...сказал тип, стесняющийся уточнить название своего прова за отношение в ipv6 :). Впрочем можете не париться - я масспродом не занимаюсь и ваши шансы купить сие весьма низкие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #680 Ответы: #688, #689

688. Сообщение от Tron is Whistling (?), 23-Янв-24, 22:16	+/–
А ваш софт умеет думать, пока МК дымится вместе с платой? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #687

689. Сообщение от Tron is Whistling (?), 23-Янв-24, 22:32	+/–
Почему? Потому что по законам Мерфи первым сдохнут датчики для вашего софта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #687

690. Сообщение от Аноним (690), 24-Янв-24, 06:18	+/–
Резюмируя два. Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела. Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет. Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник. Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #684

691. Сообщение от Stellarwind (?), 25-Янв-24, 15:39	+/–
Линуса просто уже ранее настойчиво попросили быть повежливее.. Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C. и про ядро: In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #574 Ответы: #692

692. Сообщение от n00by (ok), 25-Янв-24, 17:02	–1 +/–
> Линуса просто уже ранее настойчиво попросили быть повежливее.. > Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus > C++ is a horrible language. It's made more horrible by the fact > that a lot of substandard programmers use it, to the point > where it's much much easier to generate total and utter crap > with it. Quite frankly, even if the choice of C were > to do *nothing* but keep the C++ programmers out, that in > itself would be a huge reason to use C. На это я отвечал в #211 > и про ядро: > In fact, in Linux we did try C++ once already, back in > 1992. > It sucks. Trust me - writing kernel code in C++ is a > BLOODY STUPID IDEA. И на это тоже. Правда, не на цитату Линуса, а на изложенный экспертом похожий смысл. Подсказывать не хочу -- думайте сами над очевидным ляпом, если считает себя знатоком С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #691

693. Сообщение от Аноним (693), 28-Мрт-24, 14:10	+/–
Поток сознания
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #671

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

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