The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Дискуссия об использовании языка C++ для разработки ядра Linux

14.01.2024 21:32

В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.

С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки C и C++ значительно продвинулись вперёд в своём развитии и язык C++ стал лучше, чем С, подходить для разработки ядра операционных систем.

Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++, и во многих случаях использование C++ позволит улучшить инфраструктуру без глобального изменения кода. В качестве минимальной упоминается использование спецификации C++14, которая включает необходимые средства метапрограммирования, а в качестве желаемой - использование спецификации C++20, в которой появилась поддержка концепций, способных исключить появление многих ошибок.

Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

  1. Главная ссылка к новости (https://www.phoronix.com/news/...)
  2. OpenNews: В ядре Linux 5.18 планируют разрешить использование стандарта языка Си C11
  3. OpenNews: В рамках проекта IncludeOS развивается ядро для обособленного запуска C++-приложений
  4. OpenNews: Проект BOSSMOOL развивает средства разработки драйверов ядра Linux на C++
  5. OpenNews: Linux ядро адаптировано для сборки компилятором Intel C/C++
  6. OpenNews: Создатель C++ раскритиковал навязывание безопасных языков программирования
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60436-cpp
Ключевые слова: cpp, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (609) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.62, _kp (ok), 23:42, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –25 +/
    Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо сизифов труд.
     
     
  • 2.75, Аноним (75), 00:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О чем речь? С++ может инициализировать структуры
     
  • 2.78, Аноним (75), 00:07, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    struct A {
      int a;
      int b;
    };

    A a1{1, 2};

    работает в C++20 (может и в более ранних версиях)

     
     
  • 3.244, _kp (ok), 11:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    a1{1, 2};
    Вот не надо подобного. Когда полей в структуре не один десяток, получим нечитаемый говнокод и хорошими шансами на вагон опечаток.


    a1{.v1=1, .v2=2} - работает в с++, но частично. Давится на порядок полей, и к тому что считает константами.
    И подобное с Си в С++ не переносится без правки исходника.

     
     
  • 4.513, Аноним (-), 13:43, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  a1{1, 2};
    > Вот не надо подобного. Когда полей в структуре не один десяток, получим
    > нечитаемый говнокод и хорошими шансами на вагон опечаток.

    И хотя это правда, стоит добавить: когда в структуре столько полей - мы знаем что программер/архитект где-то сказочно облажались. Когда у вас столько полей, линейным списком, вы что-то сделали не так. Что, даже вложенный struct не смогли? Или это и правда плоский список такого размера? Что бы это могло быть в легитимном виде, когда того кто это сделал не надо бы уволить с треском за вот это все?

     
     
  • 5.525, Аноним (525), 14:32, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а только добавят скобочек в визуально случайных местах инициализации структуры.

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

    И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".

     
     
  • 6.644, Аноним (-), 18:18, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то сделают данные более структурированные - и - вот - менее подверженными... большой текст свёрнут, показать
     
  • 5.578, _kp (ok), 20:06, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>Когда у вас столько полей... вы что-то сделали не так.

    Что значит мы? Это задачи такие. И не все делается в одиночку. Что требуется для работы с устройствами и протоколами.
    А в итоге, иногда, строки в исходнике распухают за 400 символов. ;)
    Отформатируешь, так будет каша, в которой не разобраться.
    Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)

     
     
  • 6.645, Аноним (-), 18:33, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну да, вы такие особенные на всю планету, наверное Значит общее управление прое... большой текст свёрнут, показать
     
  • 2.90, Аноним (-), 00:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо
    > сизифов труд.

    Эй, это даже в си работает?! Вы там что-то совсем тормоз не отпустили?

    Черт, даже можно присваивать однотипные структуры. Одна из причин по которым gcc в freestanding надо memcpy - конечно же такое присвоение это вот оно будет.

     
     
  • 3.115, Аноним (115), 02:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В смысле, 'даже'? В плюсах эта фича полноценно появилась только в C++20, когда как в Си с C99

    https://en.cppreference.com/w/cpp/language/aggregate_initialization

     
  • 3.149, Аноним (149), 03:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/



    a = {.x = 1, .y = 2};



    Вот такой синтаксис завезли только в 20е плюсцы.
     
     
  • 4.240, _kp (ok), 11:24, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >


    > a = {.x = 1, .y = 2};
    >


    > Вот такой синтаксис завезли только в 20е плюсцы.

    Ага.  А если не в исходнике было не {.x = 1, .y = 2, ...}, а в другом порядке { .y = 2, .x = 1, ...}, то надо править исходник, иначе не скомпилирует.

     
     
  • 5.363, ДаНуНафиг (?), 18:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Все правильно, ибо нефиг создавать ложное впечатление, есть же строгий порядок инициализации.
     
     
  • 6.469, _kp (ok), 02:21, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > нефиг создавать ложное впечатление, есть же строгий порядок инициализации.

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

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

     
     
  • 7.643, ДаНуНафиг (?), 16:38, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Все это прекрасно выделяется блоками комментариев Не могу представить ситуации ... большой текст свёрнут, показать
     
     
  • 8.646, _kp (ok), 18:34, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да это ж это же костылизм Впрочем, сейчас оно уже в прошлом Да легко Перестав... текст свёрнут, показать
     
     
  • 9.672, ДаНуНафиг (?), 07:41, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего не понял про собирающего Если у него были старые исходники, то у него вс... текст свёрнут, показать
     
  • 3.249, _kp (ok), 11:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я сейчас почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу.
    Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов, и более того не требует временных переменных, что облегчает автоматизацию генерации кода.
    Вне ядра проблема "элегантно" решается мешаниной файлов C и C++ в одном проекте.
    Каких то причин, кроме религиозных убеждений, доя подобной несовместимости, и подобных - нет. И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С.

    О другой проблеме - совместемости вызовов.
    Частичное решение - extern "C".
    И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для API и библиотек.

     
     
  • 4.305, Аноним (-), 14:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На самом деле очень зависит от И может являть собой и memset или memcpy в опред... большой текст свёрнут, показать
     
     
  • 5.505, _kp (ok), 11:37, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы предлагаете в структуры напихать методов на все случаи?
    Только описывать их придется в одном месте, а вызывать из другого. Ну удобно же, и читаемо.  :)

    А подобную инициализацию в портянки переписывать? 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, и кто там еще

    Так, идея в поддержке Си - исходников, а не переписывании.

     
     
  • 6.581, adolfus (ok), 20:24, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В С и С++ нет методов, не было никогда и не будет -- есть функции-члены.
     
  • 6.599, Аноним (-), 04:04, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я лишь констатировал что на си можно делать весьма по разному - в том числе даже... большой текст свёрнут, показать
     
  • 4.341, Аноним (341), 16:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов

    А можно пример, чтобы это было так не только с -O0? Зачем компилятору вызывать конструктор, когда он может применить оптимизации?

    Можно этот переделать: https://godbolt.org/z/Y4G554zdr

     
     
  • 5.580, Аноним (341), 20:20, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А, методы, определённые в теле класса, неявно помечены как inline. Если определения конструкторов вынести - новое условие уже будет "чтобы это было так не только с -O0/-O1".
     
  • 4.352, pavlinux (ok), 17:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ... почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу.
    >  аналогичное extern "CPP",

    Пейсатель,  CPP - это C PreProcessor,   CXX - для плюсов )))

     
  • 4.367, ДаНуНафиг (?), 18:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Про 0 тактов - constexpr ctor.
     
     
  • 5.373, Аноним (115), 18:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    consteval
     
  • 5.471, _kp (ok), 02:31, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Про 0 тактов - constexpr ctor.

    1. Да, я это использую.
    Но не так и редко бывает на ровном месте и
    constexpr variable must be initialized by a constant expression
    Особенно во встраиваемом ПО,что по духу ближе к ядру, чем пользовательские приложения.

    2. После обкладывания constexpr всего и вся правда ведь исходник и красивей и читаемей?
    Поэтому, использую не в всегда.

     
     
  • 6.474, Аноним (-), 02:47, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > constexpr variable must be initialized by a constant expression

    На сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 тактов получится. За 0 тактов только то что удалось в константу сколлапсить, для чего оно должно быть вычисляемо на этапе компила. Иначе фиг тебе, золотая рыбка.

     
     
  • 7.492, _kp (ok), 10:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    constexpr и задумано для этого. Не спорю.
    Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее.

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

     
     
  • 8.600, Аноним (-), 04:09, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы плюсы мощнее сей Но если повыпендриваться - то си можно основательно пер... большой текст свёрнут, показать
     
  • 6.642, ДаНуНафиг (?), 16:29, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей
    > и читаемей?
    > Поэтому, использую не в всегда.

    Красивее - нет, но оно и не всегда нужно, а когда и вовсе нужно убирать.

     
  • 4.450, InuYasha (??), 00:03, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А что плохого в extern "C"? Очень часто используется.
     
  • 4.554, анон (?), 16:27, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в отличии от конструкторов

    это не совсем так. placement new в C++ может инициализировать объекты по адресу в буфер. и также возможны свои реализации аллокаторов

    static char buffer[128];
    new (buffer) Circle()

     
     
  • 5.579, _kp (ok), 20:19, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > new (buffer) Circle()

    Благодарю. Жаль что с constexpr оно только с c++20 только, а то в embedded в ходу компиляторы и постарее. Но, уже лучше.

     
  • 2.236, Аноним (236), 11:16, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > ибо сизифов труд

    Есть же знатоки.

     
     
  • 3.241, _kp (ok), 11:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> ибо сизифов труд
    > Есть же знатоки.

    А что не так? Если ни какими опциями компилятора нельзя избежать правки рабочего исходника и внесения новых опечаток, то вполне мартышкин труд.

     
     
  • 4.325, Котофалк (?), 15:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Строго говоря разница усматривается. Сизифов труд это бесконечное наказание, мартышкин труд - бесполезное развлечение.
     
  • 2.270, leap42 (ok), 12:57, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Пока с++ не осилит инициализацию структур

    С++ поддерживает 25 способов инициализации, и это уже само по себе проблема)

     
     
  • 3.293, Аноним (293), 13:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В 20 сишную .fild_name=100 запилили.
     

     ....большая нить свёрнута, показать (40)

  • 1.1, Аноним (1), 21:43, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
     
     
  • 2.2, oficsu (ok), 21:46, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу
     
     
  • 3.18, Аноним (18), 22:08, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу

    ШТО?

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

     
     
  • 4.52, funny.falcon (?), 23:20, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > не обладают тьюринговой полнотой

    Но остаётся совсем чуть-чуть до этого.

    https://github.com/Hirrolot/metalang99
    https://jadlevesque.github.io/PPMP-Iceberg/

    Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
    И оно компилится действительно очень долго.
    Кроме TCC, он быстр даже в этих шаблонах. Правда, чуть-чуть бажит.

     
     
  • 5.61, Аноним (-), 23:41, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
    > И оно компилится действительно очень долго.

    А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею.

    Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.

     
  • 4.56, Аноним (-), 23:32, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой.
    > Это шаблоны можно заставить компилироваться сколь угодно долго.

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

     
  • 4.69, oficsu (ok), 23:48, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это шаблоны можно заставить компилироваться сколь угодно долго

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

     
     
  • 5.214, Аноним (214), 10:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тормозящие шаблоны целиком типичная ситуация в 100% проектов. Программы на этом языке компилируются дольше всего.
     
     
  • 6.408, Аноним (293), 20:31, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шаблоны это compile time. Ну и хрен с ними, сколько им компиляться. Главное, чтобы потом сгенерённый код быстро работал.
     
  • 3.30, Bottle (?), 22:29, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ещё макросы не анализируются также хорошо как шаблоны через статический анализ.
     
  • 2.4, Аноним (4), 21:47, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?
     
     
  • 3.32, _hide_ (ok), 22:36, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А кто сказал, что раст можно? Пока что раст -- это для модулей, которые с ванилью собирать не обязательно
     
     
  • 4.51, Витюшка (?), 23:18, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это сказал Линус в интервью, что ожидается большее использование в базовых компонентах ядра.

    Те модули - это пока, проба пера.

     
     
  • 5.107, Аноним (107), 02:09, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет.
     
  • 3.204, Герман (??), 10:07, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследование классов, шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо, лишнее усложнение не нужно, высока цена ошибки

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

     
     
  • 4.252, Аноним (252), 12:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >гарантий безопасности

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

     
     
  • 5.255, Герман (??), 12:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Средства, использования которых необязательны? Было бы в плюсах все хорошо с безопасностью, не было бы придумано столь много безопасных замен ему. Раст учит разработчиков с самого начала изучения следить за правильной работой с памятью, не давая некорректному коду скомпилироваться

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

     
  • 4.347, Аноним (341), 16:51, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо

    Давайте полюбуемся на простые _Generic-макросы в ядре. И вообще на макросы.

    https://github.com/torvalds/linux/blob/052d534373b7ed33712a63d5e17b2b6cdbce84f
    https://github.com/torvalds/linux/blob/052d534373b7ed33712a63d5e17b2b6cdbce84f

     
  • 2.6, Аноним (6), 21:50, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)
     
  • 2.7, Аноним (7), 21:50, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже в Gentoo завезли бинарное ядро.
     
     
  • 3.36, Аноним (36), 22:43, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для истинных гентушков это ничкго не изменило.
     
     
  • 4.105, Аноним (105), 02:02, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.
     
     
  • 5.452, Аноним (452), 00:06, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.
     
     
  • 6.517, Аноним (115), 13:49, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно собирать всё ядро. В других линуксах всё же обычно дают возможность пересобрать всё и это очень долго, а ксатомизировать крайне геморно
     
     
  • 7.601, Аноним (-), 04:16, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Yolo Я майнлайне кернель под дебианом собираю В билдсистеме ядра даже есть ген... большой текст свёрнут, показать
     
     
  • 8.623, Аноним (623), 16:35, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля Сложно... текст свёрнут, показать
     
     
  • 9.647, Аноним (-), 18:46, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО где как На десктопе я от дистровского конифига танцевал, таргетируя более-... большой текст свёрнут, показать
     
  • 2.8, maximnik0 (?), 21:51, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.

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

     
     
  • 3.63, Аноним (-), 23:43, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.
    > С выкидыванием всякого хлама,там такого всего накопилось ......

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

     
     
  • 4.458, Аноним (452), 00:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
     
     
  • 5.475, Аноним (-), 02:52, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход
    > на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный.
    > Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.

    А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю.

    На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).

     
  • 4.583, _kp (ok), 21:47, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это в прошлом было такое А сейчас что скорость компиляции примерно одинакова,... большой текст свёрнут, показать
     
     
  • 5.603, Аноним (-), 04:30, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, конечно Запускаем допустим libaom компилиться И чего-то сишная часть тика... большой текст свёрнут, показать
     
     
  • 6.615, _kp (ok), 12:26, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если например пересборка компилятора esp32s3 и системы сборки сократила время сб... большой текст свёрнут, показать
     
     
  • 7.673, Аноним (-), 16:53, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я ESP не использую, и врядли буду когда либо Так что это знание может и будет п... большой текст свёрнут, показать
     
     
  • 8.674, _kp (ok), 19:21, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как нас унесло Изначальный смысл был скормить си исходники компилятору с , а н... большой текст свёрнут, показать
     
     
  • 9.675, Аноним (-), 20:34, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот те раз А я то думал изначальный смысл - оценить технологию, по возможности ... большой текст свёрнут, показать
     
  • 2.20, Аноним (20), 22:12, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А зачем вы его постоянно пересобираете?
     
     
  • 3.40, Аноним (36), 22:46, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    2.6.32 работает - не трожь!
     
  • 3.60, anonymous (??), 23:39, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что оно багованное.

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

     
     
  • 4.104, Аноним (20), 01:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так это ж надо желать один раз, когда хочется попробовать новую версию. А один раз - какая разница, сколько оно собирается? Это ж не 200 тысяч запросов в секунду где время обработки имеет значение.
     
  • 3.77, Аноним (77), 00:06, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем вы его постоянно пересобираете?

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

     
  • 3.277, pv (?), 13:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А зачем вы его постоянно пересобираете?

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

    да и чего мелочиться, в ядре просто необходим питон, яваскрипт, го, и вижуалбэйсик!
    и систему сборки ещё обязательно поменять, а то несовременно как-то.

     
  • 2.27, Аноним (27), 22:27, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    опять огульные выдуми кро скорость сборки. когда же вы успокоитесь, выдумщики
     
  • 2.34, Аноним (36), 22:40, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Запаримся пересобирать же! Си собирается намного шустрее.

    А что вы про Rust запоёте?

     
     
  • 3.179, Проходил мимо (?), 08:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Судя по комментариям, большинство из тех, кто "поет" на OpenNET про Rust разбираются в нем примерно как свинья в апельсинах. Хотя, возможно, свинья разбирается все же лучше.
    Хейтеры, которые ниАсилили. Естественно, что у любого, кто в теме вопли всяких криворуких рукожопов вызывают лишь гомерический смех.
    PS Это не значит, что Rust идеальный и у него нет проблем. Некоторые вещи там сделаны не лучшим образом.
     

     ....большая нить свёрнута, показать (45)

  • 1.3, Аноним (3), 21:46, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    > В списке рассылки

    Шёл 2024 год...

     
     
  • 2.5, Аноним (3), 21:47, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    П.с. Так там ещё и 80 символов ограничение 🤦‍♀️
     
     
  • 3.9, Аноним (9), 21:53, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > checkpatch/coding-style: deprecate 80-column warning

    https://lkml.org/lkml/2020/5/31/326

     
  • 3.72, Аноним (115), 23:57, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменяли бы их на пробелы
     
     
  • 4.118, Аноним (107), 02:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А лучше трем символам. Или может восьми, видел и такое.
     
     
  • 5.296, Аноним (296), 14:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В ядре как раз-таки 8
     
     
  • 6.451, InuYasha (??), 00:04, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    *стирает исходники ядра пры..линукса*
    фу.
     
  • 5.313, Аноним (313), 14:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Яваскриптеры голосуют за два пробела.

    В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.

     
  • 4.291, Аноним (293), 13:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, следовательно, не едет.
     
     
  • 5.304, rmh (?), 14:34, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Лучше пробелы

    Не лучше. Таб = 1 байт, пробелы >1 байта.

     
     
  • 6.521, n00by (ok), 14:11, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Не лучше. Таб = 1 байт, пробелы >1 байта.

    И что?

     
  • 5.311, Аноним (313), 14:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > не зависит от настроек редактора кода и, следовательно, не едет.

    Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.

     
     
  • 6.391, Аноним (391), 19:14, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    едет, если умственно-ограниченные начинают использовать табуляцию не для индентификации кода (и использовать этот символ строго в начале строки до первого не-пробельного), но и пытаются табуляцией что-то форматировать в середине строки.
     
     
  • 7.420, Аноним (313), 21:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Фанаты пробелов - это потомки тех, кто в 90-х в офисе вместо настройки первой строки абзаца отбивали этот отступ пробелами.
     
  • 4.315, Аноним (313), 15:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бредите. Табуляция - это табуляция, ОДИН символ. Что значит "равной 4 символам"?
     
     
  • 5.321, Аноним (115), 15:17, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    TAB это терминальный опкод, а не символ. Ровно как и все ASCII символы до 0x20 не символы.
     
     
  • 6.376, VladSh (?), 18:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну пусть будет 1 оп. код вместо четырёх; есть же разница?
     
     
  • 7.453, InuYasha (??), 00:07, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    когда я в подном большом проекте заменил все отступы на табы (вместо 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...
     
     
  • 8.477, Аноним (-), 02:55, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А еще на несколько мегов меньше читать и парсить компилеру whitespaces до лампо... текст свёрнут, показать
     
  • 8.482, Аноним (482), 06:37, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Производительность взлетела до небес, наверное ... текст свёрнут, показать
     
  • 7.520, Аноним (115), 13:53, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что такой тугой, TAB равен изначально 8-и символам и это неудобно. Что породило со временем кастомные настройки размера TAB-ов, например, более практичный 4 символа. И по факту теперь это плаваяющая единица из-за чего при разных настройках едет форматирование текста. Потому TAB в современном мире непригоден для использования. Ситуацию можно починить если вхерачить в UTF специальные коды для TAB-ов разного размера или же инструкцию с заданием длины TAB-ов.
     
     
  • 8.531, Аноним (525), 14:56, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё раз, специально для вас Форматирование при использовании табов едет только ... текст свёрнут, показать
     
     
  • 9.565, Аноним (115), 17:52, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какой и ты тугой Форматирование в общем случае едет всё равно потому что TABы к... текст свёрнут, показать
     
     
  • 10.566, Аноним (115), 17:55, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Типичный, кстати, пример, где всё это едет, как раз линуксовое ядро, которое пиш... текст свёрнут, показать
     
  • 8.584, _kp (ok), 22:00, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с ... текст свёрнут, показать
     
     
  • 9.676, Капитан О. (?), 20:37, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На печатных машинках чужие исходники не отображали так что там проблема с тем чт... текст свёрнут, показать
     
     
  • 10.681, _kp (ok), 18:23, 22/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    TAB - был не символом, а кодом движения печатающей головки или руки оператора П... текст свёрнут, показать
     
  • 2.10, nich (ok), 21:58, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да вообще тупые.  Пора уже на слак перейти, или накрайняк на дискорд.  Я уже устал читать их многостраничные сообщения в рассылке.  В слаке или в дискорде каждое сообщение будет не более двух-трех строчек.
     
     
  • 3.137, Вы забыли заполнить поле Name (?), 03:14, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Лучше в твиттер (или как она там называется теперь)
     
  • 2.16, Аноним (16), 22:05, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ... и до сих пор не придумали ничего лучше, чем форум. Даже в виде рассылки.
     
  • 2.109, Аноним (107), 02:12, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки и их архивы будут на месте.
     
  • 2.160, Тот_Самый_Анонимус_ (?), 05:36, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Шёл 2024 год...

    О, кто-то календарь перевернул!

     

     ....большая нить свёрнута, показать (31)

  • 1.11, Аноним (11), 21:59, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax

    Это он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.

     
     
  • 2.81, Аноним (81), 00:13, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
     
     
  • 3.100, Витюшка (?), 01:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода.

    Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.

    Это как раз для передачи json по http синтаксис не столь важен, "можно потерпеть", не критично.

    Попробуй разобрать алгоритм на brainfuck.

     
     
  • 4.573, Аноним (573), 18:57, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.

    Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на это описание и, по необходимости, прокомментирована. В случаях когда реализация использует оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать с тем же успехом.

     
     
  • 5.575, n00by (ok), 19:09, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это верно, но есть нюанс Идея самодокументированного кода позволяет автору со... большой текст свёрнут, показать
     
     
  • 6.648, Аноним (-), 18:50, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
    > хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
    > прав по лицензиям типа GPL. Потому имеем, что имеем.

    В каком месте GPL лишает кого-то имущественных прав? Цитату?

     
     
  • 7.659, n00by (ok), 08:36, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
    >> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
    >> прав по лицензиям типа GPL. Потому имеем, что имеем.
    > В каком месте GPL лишает кого-то имущественных прав?

    В месте замены "право" на "лево".

    > Цитату?

    "copyleft"

     
     
  • 8.661, Аноним (-), 11:26, 20/01/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 9.669, n00by (ok), 15:36, 20/01/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.170, Аноним (170), 07:22, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
     
     
  • 4.197, Советский инженер (ok), 09:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >... но определённо лучше Rust и C++

    с этим тоже можно поспорить, т.к. на читиаемость влияет и количество строк и goto всякие.

     
     
  • 5.582, adolfus (ok), 20:33, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В С++ есть большая проблема -- ссылки в перечне параметров функции. Это препятствует использованию там r-value. А как известно, любое l-value в программе добавляет +1 к пулу потенциальных проблем безопасности и программных ошибок.
    Что касается goto, то без него вы даже из вложенного цикла не выйдете. Вернее, выйдете, но через виртожопу.
     
     
  • 6.609, Аноним (609), 08:27, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Что касается goto, то без него вы даже из вложенного цикла не выйдете.

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

    >Вернее, выйдете, но через виртожопу.

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

     
     
  • 7.614, adolfus (ok), 12:04, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так пройдитесь просто по двумерному массиву. Когда-нибудь изображения обрабатывали? А гиперспектральные, которые трехмерные массивы?
    Парсер простой напишите без goto для какого-нибудь примитивного языка, например, для джейсона. Все без исключения FSM-алгоритмы, коими и являются эти самые синтаксические анализаторы, работают на goto безальтернативно.
     
  • 6.610, Аноним (609), 08:32, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Что касается goto, то без него вы даже из вложенного цикла не выйдете.

    "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.

     
     
  • 7.616, adolfus (ok), 12:34, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Каше-френдли программирование начинается прежде всего с безальтернативного исп... большой текст свёрнут, показать
     
     
  • 8.622, n00by (ok), 14:45, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Предсказание и предвыборка команд работают для call ret начиная с NetBurst и дл... текст свёрнут, показать
     
  • 4.397, warlock66613 (ok), 19:53, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И Rust и C++ более выразительные языки чем C, и именно поэтому код на них гораздо проще читать.
     
     
  • 5.585, _kp (ok), 22:07, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понимаемо, но не так. ;)
    То есть, в плане оформления исходника, позволяют "прострелить себе ногу".


     
  • 5.635, wyry (?), 18:20, 18/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Несмотря на то, что я топлю за C++, не могу не придраться, что C++ ОЧЕНЬ опасен в плохих руках и там легко допустить плохие решения (как по семантике, так и по читаемости кода). Но преимущество C++ в том (и об этом говорили многие задолго до китов), что C++ напрямую связан с C и всё можно переписывать плавно не боясь что-то сломать.
     
  • 3.490, scriptkiddis (?), 10:01, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и че ты не переписал еще все ядро на brainfuck?
     
  • 2.248, Аноним (248), 11:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
     
     
  • 3.258, Аноним (258), 12:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это объясняется легаси.
     
     
  • 4.316, Аноним (313), 15:05, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Могу назвать ещё минимум две причины, по которым
    ls -l
    Лучше, чем
    list-files-and-directories --show-as-much-details-as-possible
     
     
  • 5.382, Аноним (-), 18:59, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Могу назвать ещё минимум две причины, по которым
    > ls -l
    > Лучше, чем
    > list-files-and-directories --show-as-much-details-as-possible

    Вы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.

     
     
  • 6.393, Аноним (341), 19:24, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +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

     
     
  • 7.446, Аноним (446), 23:57, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Наоборот же, powershell показывает, что можно всем угодить
    > изкоробочными алиасами и parameter name matching'ом

    Он мне так угАдил своим синтаксисом, километровыми командами и очешуенным временем старта на виртуалках что я как раз и развидел маздайку к хренам. И назад уже никогда не вернусь, хоть там что. Простите но какую задачу решает (ba)sh я понимаю. Какую задачу решает это индусское месиво я не понимаю. Мне такой шелл - без надобности. Совсем. Одно это уже бьет наповал ваше "всем"  наличием конкретного контрпримера.

    Не, я в принципе не собираюсь столько на клаве печатать в шелле. А когда там еще и автодополнение такое как там, пути с пробелами, и брейнфак с типизацией (в шелле!!!) - ну, знаете, вот пусть авторы этого и пользуются им.

     
     
  • 8.476, Аноним (341), 02:54, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна ... текст свёрнут, показать
     
     
  • 9.479, Аноним (-), 03:04, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В результате самое крутое что есть в шелле ака мелкая автоматизация системной ру... большой текст свёрнут, показать
     
     
  • 10.546, Аноним (546), 15:53, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя опять что-ли шиза долбает, 294й То что по умолчанию идёт с PSReadLine ты о... текст свёрнут, показать
     
     
  • 11.649, Аноним (-), 19:03, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну во первых я вобью проблему в поискарь и скопипащу 90 решения Во вторых я не... большой текст свёрнут, показать
     
     
  • 12.684, Аноним (684), 19:00, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя как 294й, с способностью понимать тексты Проблема Скопипасть в поискарь... большой текст свёрнут, показать
     
     
  • 13.685, Аноним (-), 21:48, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Меня от шелла интересует 2 сценария oneliner руками на 1 раз, here and now Л... большой текст свёрнут, показать
     
  • 13.690, Аноним (690), 06:18, 24/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Резюмируя два Инфоцыган 294й забыл сам с чего начал автодополнения нет, коротки... большой текст свёрнут, показать
     
  • 6.586, _kp (ok), 22:10, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > автодополнение в том уродце не работает по сути никак,

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

     
  • 4.322, Аноним (115), 15:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
     
     
  • 5.439, fuggy (ok), 23:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То-то наверно лучше в C++ когда звёздочка обозначает сразу 4 разных операции. А без функциональщины, лямбд современный язык уже не язык. В Rust итераторы более читабельные, чем императивная возня с указателями. В C++ между прочем тоже лямбды есть со своим специфическим синтаксисом.
     
  • 2.406, Аноним (-), 20:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax

    Или это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"

     
     
  • 3.499, Аноним (499), 11:14, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
     
  • 3.574, Аноним (573), 19:03, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
     
     
  • 4.691, Stellarwind (?), 15:39, 25/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Линуса просто уже ранее настойчиво попросили быть повежливее..

    Странно что еще никто не запостил: 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.

     
     
  • 5.692, n00by (ok), 17:02, 25/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На это я отвечал в 211 И на это тоже Правда, не на цитату Линуса, а на изложен... большой текст свёрнут, показать
     

     ....большая нить свёрнута, показать (41)

  • 1.12, Витюшка (?), 21:59, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Легендарная битва. Интересно чем закончится. Но сразу и Rust и C++ одновременно - это совсем не good.

    Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).

     
     
  • 2.15, Витюшка (?), 22:05, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.

    Но за Rust хайп и очень фанатичное комьюнити, которое толкает его куда только можно.

    Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.

     
     
  • 3.21, Аноним (11), 22:12, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал.
     
  • 3.29, jjklh (?), 22:28, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    По моим, наверное, второе дыхание было с C++0x/C++1y. А вот уже с C++1z/C++2a и дальше язык просто рванул в космос.
     
  • 3.67, Аноним (-), 23:47, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.

    Как там у него с портабельностью и вообще готовностью к проду? Вот представьте что завтра билдим кернел им для вашего десктопника. Как, прокатит? Без факапищ?

     
     
  • 4.101, Витюшка (?), 01:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, нет. Я и говорю что некому топить за него.

    Топить - не только в рассылках писать "а давайте zig", а именно допилить до применения в ядре.

    Основа там заложена очень крутая.

     
     
  • 5.385, Аноним (-), 19:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > К сожалению, нет. Я и говорю что некому топить за него.
    > Топить - не только в рассылках писать "а давайте zig", а именно
    > допилить до применения в ядре.
    > Основа там заложена очень крутая.

    Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.

     
     
  • 6.423, Витюшка (?), 22:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В основном языки имеют одну реализацию. С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Как и С.

    Rust никогда не будет допилен в gcc. Я специально смотрел - пилят какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты.

    Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда (в обозримом будущем).

    Но пропихнуть Rust в kernel это не помешало 😄

     
     
  • 7.442, Аноним (446), 23:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    гарантирующую 100 вендорлок, что после си и си как бы нефиговый регресс, е... большой текст свёрнут, показать
     
  • 3.135, Вы забыли заполнить поле Name (?), 03:05, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.

    Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные всем вещи?

     
     
  • 4.175, Аноним (175), 07:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-что от стула.
     
     
  • 5.317, Аноним (313), 15:07, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > заставил оторвать кое-что от стула

    Пару ножек?

     
  • 4.387, Аноним (-), 19:06, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.
    > Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные
    > всем вещи?

    А в rust что-то вообще СТАНДАРТИЗОВАНО?! У него ж ни единой версии стандарта нет. По крайней мере от нормальных standard body. Не, куча хипстеров хаотично корежащих синтаксис под заскоки левой своей пятки и приказ своего корпо-хозяина - это не оно. Вообще совсем. И вот как-то так получается что у хруста нет вообще ни 1 стандарта. В отличие от C++.

     
     
  • 5.395, Советский инженер (ok), 19:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    типа на стандартном С можно ядро написать!?

    вот умора, язык разработан для написания ядер и прочей системщины более 50 лет назад.
    имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не собираются.

    и эти же "стандартизаторы" вещают про стандарты.

     
     
  • 6.445, Аноним (446), 23:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > типа на стандартном С можно ядро написать!?

    Ну, почти. Режим freestanding официально специфицирован с C99 аж. Там правда пары вещей не хватает, это таки вот именно гнутые экстеншны.

    > вот умора, язык разработан для написания ядер и прочей системщины более 50
    > лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не
    > собираются. и эти же "стандартизаторы" вещают про стандарты.

    Потому что в целом код conformant, плюс-минус очень небольшое число мест. А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Наверное так и надо...

     
     
  • 7.500, Советский инженер (ok), 11:20, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Там правда пары вещей не хватает ...

    дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то другое.
    Отличные стандарты! 🤣


    >А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис.

    Именно поэтому компиляция ядра клангом периодически отваливается? ведь так?
    Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах?
    СТАНДАРТ !!! о таком только мечтать!

     
     
  • 8.650, Аноним (-), 19:17, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Хрустики даже и так не смогли Все познается в сравнении которое они и не выд... большой текст свёрнут, показать
     
     
  • 9.660, Советский инженер (ok), 11:13, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Хрустики смогли пробиться в ядро, а С со всеми своими стандартами не смог Оче... текст свёрнут, показать
     
     
  • 10.662, Аноним (-), 12:17, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Они пока так пробились что постоянно переделывают свое месиво, постоянно надо са... большой текст свёрнут, показать
     
     
  • 11.679, Советский инженер (ok), 21:44, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ты как ни плюйся желчью, а факт есть факт раст в ядре а плюсы нет точно не в... текст свёрнут, показать
     
     
  • 12.686, Аноним (-), 21:54, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В ядре много чего было И не все из этого с нами сейчас Так что это само по себ... большой текст свёрнут, показать
     
  • 2.17, Аноним (6), 22:06, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).

    Возможно потому что его компилятор работает только на последних версиях систем?

     
     
  • 3.23, Витюшка (?), 22:15, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig.

    https://docs.kernel.org/kbuild/llvm.html

    Да и ядро и так компилится с помощью llvm.

     
     
  • 4.41, Аноним (41), 22:50, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот только для ядра будет требование сборки с использованием gcc.
    Для раста из-за этого начали делать gccrs, было утверждено добавление GCC 13 (https://www.opennet.me/opennews/art.shtml?num=57491) в виде беты и так далее.
    А что у Зига? Разве есть хоть какие-то подвижки?
     
     
  • 5.54, Витюшка (?), 23:26, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, вот и нужны кто будет двигать Zig и возьмётся за добавление к gcc. Это должны быть компании, но таких пока нет.
     
  • 4.68, Аноним (-), 23:48, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig.

    Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в git, ибо LLVM не особо то кроссплатформенная штука и далеко не все архитектуры поддерживает. Здорово сливая GCC по поддержке железа.

     
     
  • 5.76, Аноним (-), 00:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    У LLVM все прекрасно с поддержкой платформ.
    Это GCC поддерживает всяких хлам и некроплатформы
     
     
  • 6.145, jjklh (?), 03:38, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > У LLVM все прекрасно с поддержкой платформ.
    > Это GCC поддерживает всяких хлам и некроплатформы

    ну, ладно выкинут поддержку неподдерживаемых платформ из ядра, потому что, допустим, ядро пишут для llvm, а не наоборот. Но с этим https://clangbuiltlinux.github.io/ что делать? Оно ж тупо не собирает ядро трехлетней давности, Карл!!!

     
     
  • 7.226, Аноним (41), 10:53, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ну, ладно выкинут поддержку неподдерживаемых платформ из ядра

    При чем тут все платформы? Зачем тебе новейший драйвер напр. сетевухи на 100Гб на PDP-11 или System/370?
    Сильно убудет если он не будет там поддерживаться, если он не компилится из-за шланга? Шланг даже m68k тяшет.
    Приведи пожалуйста пример, отсутствие какой архитектуры - блокер.

    > Оно ж тупо не собирает ядро трехлетней давности

    А ты обратил внимание, что андроиды собираются все, кроме android15‑6.6 старыми шлангами?
    Не задумался почему так? Может просто гугл следит за этим и исправляет в ядре/шланге что нужно?
    Вот если и в ядре будут следить, то компилится будет. Или ты думаешь что gcc просто самом собой начинает поддерживать все без проблем?

     
  • 6.390, Аноним (-), 19:12, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > У LLVM все прекрасно с поддержкой платформ.
    > Это GCC поддерживает всяких хлам и некроплатформы

    BSDшники уже пробовали рассказывать сказку про (не)нужные всем фичи. И где они теперь? Вот и вы туда же с этим всем отправитесь. По тем же причинам. Мне вот например не нужны тулчейны где так внаглую лечат что мне (не)нужно. Я и не буду такими тулчейнами пользоваться.

     
  • 2.602, Аноним (20), 04:29, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да нет там никакой битвы, тем более легендарной. Очень вялая дискуссия где одни челы говорят, что Раст всё равно лучше, а другие челы обсуждают все причины, по которым С++ впилить в кернел не получится, во всяком случае что бы с++ при этом оставался полезным.
     

     ....большая нить свёрнута, показать (30)

  • 1.13, Аноним (13), 22:04, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости наговорил глупостей. Но из-за такого китайского концепта как "потеря лица" он не может признать, что говорил глупости.

    Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений (да, я знаю, они тяжёлые. Но в C++ есть модули, в них такие вычисления закешируются). Но необходимо ввести жёсткую конвенцию по написанию кода о том, что должно линковаться на уровне хэдеров, что - статически, а что - динамически, и разработать линтер. Без линтера тут никуда. За header-only нужно сразу от разработки отлучать с волчьим билетом.

     
     
  • 2.79, Аноним (115), 00:09, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Ты как тогда не хотел понимать какие претензии были к с++, так сейчас не будешь разбираться что же изменилось в лучшую сторону.

    > Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за...

    Кроме из-за ещё есть и аргументы против. Твоё выдёгивание только из-за' ничего не стоит

     
     
  • 3.94, Аноним (94), 00:53, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё.

    Он высказался не о языке. Он не подумав (зачем ему думать, он же диктатор-хозяин-барин и ядро - его собственность! правда потом спонсоры ему пояснили, who is who.) ляпнул, что недопуск C++ в ядро - это мера по недопуску в ядро программистов N-го сорта - программистов на C++. Если теперь он допустит в ядро программистов на C++, то ему придётся признавать 3 вещи:
    1. что программисты на C++ - это не программисты N-го сорта
    2. что Линус необоснованно из личной гордыни задел достоинство программистов на C++
    3. что оттолкнув по мотивам личной гордыни и неприязни определённую группу программистов Линус проявил непрофессионализм и замедлил развитие проекта

     
     
  • 4.110, Аноним (115), 02:14, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю о каком именно высказывании говоришь, я видел только где в основном обсуждался ЯП
     
     
  • 5.189, 11 (?), 09:18, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +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
     
     
  • 6.211, n00by (ok), 10:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > a lot of substandard programmers use it

    Линус знатно потроллил. Никто ведь не заставлял принимать "a lot" на свой счёт.

     
  • 4.318, Аноним (313), 15:11, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > то ему придётся признавать 3 вещи:

    - что теперь программисты N-го сорта допущены в ядро.

     
     
  • 5.368, Аноним (368), 18:33, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тут у Линуса осталось 3 варианта действий 1 покаяться за вред, нанесённый прое... большой текст свёрнут, показать
     
     
  • 6.410, Аноним (-), 20:38, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?"
    Более того, а за что каяться?
    От добавления С++ ядро лучше бы не стало, по аналогии с Сишкой С89 сидели бы на С++98 до 2022 года(
    Так что никаких смартпойнтеров и прочих даров цивилизации.

    Более того подозревая, что дудуки пилящие ядро начали бы писать в стиле "как умеют".
    ИМХО тогда стало бы еще хуже.

     
     
  • 7.460, Аноним (460), 01:14, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?"

    Какой третий? Весь сишный код фиксится до совместимости с clang++  и объявляется плюсовым.

     
  • 4.587, _kp (ok), 22:32, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>Линус может сказать, что уже прошло много времени и язык существенно изменился
    > Он высказался не о языке.

    Речь о c++ образца 2007г или ранних.
    Вы сами то хотите на них писать? Ладно, это мелочь.

      А по существу. Тогда был подъем моды на объектное программированиее, причем где надо и ненадо, и даже там где это вредно.
      И фраза про С++ "намного легче генерировать полную чушь" была не безосновательна.
    Дай дураку инструмет, на котором он легко сделает говнокод, и он именно его и напишет.
      Аналогична ситуация с количеством говнокода на Делфи и Питоне, и совсем не потому что языки плохи, а потому что позволяют навалить кучу по быстрому.

     
  • 2.86, Синий попугай (ok), 00:18, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разрешите поинтересоваться? Что именно подразумевает header only и почему это настолько плохо?
     
     
  • 3.97, Аноним (97), 01:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Либа со сложным и или большим кодом а если код простой и небольшой, который воо... большой текст свёрнут, показать
     
     
  • 4.164, n00by (ok), 06:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > и в каждый бинарь включена своя копия реализации.

    Подтверждением в виде дизассемблерного листинга не порадуете?

     
     
  • 5.267, Аноним (-), 12:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> и в каждый бинарь включена своя копия реализации.
    > Подтверждением в виде дизассемблерного листинга не порадуете?

    Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы.

    А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.

     
     
  • 6.360, Аноним (293), 18:12, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
     
     
  • 7.461, Аноним (460), 01:18, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорных инструкций. Нетривиальные находятся в libstdc++.so.
     
     
  • 8.522, Аноним (115), 14:18, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Большинство основных STL частей чисто шаблонные Например, тот же std map генер... текст свёрнут, показать
     
  • 8.524, n00by (ok), 14:26, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли Для стан... текст свёрнут, показать
     
  • 6.523, n00by (ok), 14:22, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>> и в каждый бинарь включена своя копия реализации.
    >> Подтверждением в виде дизассемблерного листинга не порадуете?
    > Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали
    > - все три проги поюзают один shared lib, если либу так
    > собрать. Будет реюз кода либы.

    Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная библиотека для ядра header-only была 15 лет назад.

     
     
  • 7.663, Аноним (-), 12:25, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная
    > библиотека для ядра header-only была 15 лет назад.

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

     
     
  • 8.668, n00by (ok), 15:28, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что ты придумал тезис круто и офигенно , что бы приписать его мне В над... текст свёрнут, показать
     
  • 4.486, Аноним (486), 07:32, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Если всё линкуется в один бинарник, то вообще может быть ошибка линковки

    чудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)

     
     
  • 5.589, Аноним (589), 23:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Э... Очевидно имелось ввиду именно линковка.

    Один файл компилируется в объектник с включенным заголовочником.

    Другой файл генерируется объектник с включенным  заголовочником.

    Оба содержат одинаковые сгенерированные функции.

    Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.

     
  • 2.132, Вы забыли заполнить поле Name (?), 03:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > За header-only нужно сразу от разработки отлучать с волчьим билетом.

    Взял и boost опозорил.

     
     
  • 3.151, Аноним (115), 04:57, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    STL же, boost сама по себе помойка
     
     
  • 4.213, n00by (ok), 10:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > STL же

    Любопытно, сколько из присутствующих видели библиотеку Степанова и Ли.

     
     
  • 5.275, Аноним (293), 13:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Покажи, посмотрим.
     
     
  • 6.421, Аноним (421), 21:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если долго вглядываться в бездну, бездна начнет вглядываться в тебя.

    А вообще, всё зависит от прямоты рук.

    # Непустых строк:
    $  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

     
     
  • 7.422, Аноним (421), 21:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    $ 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
     
  • 7.526, n00by (ok), 14:34, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это не то.
     
  • 2.133, Вы забыли заполнить поле Name (?), 03:04, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений

    Почему бы это просто в C не добавить?

     
     
  • 3.194, Аноним (194), 09:44, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давно есть. Человек просто поумничать хотел
     
     
  • 4.361, Аноним (293), 18:14, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Шаблонов нет, а compile-time вычисления есть?
     
  • 3.238, Аноним (238), 11:20, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    C с этими добавлениями называется C++ :).
     
  • 3.298, Аноним (115), 14:16, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си как был бревном, так им и остался.  С другой стороны, плюсы постепенно движутся куда нужно, но медленно. Скорее уж в плюсах появится ABI, чем в Си занесут новые фичи
     
  • 2.150, fuggy (ok), 04:44, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем переписывать на C++ чтобы потом пришлось переписывать на Rust умалчивается.
     
     
  • 3.155, Аноним (115), 05:13, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На rust переписывать не придётся. Его засунули в ядро чтобы шумные детишки наигрались молча с какой и потом остали от ядра сами
     
     
  • 4.173, Аноним (173), 07:41, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже так считаю.
     
  • 4.253, Аноним (253), 12:38, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Раст - навсегда в ядре. Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
     
     
  • 5.302, Аноним (115), 14:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ничего нигде не бывает навсегда, ты сам тут не навсегда Как засунули, так и убе... большой текст свёрнут, показать
     
     
  • 6.310, Аноним (253), 14:51, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали раст. Платиновым спонсорам нужен раст, а плюсы им не нужны. Вот так вот...
     
     
  • 7.323, Аноним (115), 15:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо С++ и Go, тогда можно будет считать что  выбрали. Пока что это местячковые потуги, как и со всеми остальными модными технологиями. И опять таки, ничего не бывает навсегда, особенно у корпораций: у них бабла много и не жалко выкинуть игрушку на помойку в любой момент
     
  • 5.362, Аноним (293), 18:18, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен.

    А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.

     
  • 2.351, Аноним (341), 17:20, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Помимо политики была ещё одна причина - исключения в C++, хотя Линус тогда* не говорил, почему нельзя использовать плюсы без них.

    * https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.2311@home.osdl.o

     
     
  • 3.530, n00by (ok), 14:54, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Линус и не развернул тему "fundamentally broken". В ядре NT возможно использовать исключения на IRQL PASSIVE_LEVEL, если очень захочется разрешить политикой проекта.
     

     ....большая нить свёрнута, показать (45)

  • 1.19, Аноним (19), 22:11, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >В качестве минимальной упоминается использование спецификации C++14

    Не, нужно сразу 26 в редакции clangа на сегодняшний день брать. Потому что без ranges делать compile-time вычисления невесело. Хоть в шланге и нет ещё полноценных ranges, уже то что есть - очень полезно и убирает кучу того, что либо вручную приходилось держать в актуальном состоянии или скриптом генерировать (напр. индекс максимального элемента массива из фиксированных compile-time значений). magic_enum вообще офигенно полезная либа. Она хоть и header-only, но она не приводит к оверхеду на каждый включённый экземпляр, как если бы nlohmann json включили в один модуль, а потом во второй, и всё header-only. Другая офигенна полезная либа - это ctre.

     
     
  • 2.195, Аноним (194), 09:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот честно... чем пользоваться этой синтаксической ахинеей проще написать в 5 строк скрипт на том же питоне для предвычислений
     
     
  • 3.279, Аноним (279), 13:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того же на разных языках и гемороиться с интеграцией питоньего скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, я лучше ranges поюзаю.
     
     
  • 4.309, Аноним (-), 14:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И огрести на ровном месте проблем, в частности тащить 2 реализации одного
    > и того же на разных языках и гемороиться с интеграцией питоньего
    > скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо,
    > я лучше ranges поюзаю.

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

    Да, блин, знаете, когда начинает сыпаться с 9000 разных сторон - таки, впадлу!

     
     
  • 5.357, Аноним (115), 17:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В пакетах всё ещё можно поставить второй питон. Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно - любая кодогенерация зло.
     
     
  • 6.394, Аноним (-), 19:27, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В пакетах всё ещё можно поставить второй питон.

    Это в каких бы таких пакетах? Поддержку питона2 вынесли сами питоняши еще сколько там назад. Линуксные дистры и вынесли его - они быть святее папы римского не собираются, майнтайня софт за питоняш.

    > Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно
    > - любая кодогенерация зло.

    Оно и видно что там не сломается. В дебиане 12 было аж 3000 чтоли багов на эту тему. Всего-то, блин. Они и задропали половину софта к хренам, им что, больше всех надо?!

     
  • 6.424, Аноним (421), 22:04, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Итерация свойственна человеку, кодогенерация божественна.
     
  • 2.289, Аноним (293), 13:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Засуньте ваш Шланг в... Ядрописатели требуют обязательность сборки GCC.
     
     
  • 3.371, Аноним (371), 18:39, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому анализу, удобству использования и скорости результирующего кода. Тех же концептов до сих пор нет, и это создаёт проблемы для кода, который написан под gcc. Если шлангоспецифичные расширения не юзать - то gcc соберёт то, что собирается шлангом. Поэтому ориентироваться надо именно на собираемость шлангом.
     
     
  • 4.383, Аноним (293), 19:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если разработчики ядра захотят обязательно эти концепты, то разработчики GCC пойдут навстречу. Почему нет?
     
     
  • 5.467, Аноним (460), 02:10, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    в шланге нет концептов, в gcc они есть. Если задействовать код на концептах - то шлангом собираться не будет. А собирать лучше шлангом.
     
     
  • 6.590, Аноним (589), 23:16, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С чего вдруг лучше то?
     
     
  • 7.636, Аноним (636), 23:59, 18/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    См. рис. 1.
     

  • 1.22, Placeholder (ok), 22:14, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Как раз схожесть синтаксиса это скорее надостаток, потому что внешнее соходство вообще не означает что под капотом будет схожее поведение. Этакие "ложные друзья переводчика".
     
     
  • 2.26, Аноним (173), 22:25, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и си этого не гарантирует как и большинство высокоуровневых языков с >1 компиляторов.
     
     
  • 3.216, n00by (ok), 10:31, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это гарантируют стандарты и Си, и Си++, а вот смешивание языков может привести к проблемам. Например, наверняка потребуют запретить перегрузку, что бы не вызвать у некоторых культурный шок.
     
  • 2.28, Bottle (?), 22:28, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Главные различия, которые следует запомнить:
    В стандарте C++ нет Value Length Array (хотя GCC, Clang поддерживают их), приведение типов немного иное, ABI отлично.
     
     
  • 3.31, Аноним (31), 22:34, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте  опциональным.
     
     
  • 4.58, Аноним (58), 23:38, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
     
     
  • 5.70, Аноним (-), 23:54, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В том что 1 Никогда не знаешь когда этот код навернется 2 Способов узнать ... большой текст свёрнут, показать
     
     
  • 6.99, Аноним (99), 01:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти.

    > Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.

    При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.

     
     
  • 7.106, Аноним (115), 02:08, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
     
     
  • 8.126, Аноним (126), 02:51, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тьфу, действительно мегабайт, перепутал с гигами С выделением на стеке тоже мож... текст свёрнут, показать
     
     
  • 9.127, Аноним (115), 02:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но почему-то проверок места на стеке нигде нет... текст свёрнут, показать
     
  • 8.297, Аноним (-), 14:10, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    1 Ну попробуй так на AtMega какой-нибудь Правда, грохаться этот убогий не у... большой текст свёрнут, показать
     
     
  • 9.326, Аноним (115), 15:34, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какое отношение аппаратные исключения имеют к условному libc, или аллокатору пам... текст свёрнут, показать
     
     
  • 10.405, Аноним (-), 20:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется А вот и хрен, э... большой текст свёрнут, показать
     
  • 10.426, Аноним (-), 22:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется А вот и хрен, э... большой текст свёрнут, показать
     
  • 9.533, n00by (ok), 15:00, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это и на AMD64 не работает ... текст свёрнут, показать
     
  • 7.124, Аноним (-), 02:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если я статически пишу uint8_t arr 10 я имею основания полагать что это будет ... большой текст свёрнут, показать
     
     
  • 8.138, jjklh (?), 03:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    кто сказал раст ... текст свёрнут, показать
     
  • 8.139, Аноним (149), 03:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сишечка не системная - также можно исчерпать стек, вызывая функции Особенно есл... текст свёрнут, показать
     
     
  • 9.283, Аноним (-), 13:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да А кто у нас тогда системный то На сях что-то большая часть системщины, бутл... большой текст свёрнут, показать
     
  • 8.140, Аноним (140), 03:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В некоторых компиляторах есть builtin, позволяющий проверить наличие места на ст... текст свёрнут, показать
     
     
  • 9.292, Аноним (-), 13:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто вопрос был почему VLA не рекомендуют в системщине Ну вот потому В сях в... большой текст свёрнут, показать
     
     
  • 10.375, Аноним (375), 18:48, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Локальные переменные живут в стеке VLA в принципе может жить где угодно, но нуж... текст свёрнут, показать
     
     
  • 11.429, Аноним (-), 23:02, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Читайте стандарты си Там вообще нет упоминания стека, никак и нигде То что кон... большой текст свёрнут, показать
     
  • 8.146, Аноним (149), 03:41, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, не будет Во всех тестах в массив будут записаны 1-3 байта и они ничего... текст свёрнут, показать
     
     
  • 9.290, Аноним (-), 13:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них тойота и полу... большой текст свёрнут, показать
     
     
  • 10.345, Tron is Whistling (?), 16:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Главное, чтобы у тебя этот суровый r эксепшн tm не произошёл во время полёта н... текст свёрнут, показать
     
     
  • 11.413, nothingaboutdog (?), 20:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 ... текст свёрнут, показать
     
  • 11.431, Аноним (-), 23:08, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если это важно - это решается другими методами См как это кажется, боинг сдела... текст свёрнут, показать
     
     
  • 12.503, Tron is Whistling (?), 11:27, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не гидравлический пресс надеюсь А то fail fast может в fall fast перейти D... текст свёрнут, показать
     
  • 12.504, Tron is Whistling (?), 11:28, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мне у некоторых софтсвитчей вот этот fail fast нравится Да пусть оно лучше сесс... текст свёрнут, показать
     
     
  • 13.677, Аноним (-), 20:56, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Софт свич несколько отличается от печатки с силовухой, допустим Одно дело по пр... текст свёрнут, показать
     
     
  • 14.680, Tron is Whistling (?), 22:17, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочу... текст свёрнут, показать
     
     
  • 15.687, Аноним (-), 22:14, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    По законам Мерфи - устройство порой сгорает первым, защитив предохранитель И ... большой текст свёрнут, показать
     
     
  • 16.688, Tron is Whistling (?), 22:16, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А ваш софт умеет думать, пока МК дымится вместе с платой ... текст свёрнут, показать
     
  • 16.689, Tron is Whistling (?), 22:32, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Почему Потому что по законам Мерфи первым сдохнут датчики для вашего софта ... текст свёрнут, показать
     
  • 10.358, Аноним (341), 17:59, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как я понял твои ответы - Если мы используем массив со статическим временем жиз... текст свёрнут, показать
     
     
  • 11.434, Аноним (-), 23:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И мы можем более адекватно эту идею проверить Частично даже в компилтайме, смот... большой текст свёрнут, показать
     
     
  • 12.462, Аноним (341), 01:39, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я почему шучу про много энергично говорим - потому что идеи assert ов для разм... текст свёрнут, показать
     
     
  • 13.651, Аноним (-), 19:38, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не то что немыслимые - а еще хуже чем динамическая аллокация Ибо еще менее de... большой текст свёрнут, показать
     
  • 7.166, n00by (ok), 06:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > От переполнения стэка ни один код не защищён.

    Дожили. А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.

     
     
  • 8.227, n00by (ok), 10:54, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для особо одарённых, кто судит по себе и считает это троллингом https learn m... текст свёрнут, показать
     
     
  • 9.509, freehck (ok), 12:30, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И по ссылке написано, дословно, под стэк выделено суммарно три страницы, так ст... текст свёрнут, показать
     
     
  • 10.534, n00by (ok), 15:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Надо перевести на понятный Стек крайне осторожно используется для хранения адре... текст свёрнут, показать
     
     
  • 11.536, freehck (ok), 15:27, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Боюсь, что это ты не понял Данная статья просто предостерегает разработчиков о ... текст свёрнут, показать
     
     
  • 12.550, n00by (ok), 16:10, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очевидно, это ты не понял смысл таких не подпускают Защита стека в Window... текст свёрнут, показать
     
     
  • 13.553, freehck (ok), 16:27, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ух едрить как же всё запущено Ну, с тем же успехом можно сказать, что код защищ... текст свёрнут, показать
     
     
  • 14.564, n00by (ok), 17:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я знаю, что некоторые умело подменяют тезис с целью превзойти собеседника Вот т... текст свёрнут, показать
     
  • 13.637, Аноним (637), 00:04, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Размер стека можно задать каким нужно, вызвав соответствующую функцию Это он по... текст свёрнут, показать
     
     
  • 14.641, n00by (ok), 14:58, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Формулировка некорректна Можно _попробовать_ задать размер KeExpandKernelStack... текст свёрнут, показать
     
  • 7.251, _kp (ok), 12:17, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > не защищён от исчерпания памяти.
    >> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.

    Хорошо, n=55666, но память процесса переполнена.
    Или переполнена иным, более естественным способом.

    Что сделает ПО безопасном языке? Да точно так же грохнется,толко некролог подробнее выдаст, но это не точно.

    Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области стека или его части, но не везде это делается очевидным и удобным способом.
    Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с частичным сохранением состояния.

     
     
  • 8.295, Аноним (-), 14:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я знаю что сделает нормальный системщик 1 Запретит такую конструкцию если без ... большой текст свёрнут, показать
     
  • 5.165, n00by (ok), 06:48, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А в чём проблема VLA? Лучше с alloca и указателями для того
    > же самого геморроиться и статическому анализатору палки в колёса ставить?

    Проблема в том, что это ядро. Вот скажи, какой там размер стека?


     

     ....большая нить свёрнута, показать (52)

  • 1.24, Аноним (173), 22:21, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну если хруст завозят, то и православные плюсики должны завезти.
     
     
  • 2.348, PnD (??), 17:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Немного не так.
    Зашкварился на rust? Всё, теперь c++ отказать — не по понятиям. (Далее, остальные в очередь.)
    </trollFace>
     
  • 2.398, warlock66613 (ok), 20:02, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже помойка будет какая-то.
     

  • 1.25, Bottle (?), 22:24, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Плюсы очень нужны в ядре, потому что поддержка модулей в Си даже не планируется, а хедеры очень сильно замедляют компиляцию.
     
     
  • 2.74, Аноним (75), 00:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Модули в рабочем состоянии пока что только в компиляторе от микрософта
     
     
  • 3.98, Аноним (98), 01:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В шланге давно в рабочем состоянии. И в CMake с недавнего времени. Но ядро Linux продолжает жрать makefile-кактус вместо CMake+Ninja.
     
     
  • 4.111, Аноним (115), 02:20, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    CMake сам по себе кактус. И у тебя вообще хватает инженерного интеллекта, чтобы догадаться, что система сборки, полностью заточенная под юзерспейс, для ядра не подходит?
     
     
  • 5.141, Аноним (140), 03:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сфигали не подходит для ядра, если для сборки под голые микроконтроллеры без разделения на юзерспейс и кернелспейс подходит?
     
     
  • 6.158, Аноним (115), 05:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если не подходит, то это же ещё не означает, что не найдутся упоротоые, которые будут готовить из буханки белого троллейбус. Ну и сравнил, конечно, гогнокод под голый контроллер с развесистым ядром.
     
     
  • 7.411, Аноним (-), 20:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но, но ведь троллейбус делается из буханки ржаного!
    В любом случае чистые make файлы это уже анахронизм (кроме некрофагов из ядра)))
     
  • 2.92, Аноним (-), 00:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    модули - проприетарный рак от майкрософт. хидеры ничего не замедляют, если мозгами хоть иногда пользоваться, что в случае майкрософт невозможно
     
     
  • 3.159, Аноним (115), 05:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда вам стоит для начала поработать с большими проектами
     
     
  • 4.172, Аноним (172), 07:41, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько большими? Сколько строк?
     
     
  • 5.303, Аноним (115), 14:31, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Настолько, что какой-нибудь sloccount не посчитает за разумное время
     
  • 4.250, Аноним (194), 12:06, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так вы не делайта свои "большие" проекты в одну портянку....
     
  • 3.287, Аноним (293), 13:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А модули в Python, D и ещё много где, тоже Microsoft ввела?
     
  • 2.299, Аноним (299), 14:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    header-only библиотеки конечно можно написать так, чтобы они замедляли компиляцию. но так обстоит дело с чем угодно почти. так что просто нужно писать грамотно и ничего замедлятся не будет.

    такая байка, что компиляция будет очень долгой из-за ho пошла еще со времен кода в духе александреску. ситуация уже давно изменилась а байка осталась.

     
     
  • 3.377, Аноним (375), 18:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это не байка. Ты на своей шкуре это сможешь заценить, подключив в программу CLI11.
     
  • 3.418, Bottle (?), 21:24, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это не байка. Погугли патчи ядра от Инго Молнара.
     

  • 1.33, Ivan7 (ok), 22:36, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Наконец-то С++! Архаика Си - это конечно круто, но технологии идут вперёд!
     
     
  • 2.183, Герман (??), 08:51, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Внедрение плюсов - такой себе шаг вперед
     
  • 2.537, Аноним (-), 15:29, 16/01/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.35, Аноним (35), 22:40, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пусть пихают и раст и зиг и сипипи сразу. И вейланд с системдой тоже сразу в ядро. Ресукликс-Биникс!
     
  • 1.37, Аноним (37), 22:44, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    И Carbon, и VLang - тоже !
     
     
  • 2.59, Аноним (58), 23:39, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Cabron.
     
     
  • 3.276, Аноним (293), 13:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Cartoon
     
  • 2.327, Котофалк (?), 15:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    а вот VLang мысль и в самом деле интересная. Но, но что там с архитектурами, отличными от x86?
     
     
  • 3.498, Аноним (499), 10:52, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Он вроде в С компилируется, значит считай поддерживает считай что все. В отличии кстати от очень ограниченного набора платформ у Rust.
     

  • 1.39, Аноним (37), 22:46, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не забывая про Zig и Seed   (ElenaLang -тоже неплохо )) )
     
     
  • 2.300, Sw00p aka Jerom (?), 14:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Marusya на подходе :)
     
     
  • 3.324, Аноним (293), 15:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сначала Алиса
     
     
  • 4.333, Sw00p aka Jerom (?), 15:46, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Сначала Алиса

    такими темпами не видать нам Katyusha :)

     
  • 2.409, Аноним (293), 20:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Seed это вот этот https://ru.wikipedia.org/wiki/Seed7 ?
     

  • 1.42, Аноним (42), 22:52, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Rust
    > C++

    Бедный Linux, как же упорно туда всякую гадость пихают...

     
     
  • 2.83, Аноним (115), 00:14, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Если плюсы таки завезут, то rust там быстро сдохнет
     
     
  • 3.184, Герман (??), 08:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Вместе с Си и ядром целиком
     
  • 3.604, Аноним (20), 04:35, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это тебе так кажется. Раст "пихают" не потому, что "фанаты", а потому, что на то есть объективные причины. Те самые причины, по которым пихают его, а не С++. Это не вопрос того, что кому больше нравится. Это вопрос сугубо технический. И раст чисто по техническим причинам оставляет С++ далеко позади.
     
     
  • 4.624, Аноним (623), 17:06, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, конечно, не потому что фанаты Давай посмотрим на объективные факты Основ... большой текст свёрнут, показать
     
     
  • 5.670, Илья (??), 18:40, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кресты это нехорошо. Одни и те же ошибки ошибки при завышенном чсв плюсовиков

    Не могу придумать никакой отрасли (кроме игр) где я бы согласился на плюсах проект начинать

     

  • 1.43, Анонимбус 2000 (?), 22:54, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Поддерживаю данное начинание!
     
  • 1.44, Антонимусс (?), 22:55, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это ядро уничтожит энтропия и тогда GNU Hurd всех победит. Осталось подождать ещё лет 10.
     
  • 1.45, Аноним (45), 22:57, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм, я от с/с++ отошел лет так 15 назад. Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Тогда как в чистом с можно было линковаться между разными компиляторами, потому что есть бинарная совместимость. Для расширений питона это вроде до сих пор актуально. Не будет ли из-за этого проблем с ядром? Гарантировать что все блобы в ядре и сторонние модули будут скомпилированы одним компилятором никто не может.
     
     
  • 2.48, Аноним (48), 23:03, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ведро беспокоит что-либо, кроме gcc?
     
  • 2.49, Аноним (-), 23:15, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А разве с СИ не так же?
    Пришлось делать гну-тые расширения, чтобы собирать ядро.
     
  • 2.57, Аноним (57), 23:33, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами.

    Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать не могут.

     
     
  • 3.374, Аноним (293), 18:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да чё там думать, пусть берут эту схему из g++. Кстати, кто-то как-то приводил документ из недр Мелкомягких, где они это и предлагали сделать на уровне языкового стандарта. Сейчас не могу найти ту ссылку.
     
  • 2.380, Аноним (293), 18:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем конкретному ядру бинарная совместимость? Эту версию ядра или другую можно полностью с модулями пересобрать другой версией компилятора. Стороннние модули тоже можно пересобрать нужной версией.
    Про какие блобы речь? Если загружаемые прошивки в девайсы, то пофиг, чем оно там для них собиралось. Оно с кодом ядра линковаться и не будет. Если блободрайверы, так это же хорошо. Мейнтейнеры ядра и так всеми силами борются с блободрайверами. Это им только в помощь. Пусть вендоры приучаются выпускать открытые драйвера.
     
     
  • 3.416, ТвойКопетанОчевидность (?), 21:05, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Например, какая-нибудь nvidia тебе поставляет драйвер готовым модулем
     

  • 1.46, 3draven (ok), 22:58, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Скоро ядро перепишет ИИ. В бинарных кодах сразу.
     
     
  • 2.50, Информатика (?), 23:18, 14/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Машинный код
     
  • 2.125, Вы забыли заполнить поле Name (?), 02:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть хотя бы драйвер напишет рабочий. А потом сможет в нем баг поправить.
     
  • 2.263, Аноним (263), 12:54, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ИИ пока что даже простой код генерировать не научился. Если не считать измусоленные факторилы с фибонначи. Куда ему до ядра?
     

  • 1.47, Аноним (-), 23:00, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –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-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com/

     
  • 1.53, Ilya Indigo (ok), 23:22, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Ну наконец-то об этом заговорили!
     
  • 1.64, cheburnator9000 (ok), 23:43, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    давно пора.
     
  • 1.65, anodymus (?), 23:44, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А я согласен на плюсы в ядре. Благодаря изменениям под встраиваемые системы там теперь можно исключения не использовать. И более строгая проверка типов чем в С. Плюс, выразительнее языковые конструкции можно делать.
    А Раст - это просто попытка корпорастов под себя "поляну" подмять. Они же, наверняка, весь это "хайп" вокруг языка и разводят за бабло. Чтобы потом одним прекрасным утром поставить специальный блоб (как пример) в зависимостях и никто никуда уже не слезет. И с упорностью осла лезут в проект в который их никто не звал, вместо того, чтобы свой делать и показать как надо. Инфоцыгане.

    У C++ хотя бы комитет стандартизации существует. Да, он тоже многими корпорастами спонсируется, но там тяжелее свою волю навязывать. Приходится уже договариваться.

     
     
  • 2.87, asaaddxasaadd (ok), 00:22, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А каких, собственно, корпорастов?
    Тех, которые GCC разрабатывают?
     
     
  • 3.88, Аноним (75), 00:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В гугле забанили?
     
  • 3.89, Аноним (75), 00:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://isocpp.org/std/the-committee
     
     
  • 4.181, Аноним (175), 08:06, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Одни белые лица и в основном мужики, никакого диверсити.
     
     
  • 5.414, Аноним (-), 20:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты лучше посмотри где они работают)
    Сплошные майкрософты, гуглы и прочие корпорации.
    Так что, "что они скажут - так и будет".
     
  • 2.123, Вы забыли заполнить поле Name (?), 02:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Плюс, выразительнее языковые конструкции можно делать.

    С другой стороны понаделают "выразительных конструкций", а потом разгребать. В большом проекте с большим кол-вом участников чем прямолинейнее конструкции, тем лучше имхо.

     
     
  • 3.237, yet another anonymous (?), 11:19, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот, ради интереса, поробуйте объяснить кому-нибудь (да хоть себе) как в Ядре списки и работа с ними сделаны. (это к "чем прямолинейнее конструкции, тем лучше").
     
     
  • 4.340, Аноним (194), 16:27, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    вы точно программист ?
     
  • 3.631, Аноним (631), 17:42, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тут надвое сказано... Что именно "разгребать"?? ООП для того и придумали, что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь.

    Другой вопрос, что с ЛЮБЫМ ООП языком придётся тянуть и его рантайм (который просто нельзя выкинуть). И как рантайм одного модуля "дружить" с остальными? (включая ядерный) Вот где засада. На одном хелловорлде рантайм прекрасно работает. Но в сложной модульной системе - большой вопрос.

     
     
  • 4.633, Вы забыли заполнить поле Name (?), 02:46, 18/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > ООП для того и придумали,
    > что сложность современных систем на порядки выше старых юниксовых пародий. Соотв.
    > без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь.

    А причем тут ООП? Хорошую декомпозицию и абстракцию можно сделать без него: lisp и erlang как пример.

     

  • 1.73, Аноним (-), 23:58, 14/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++

    скорее потому, что с++ - надстройка над с

    >  один из ключевых разработчиков ядра в компании Intel

    того самого intel, который патчи даже не компиляет перед отправкой?

     
     
  • 2.278, Аноним (278), 13:25, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > скорее потому, что с++ - надстройка над с

    Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих на "C с классами" у C++ плохая репутация.

     
     
  • 3.378, Аноним (375), 18:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте классы на GовноObject делать, так определённо лучше!
     
  • 3.456, InuYasha (??), 00:10, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    как раз наоборот - современный ++ выглядит порой как несто среднее между растом и brainfuck.
     
  • 3.491, Аноним (341), 10:02, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится... большой текст свёрнут, показать
     

  • 1.95, Аноним (95), 01:14, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Потом все равно на Carbon переписывать.
     
     
  • 2.116, Аноним (107), 02:30, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А вот кстати про Carbon почти никто не пишет, а он развивается просто бешеными темпами. Так что может быть и не шутка.
     
     
  • 3.122, Вы забыли заполнить поле Name (?), 02:46, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > почти никто не пишет, а он развивается просто бешеными темпами

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

     
     
  • 4.171, Аноним (175), 07:32, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И карго почти наверняка будет запрещено, а ведь это считай центральная фича языка.
     
     
  • 5.243, yet another anonymous (?), 11:27, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В методичке написано, что это не часть языка и вы можете жить и без него. Но: таки да, r... тащат в ядро, чтобы оно паровозиком для cargo послужило. Без cargo цели достигнуты не будут.
     
  • 5.440, Аноним (-), 23:39, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > а ведь это считай центральная фича языка.

    Агаблин, обеспечивает вендорлок на гугл, амазон и майкрософт.

     
  • 2.404, Аноним (293), 20:21, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Гугель говорил, что Carbon будет собирать и код писанный для C++.
     

  • 1.96, Аноним (96), 01:18, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите, это начало конца или второе рождение?
     
     
  • 2.103, bulbasalo (?), 01:44, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Время переходить на  NetBSD.
     
     
  • 3.280, Аноним (293), 13:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если и переходить на то семейство, то уж на Стрекозу.
     
  • 3.630, Аноним (631), 17:39, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Почему не QNX? Minix? Да даже BeOS была бы куда лучшей альтернативой!
     
  • 2.245, Аноним (245), 11:32, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это метастазы.
     
  • 2.629, Аноним (631), 17:38, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это конвульсии трупа :) Фактически уже понятно - как только "добрый диктатор" сдохнет, начнётся полный коллапс (не по этой причине, а тупо из-за бестолкового, монолитного, плохо спроектированного ведра). И на каком языке писать ведро вопрос уже стоять даже не будет.
     

  • 1.108, Аноним (105), 02:10, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Я за ядро на Java. Заколебали уже. Там тоже синтаксис  аналогичный. И вообще все есть интернет. У них вон 8-я версия много лет в продакшене и жабомашина может запускать разные версии когда надо. Чего к плюсам привязались?
    Солянка - так солянка.
     
     
  • 2.265, aaaaa (?), 12:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    с gc что будем делать?
     
  • 2.281, Аноним (293), 13:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А JVM под чем крутить?
     
     
  • 3.308, Аноним (115), 14:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Под lisp-машиной
     
     
  • 4.388, Аноним (293), 19:10, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А Lisp-машину на чём? Гусары, молчать!
     
     
  • 5.417, Аноним (115), 21:06, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так она уже машина. Или не знаешь что это такое? Тогда википедия в помощь
     
     
  • 6.593, Аноним (589), 23:31, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пока это только умозрительная машина.

    Которую можно вертеть только на ...

     
  • 2.330, Котофалк (?), 15:39, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Я за ядро на Java.

    Только на java-процессоре.

     
     
  • 3.384, Аноним (293), 19:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А Lisp-машину на чём? Гусары, молчать!
     
     
  • 4.515, Советский инженер (ok), 13:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    на эмуляторе поверх явапроцессора
     

  • 1.113, Аноним (113), 02:20, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Пока линуксом управляет один единственный до*боеб, способный забаррикадироваться в своих 80-ых, и единолично принимающий судьбоносные решения, вашему красноглазому сообществу никакой прогресс не грозит.
    Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.
     
     
  • 2.117, Аноним (107), 02:32, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть на примере Мозиллы.
     
     
  • 3.652, Аноним (-), 19:59, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть
    > на примере Мозиллы.

    Есть пример лучще - Fuchsia и ее "вот, мы, ща, на десктопы, столица миоа - в нью-васюки!". Вон там в соседней новости, где гранд-план по захвату мира кажется немного обломался.

     
  • 2.120, Аноним (120), 02:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.

    Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, только если прогресс в принятии ректальных зондов в виде ИИ.
    Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.

     
     
  • 3.372, Аноним (-), 18:44, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не
    > грозит, только если прогресс в принятии ректальных зондов в виде ИИ.

    Вас услышали! В новом нотпаде уже встроено. Он теперь поди по сети отсылает каждое нажатие клавиши с 100% легитимной отмазкой :). Вы же не могли жить без AI в нотпаде, правда?! :)

    > Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.

    Вон вам чудный новый нотпад от майкрософта. Зато глаза правильного цвета, и стыд их видимо не ест :)

     
  • 2.121, Вы забыли заполнить поле Name (?), 02:43, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотри вот это видео https://www.youtube.com/watch?v=YyRVOGxRKLg Торвальдс говорит за внедрения раста как раз из-за этого. Но лично он ему не нравится.
     
  • 2.136, Аноним (105), 03:12, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Че ты несешь? Совет директоров даже если и принимает решения, то не о каждом элементе и в каждой крупной конторе есть жесткая иерархия. Это типо император мать их японии, а это простолюдин. Простолюдин императору нихрена указывать не может потому что лидер может быть только один.
    Вам дают кость из раста которую разумно можно использовать ради фич типа написания драйверов без ошибок в памяти.
    То что есть извращенцы которым так проще -хрен с ними.
    Но каждый червь со своими советами лезущий это не принятие важных решений.
    То что ты неспособен осилить хоть что-то не значит что кто-то есть твой не так чтобы зашифрованный мат. Черви ничего Линусу не докажут.
     
  • 2.152, Аноним (115), 05:05, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Линус понимает как нужно вести такой проект, а ты нет. Сейчас практически весь серверный рынок линуксовый, все другие ~юниксы давно на обочине.
     
     
  • 3.611, Школьник (ok), 09:18, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что корпорации в эпоху Интернета быстро поняли, куда дует ветер, и решили скинуться человекочасами на разработку того, что само по себе уже не могло давать конкурентных преимуществ. Это и есть главная причина того, что Линукс взлетел. И уж точно не технологическое превосходство - до первой половины нулевых в бзде лучше было сделано почти всё, а про то, насколько лучше в это же время был солярис, даже и говорить особо не надо.
     
  • 2.157, Аноним (75), 05:22, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Один процент на десктопах, а не на серверах. И проблема не в ядре
     
  • 2.187, Аноним (187), 09:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других. Ничего нового.
     
  • 2.264, Аноним (264), 12:54, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Форкни ядро и веди его в какое хочешь будущее.
     

  • 1.119, Вы забыли заполнить поле Name (?), 02:42, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Останавитесь!
     
  • 1.128, Вы забыли заполнить поле Name (?), 02:57, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

    Round 2... Fight!

    Как бы в отчасти правда, но и ложь тоже. Пустив С++ в ядро им надо будет рядом гайдлайнов накатать какие фичи использовать, а какие нет. Хотя вон гугл в хромиуме вроде смог. Но оно вам надо?

     
     
  • 2.153, Аноним (115), 05:07, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гайдлайны, внезапно, в ядре и для Си есть. Уровень обсуждений далёких от разработки людей.
     
     
  • 3.306, Вы забыли заполнить поле Name (?), 14:36, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для с++ они увеличатся на порядок из-за возможных фич языка
     
     
  • 4.328, Аноним (293), 15:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пусть определятся, какие фичи в ядре допустимы. По тем и пишут.
     
  • 4.356, Аноним (115), 17:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек
     
     
  • 5.425, Вы забыли заполнить поле Name (?), 22:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вот дока по стилю С в ядре https www kernel org doc html v4 10 process coding-... большой текст свёрнут, показать
     
     
  • 6.436, Аноним (341), 23:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Вот дока по стилю С в ядре

    "Табы это 8 пробелов..."

    > Вот для примера С++

    "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам библиотеку."

    > Qt

    *Что-то не тянущее на 21 страницу*

     
     
  • 7.443, Вы забыли заполнить поле Name (?), 23:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Вот дока по стилю С в ядре
    > "Табы это 8 пробелов..."
    >> Вот для примера С++
    > "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам
    > библиотеку."

    Мой оригинальный комментарий https://www.opennet.me/openforum/vsluhforumID3/132575.html#128 содержит слово guideline. Если https://www.kernel.org/doc/html/v4.10/process/coding-style.html мешает понятия code style и guideline, то я не виноват. Для примера гугл также делает. Смотри тогда с ним.

    Но я говорил именно про гайдлайн и для плюсов там сильно больше надо будет писать. Хотя бы имея ввиду сколько всего добавляется в новых стандартах. Для примера можешь посмотреть доку хромиумуа по ссылке выше.  


     
  • 6.437, Аноним (115), 23:32, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь Дока в я... большой текст свёрнут, показать
     
     
  • 7.438, Аноним (115), 23:33, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ^  Так и не понял куда приклеился ответ, он был анониму с ссылками
     
  • 7.441, Вы забыли заполнить поле Name (?), 23:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн ... большой текст свёрнут, показать
     
     
  • 8.466, Аноним (115), 02:03, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет гайдлайна, раньше туда тупых не брали Сейчас пытаешься приклеить документац... большой текст свёрнут, показать
     
     
  • 9.472, Вы забыли заполнить поле Name (?), 02:32, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Просто в конторе не любят писать доку - признай это Поэтому кичиться cs на 1 ст... большой текст свёрнут, показать
     
  • 9.473, Вы забыли заполнить поле Name (?), 02:41, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в гугл берут тупых по твоей логике раз у них есть гайдлайн Чтож тогда яндексо... текст свёрнут, показать
     
     
  • 10.653, Аноним (-), 20:02, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут... текст свёрнут, показать
     
  • 7.448, Вы забыли заполнить поле Name (?), 00:00, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально.

    Оригинально я писал про гайдлайн, а не cs. Если ядро смешивает их, то ко мне какие вопросы. Вон гугл тоже смешивает, сравнивай с ним.

    > И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине.

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

     
     
  • 8.468, Аноним (115), 02:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c в нём А зн... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (16)

  • 1.134, Аноним (-), 03:04, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    AUTOBOT - это блочит (и я не знаю почему):
    А как они собираются исключения туда затянуть? (этого сделать вероятно не получится, да и не нужно)
    А без исключений затянут - это будет не C++, а просто "подмножество" C++ - типа "чуть улучшенный C".
    Ах да - это они всё ради темплэйтов наверное!

    P.S. А в Расте есть исключения?

     
     
  • 2.154, Аноним (115), 05:08, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Разумеется, ведь самая главная фича плюсов это исключение
     
  • 2.207, Пряник (?), 10:11, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пока нашёл там обработку ошибок. То есть функция может вернуть либо результать, либо ошибку. И ошибка при этом вполне себе конретный тип данных, с которым можно дальше работать, например, завершив программу с сообщением или продолжить дальше работать, решив проблему.
     

  • 1.147, Аноним (147), 03:41, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра

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

     
  • 1.148, bOOster (ok), 03:48, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Здравый смысл, наконец-то берет верх..
     
  • 1.161, Аноним (96), 05:49, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Да уж, беда пришла откуда не ждали... Если что-то и может быть хуже С, то это С++.
     
     
  • 2.176, Аноним (172), 07:46, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поправил, не благодари

    > Да уж, помощь пришла откуда не ждали... Если что-то и может быть лучше С, то это С++.

     

  • 1.168, n00by (ok), 07:07, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Единственная проблема плюсов в ядре -- это привычки и отношение к языку значительной части сишников. И вопрос тут не в том, кто прав, а кто нет. Люди годами писали ядро, потому их точка зрения имеет вес. Однако, после внедрения Rust этот аргумент превратился в тыкву.
     
     
  • 2.370, ДаНуНафиг (?), 18:36, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То, что будет возможность писать на плюсах совсем не означает, что толпы молодёжи (уже смешно) побегут яростно переписывать все ядро. Так что как пилили деды свою сишную часть, так и будут, пока (если) не будет вытеснена чем-то более актуальным.
     
     
  • 3.379, Аноним (379), 18:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Толпам молодёжи (и немоложёжи) вообще срать на ядро, они от него в принципе с удовольствием подальше держаться будут. Но не всегда есть такая опция. Драйвер сам не напишется... Нужен нормальный плюсовый фреймворк для драйверов.
     
     
  • 4.545, n00by (ok), 15:47, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Под фреймворком обычно понимается что-то тяжёлое. На плюсах возможно реализовать библиотеку без лишних накладных расходов.
     
  • 3.543, n00by (ok), 15:43, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На деле, плюсы в ядре повышают порог вхождения по сравнению с Си.
     
  • 3.638, Гультай (?), 09:03, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Лол, молодёжь на javascript пишет, ей что сишечка что плюсы это древние рукописи
     

  • 1.178, freehck (ok), 07:51, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat

    Это что, реклама Red Hat между делом? Данному разговору уже не первое десятилетие.

    > С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin)

    Сомневаюсь, что люди со стороны могут по предоставленному послужному списку оценить реальную авторитетность мнения данного разработчика. Напишите лучше новость, если Линус или Грег удостоят его мнение ответом.

    > Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++

    А актуален ли вопрос вообще? Недавно читал, что ядро нынче нормально собирается Clang-ом.

     
     
  • 2.402, ИмяХ (ok), 20:08, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>ядро нынче нормально собирается Clang-ом.

    Это как раз именно потому, что в нём нет С++

     

  • 1.182, Аноним (182), 08:32, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. Чтобы не было никакого неявного тормозного кода - лучше юзать char*. Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Они и PHP его бы на писали, если бы можно было.
     
     
  • 2.185, Аноним (36), 08:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке.

    Можно, но костыльно очень. Или хотите в ядро нечто, наподобие Glib?

    >На структурах и прописывая весь скрытый в ООП код ручками.

    Это человеконечитаемо, лапшакод. И зачем для каждого "класса" проделывать ручками одни и те же действия?

     
  • 2.220, n00by (ok), 10:46, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ядро писали на Си, потому что плюсов тогда толком и не было.
     
     
  • 3.329, Аноним (293), 15:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну были, конечно, уровня Borland C++. А вот был ли свободный g++ в 1991, не знаю.
     
     
  • 4.412, 22 (?), 20:45, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Был где-то с 87-го: https://gcc.gnu.org/releases.html
     
  • 4.547, n00by (ok), 15:56, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Гипотетически они может и были, а практически стандарт языка принят в 98-м.
     
  • 2.268, freehck (ok), 12:57, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Никакого -- утверждение слишком сильное для сишки Как минимум из-за неявного пр... большой текст свёрнут, показать
     
     
  • 3.444, fuggy (ok), 23:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Rust тоже не ООП язык. Вполне себе можно писать крупные проекты и в процедурном стиле, и в ООП, и в функциональном стиле. ООП переоценён, это не золотой молоток. А уж взглянув на Java Enterprise FizzBuzz страшно смотреть.
     
     
  • 4.470, Аноним (115), 02:27, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в самом деле не киллер фича, но на задачах, где оно нужно, без поддержки ООП тяжко
     
     
  • 5.478, Вы забыли заполнить поле Name (?), 02:58, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в
    > самом деле не киллер фича, но на задачах, где оно нужно,
    > без поддержки ООП тяжко

    В каких задачах нужно ООП?

     
     
  • 6.497, Аноним (499), 10:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.
     
     
  • 7.511, freehck (ok), 13:05, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями.
    > Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.

    На самом деле ООП там нужен только потому, что ООП является отдельной индустрией-в-себе: это своя особая экосистема, свой собственный мир, у него свои разработчики, свои проблемы и своя головная боль. По существу, он нужен только там, где разработка уже в этой экосистеме живёт. Поскольку в высокоуровневых языках объекты первого порядка давно являются само собой разумеющимися вещами, то кроме выше названной социальной -- потребности в ООП-е как таковой нет: код на фанкторах пишется и понимается куда проще.

     
     
  • 8.594, Аноним (589), 23:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если объекты в плане понятий из предметной области однотипные Любая, даже мин... текст свёрнут, показать
     
     
  • 9.694, freehck (ok), 14:05, 25/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что ближе к корове, трава или курица Аналитик ответит, что курица, потому что и... текст свёрнут, показать
     
  • 2.332, Аноним (115), 15:43, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    c++ это не либа работы со строками. Причины совершенно в ином - нет API и нет гарантий на оптимизации сахара. Тем более если ещё брать c++ образца начала 2000, то вообще ужасный ЯП с минимум оптимизаций сахара компилятором.
     

  • 1.186, awoland (ok), 08:59, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это у Red Hat всё шуточки первоапрельские, а между тем Эпол, например, вполне успешно и уже давно применяет Embedded С++ для написания системных Kernel extensions (драйверов) в ядре XNU для всей линейки своих OS (macOS, iOS, iPadOS & e.t.c.) ...
     
     
  • 2.196, Noname (??), 09:50, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У эппла анально-ректальные стайлгайды и референсы. Во-вторых, эпплы сами выпускают железо и сами пишут под него. В отличии от линпус-зоопарка, у них чёткий список устройств, которые должны работать с теми или иными компонентами.
     
     
  • 3.210, beck (??), 10:23, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Винда написана на С++ и работает на огромном зоопарке устройств.
     
     
  • 4.218, Аноним (214), 10:44, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось изначально. Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.
     
     
  • 5.221, Аноним (214), 10:46, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые блобы с кучей костылей чтобы хоть как-то работало. В линуксе на помойные драйвера смотрят криво.
     
  • 5.225, beck (??), 10:51, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какие полтора типа? Минимум шесть.


    > её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать

    Windows не виновата в том, что у тебя лапки.

     
     
  • 6.232, Аноним (214), 11:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Минимум шесть.

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

    >Windows не виновата в том, что у тебя лапки.

    Ну, тут виноваты windows update и неквалифицированные некомпетентные кадры в microsoft, не сама windows, понятное дело.

     
  • 5.485, Аноним (482), 06:52, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.

    Выкинь уже свой зион с али, с «ECC»-памятью.

     
     
  • 6.488, Аноним (214), 09:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Твои фантазии унылые, фиксация какая-то?
     
  • 3.307, awoland (ok), 14:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, стайлгайды и референсы не имеют никакого отношения к технологиям программирования. Это чистая политика компании.
    Во-вторых, пример успешного написания кучи драйверов энтузиастами-хакинтошниками для железа, которого никогда отродясь не было в железе Эппле чётко доказывает, что и второй ваш довод является примером газификации луж...
     
     
  • 4.349, Noname (??), 17:03, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > хакинтошниками

    И ты ещё что-то там про газификацию луж пишешь? Лол.

     

  • 1.188, poulch (??), 09:09, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообще вопрос надо ставить глобально. Зачем ограничения на язык для разработки модулей ядра? Далеко не всякие модули включаются в состав поставки ядра. Если так хочется, то пусть ядро и комплектные модули  будут на С, но сторонние разработчики должны иметь возможность писать на любых языках. Я 20 лет страдал как единственный разработчик на фирме. Либы для разных платформ на С++ с общим кодом практически, а с драйверами вечная боль С++ под вин и С под  линукс. причем лет 15 назад были патчи на ядро которые финские студенты написали емнип которые давали возможность собирать ядро с++ компилятором...
     
     
  • 2.205, Аноним (205), 10:09, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Та же мысль. В Сишный интерфейс функций умеют почти все языки, пусть ядро остается на Си, а модули пишут кто на чем хочет.
     
     
  • 3.246, Советский инженер (ok), 11:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    собственно, а кто запрещает?
     
  • 2.459, Аноним (459), 00:16, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда как собирать всю эту мозаику? У инструментов будут свои зависимости, а у тех еще зависимости... А так-то я сам не против.
     

  • 1.191, Аноним (191), 09:23, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –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!

     
     
  • 2.229, Аноним (459), 10:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C++ и почему Раст для них не подходит.
     
     
  • 3.284, Аноним (293), 13:34, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    "Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра"
     
  • 2.595, Аноним (589), 23:48, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > какой-нибудь С++50, который наконец-таки превратится в Rust

    Ты думаешь, что в C++50 порежут все что можно по самые помидоры?

    Так что останется одна заготовка языка?

     

  • 1.192, d_kazbek (?), 09:40, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    давно пора
     
  • 1.193, Noname (??), 09:43, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Руст действительно будет интереснее, а кресты уже показали несостоятельность за годы существования. Когда-то думал, что взлетит D-шка, но увы.
     
     
  • 2.233, Аноним (459), 11:01, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Интереснее побаловатся на раз, а так С++ зрелый язык промышленной разработки и продожает активно использоватся, особенно в коммерческой разработке.
     
  • 2.628, Аноним (631), 17:27, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А чем D не взлетел?! Что в этом языке такого плохого, что его нельзя использовать для ведра?
     

  • 1.203, Tron is Whistling (?), 10:07, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вообще плюсы в ядре - здраво, но с оговорками.
    Исключения придётся вымести, по понятным причинам.
    STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора.
    С другой стороны, отсутствие STL кстати как раз отпугнёт целую массу тех, кто в не-плюсовый C не осилил.
     
     
  • 2.239, ay8910 (?), 11:22, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какие ещё целые массы тех, кто в не-плюсовый C не осилил - как они вообще окозались в разработчиках ядра-Линукс ???
     
     
  • 3.271, Аноним (253), 12:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Человек не понимает, что ядро пишется корпорациями на деньги корпораций. Им и решать, какой язычок использовать, а какой - нет.
     
  • 3.320, Tron is Whistling (?), 15:12, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Цель как раз в том, чтобы они в них и не оказались :)
     
  • 3.407, Аноним (293), 20:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сходи к попам, посмотри на их кресты. Пойми, чем плюс отличается от креста.
     
  • 2.274, Аноним (293), 13:19, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает. Например, Vector и Array - большая польза. Хотя бы, чтобы за пределы буфера не выходить.
     
  • 2.285, Аноним (278), 13:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора.

    Во всех контейнерах STL можно передавать собственные аллокаторы. Можно хоть для каждого аллокатора сделать свой набор классов, и это будет намного чище и безопасней дёрганий кошмарных malloc'ов и бесконечной ручной проверкой высвобождения всех сырых указателей.

    STL это вообще по большей части набор шаблонизированного кода, странно это не знать.

     
     
  • 3.319, Tron is Whistling (?), 15:11, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Соглашусь только за C++20. Хотя да, в принципе о нём и речь.
     
  • 2.334, Аноним (115), 15:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вместо STL будет своя либа с примитивами в c++ стиле. STL для ядерных целей не подходит
     

  • 1.208, Пряник (?), 10:16, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код

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

     
     
  • 2.222, banonymous (?), 10:47, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Как раз неосиляторы и впариают новые языки. Писать на них они тоже не умеют, но в резюме такие детали можно упустить.
     
     
  • 3.256, Аноним (253), 12:42, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Впарили раст в ядро - корпорации, их ядро, а не неосиляторы. У корпораций нет интересов писать на сишке, потому что им, по их причинам нужен раст. А обычные любители будь-то сишки или раста ничего не решают.
     
     
  • 4.457, Аноним (459), 00:11, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то по вакансиям не сильно этого заметно.
     
     
  • 5.493, Аноним (253), 10:13, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какие такие вакансии? Ты о чём? Речь про ведро, корпорациям-хозяйкам ведра не нужны никакие вакансии, разрабы уже есть у них.
     
  • 2.282, Аноним (278), 13:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > синтаксис С++ будет в разы хуже
    > к сожалению, ядро пилит кучка ретроградов-неосиляторов

    И кто же это тут несолилятор, лол.

     

  • 1.212, beck (??), 10:24, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ядро windows написано на С++.

    Вопрос об использовании С++ давно закрыт. Это работает.

     
     
  • 2.215, Пряник (?), 10:29, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но даже windows переходит на Rust.
     
     
  • 3.230, beck (??), 10:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В винде архитектура гибридная. Они могут позволить себе какие-то независимые части сделать на более других языках. Поэтому и С, и С++ и С#. И вот даже Rust.

    С линуксом и его монолитной архитектурою...

     
     
  • 4.339, Аноним (115), 16:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пиши драйвера в пр-ве пользователя на чём угодно
     
  • 3.234, Аноним (459), 11:08, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не переходят, а пишут отдельные модули. Там же не идиоты переписывать работающий код в которй инвестированы миллионы.
     
  • 2.228, Аноним (41), 10:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > windows
    > работает

    Ну, работать та работает. Но вот как работает...

     
     
  • 3.231, beck (??), 11:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нормально работает. Десятки миллионов серверов и сотни миллионов десктопов по всему миру.

    Не говоря уже про например медицинскую технику, управлялки станками и прочие кошерные вещи.

     
     
  • 4.266, Аноним (253), 12:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    по-дефолту в плюсах нет инструментов для безопасной работы с памятью. RAII и smart поойнтерс - это совсем недавно любители плюсов нашкрябали, плюсы - сплошной ансейф. УРА товарщи!
     
     
  • 5.364, Аноним (115), 18:26, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > RAII ... was developed for exception-safe resource management in C++ during 1984–89

    Очнись, наркоша. Смарт поинтеры в плюсовых проектах уже более 30 лет в том или ином виде, до стандартного STLя доехали лет 13 назад.

     
     
  • 6.494, Аноним (253), 10:17, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ты и оболтус. Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто не пользует. Твои плюсеги - сплошной ансейф, а когда находятся cve в плюсовых опенсорсах - разрабы отвечают: ну я забыл заюзать эту фичу. Ахахаха, плюсовеки, такие плюсоеки.
     
  • 2.261, Аноним (264), 12:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если так хорошо работает, почему везде линукс? Фактически сиплюсы используются только для игр. Винды - ось для запуска игр.
     
     
  • 3.288, beck (??), 13:43, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/

    Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда.

    Смартфон соединить с ноутом? Производители делают только для винды. Нормальный офис? Винда. Нориальный почтовый клиент с календарями, встречами и прочими плюшками? Опять винда.
    Управление зоопарком десктопов? Винда. Удалённый доступ с аппаратными ключами? Винда.

    99% промышленных софтов, на которых работать можно, опять винда.

     
     
  • 4.312, Вы забыли заполнить поле Name (?), 14:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не хочется тебя расстраивать, но это не от того, что винда хорошо работает. Это бизнес, ничего личного.
     
     
  • 5.336, Аноним (-), 15:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду?
    2 самых распространенных DE копируют решения из МАС оси и винды.

    Или ты хочешь, чтобы бедный врач пердолился с гентой или другими маргинальными дистрами?
    Искал дрова к специфическому оборудованию типа ЭЭГ/ЭКГ?

    В цивилизованных странах будет еще какая-то платформа для командной работы.
    Назови какое-то нормальное опенсорс решение (без шуток было бы интересно)

     
     
  • 6.344, Tron is Whistling (?), 16:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Путаешь интерфейс и подложку.
    На подложке в этих же аппаратах - далеко не винда.
     
     
  • 7.350, Аноним (-), 17:18, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, но например банкоматы я встречал на винде.
    Винда IoT Core вполне достаточно большому кол-ву медицинской техники.
    Я уже молчу про Windows CE)

    Хотя объективно для серьезного аппарата (типа радиотерапия или КТ) я бы постремался использовать ядро линукс.
    Уж лучше пусть будет какой-нибудь РТОС.

     
     
  • 8.365, Tron is Whistling (?), 18:27, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Банкомат - слишком примитивное устройство Дисплей, кейпад, принтер и полтора ко... текст свёрнут, показать
     
     
  • 9.366, Tron is Whistling (?), 18:28, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В самом аппарате, который деньги выдаёт, контроллеры бывают разные, но они автон... текст свёрнут, показать
     
  • 9.654, Аноним (-), 20:07, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У одной фирмы я видал там характерную лужайку с кнопкой Start Или, не менее паф... текст свёрнут, показать
     
  • 5.353, Аноним (353), 17:37, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за минимальную стоимость, ничего личного. Будет это линукс, винда, или ещё что-то - бизнесу неважно. А построением мирового open-source коммунизма пусть занимается кто-то другой.
     
  • 4.342, Tron is Whistling (?), 16:32, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё очень просто.
    На интерфейсе для врача - винда. В МРТ, на рентгене, в аппарате УЗИ.
    А вот внутри аппарата - либо линуха, либо RTOS'ы.
     
     
  • 5.427, beck (??), 22:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Внутри аппаратов чистое железо с прошивкаме. Накой там ОС?
     
     
  • 6.430, Tron is Whistling (?), 23:04, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Прошивки прямо в металле? :D
    Вы недооцениваете современные прошивки.
     
  • 4.343, Tron is Whistling (?), 16:33, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То есть винда тебе только картинку рисует, всеми же серьёзными задачами занимаются совершенно другие ОС.
     
     
  • 5.435, Аноним (482), 23:22, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Совершенно другие ОС даже не в состоянии нарисовать картинку, ОК.
     
     
  • 6.501, Tron is Whistling (?), 11:25, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там программеры другие, они занимаются не рисованием картинок, а работой со сложным железом.
     
     
  • 7.507, Советский инженер (ok), 12:15, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ви таки недооцениваете сложность рисования картинок по данным, полученным от сожного железа.
     
     
  • 8.516, Tron is Whistling (?), 13:48, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Картинки рисовать - тоже сложно, не спорю, но это больше математика Ну и плюс в... текст свёрнут, показать
     
  • 8.518, Tron is Whistling (?), 13:49, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Короче есть разница тупо на CPU процессить данные или работать с кучей датчиков... текст свёрнут, показать
     
  • 4.392, Аноним (293), 19:17, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда.

    Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки? А то и ваще б/у.

     
     
  • 5.484, Аноним (482), 06:47, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Закупаем такие современное оборудование (с условием, что нам его кто-то продаст)… а там опять винда. Да что ж такое.
     
  • 2.354, Аноним (115), 17:39, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ядро винды написано на Си
     
  • 2.529, хрю (?), 14:53, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ядро windows написано на С++.

    Откуда вы эту муйню все копируете? Ядро винды написано и продолжает писаться на C. Так же там есть asm и якобы его там достаточно много. Никакого С++ и чего-то ещё там нет и скорее всего не будет. Винду далеко не идиоты пишут.

     
     
  • 3.596, Аноним (589), 23:57, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно интервью в котором мелкомагкие переписывальщики на раст говорят о том, что занимаются переводом внутренних C++ типов в эквивалентные раст.
     

     ....большая нить свёрнута, показать (33)

  • 1.242, Вирт (?), 11:26, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > и язык C++ стал лучше

    Вроде же не 1 апреля еще? Автор цитаты выше Перепил на новый год и думает что наступило 1 апреля?

    Основное возражение для С++ в ядре было, что он слишком много прячет от разработчика, а для ядра это неприемлимо. И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу.

    Как, как язык поддерживающий обратную совместимость может стать лучше? Или пометили как устаревшие std::auto_ptr и std::vector<bool> и все, все проблемы решены?

     
     
  • 2.286, Аноним (278), 13:41, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу.

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

     
     
  • 3.314, Вы забыли заполнить поле Name (?), 15:00, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > начинают беситься от ошибок компилятора

    А кто не начнёт, когда в шаблонном коде  получаешь ошибку в коде кишок?

     
  • 3.454, Аноним (-), 00:09, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Все способы выстрелить себе в ногу в C++ - это исключительно наследие
    > C. На чистом плюсовом коде (без сырых указателей, сишных строк и
    > функций) выстрелить себе в ногу очень сложно.

    А дебильные классические типы целых чисел там как? Их так то и в си неплохо бы выпилить к хренам и сделать по уму, на основе C99 - и с "well defined behavior". Это спасло бы от дохреналиона багов и вулнов на ровном месте.

    И да - вообще забанить к хренам "int" (signed) как индексы. С расстрелом из реактивного г@вномета за это. Чтобы господам даже чисто теоритически в голову не приходило что в массив можно отрицательный индекс, бдаж!

     
     
  • 4.502, Tron is Whistling (?), 11:26, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не поверишь, но отрицательный индекс в массиве по указателю - очень даже востребован.
     
     
  • 5.512, Fyjy (?), 13:41, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В производстве овно кода и CVEшек?
    Верю! Можно просто открывать новости пенька и каждый 2 недели читать про очередную уязвимость от любителей поиграться с индексами.
    Но вот для надежных систем это только во вред.
     
     
  • 6.519, Tron is Whistling (?), 13:51, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер на какой-то указатель в этом индексе.
    Мне надо предыдущий взять. Далее чего?
     
     
  • 7.527, Аноним (115), 14:45, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так твой пример сам по себе небезопрасный. И на этот случай есть унарный --, знак тут всё ещё не нужен
     
     
  • 8.577, Tron is Whistling (?), 20:00, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мне не нужно менять сам указатель ... текст свёрнут, показать
     
  • 7.656, Аноним (-), 20:15, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер
    > на какой-то указатель в этом индексе.
    > Мне надо предыдущий взять. Далее чего?

    Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме?

     
     
  • 8.658, Tron is Whistling (?), 21:41, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да не, я не против, чтобы ты вместо одного сервера у меня 10 купил, но ты ведь н... текст свёрнут, показать
     
     
  • 9.665, Аноним (-), 12:44, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я как махровый сишник готов поспорить что все то же самое можно было сделать зна... текст свёрнут, показать
     
     
  • 10.666, Tron is Whistling (?), 13:04, 20/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На самом деле пусть уходят - чище будет ... текст свёрнут, показать
     
     
  • 11.678, Аноним (-), 21:09, 21/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Инихрена себе уровень самокритики Вот это вы круты Я правильно понимаю что вы ... текст свёрнут, показать
     
  • 5.655, Аноним (655), 20:12, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты не поверишь, но отрицательный индекс в массиве по указателю - очень
    > даже востребован.

    А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали. Я все понимаю - но вот в именно таком стиле CVE получаются. Воон там зубр сабмитил отрицательный индекс массиву если вооон те параметры на вход дать. Не, так не задумано - просто он аргументы функции на вход не чекал, и получив воооон те параметры, лихо проматывал индекс не только до 0 но и за него. Ну, подумаешь, по чужой памяти пошарился, а то и в провод слил, "ишь ты, карманный вариант heartbleed'а". Гнать таких програмеров ссаными тряпками и ср@ной метлой.

     
  • 4.514, Fyjy (?), 13:44, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > сделать по уму, на основе C99 - и с "well defined behavior".

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

     

  • 1.247, nc (ok), 11:47, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование на шаблонах) попадет в ядро то туши свет. Rust хоть и имеет более непривычный синтаксис чем С++, но все же разработан с учетом опыта многих других языков.
     
     
  • 2.254, Аноним (253), 12:39, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, только раст спасёт ведро линукс!
     
     
  • 3.262, nc (ok), 12:53, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да дело не в том что кто-то чего-то спасет Языки программирования объективно ра... большой текст свёрнут, показать
     
     
  • 4.294, Серб (ok), 13:57, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла.

    А опция --std компилятору не подойдет? :)

     
     
  • 5.331, nc (ok), 15:40, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не подойдет. Кроме того, хранение версии языка отдельно от исходника само по себе плохо.
     
     
  • 6.337, Аноним (115), 15:56, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это само по себе хорошо т.к. не нужно править дохринилиард прагм во всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать каждый исходник версией, просто невозможно придуамать.
     
     
  • 7.561, _oleg_ (ok), 16:56, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Это само по себе хорошо т.к. не нужно править дохринилиард прагм во
    > всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать
    > каждый исходник версией, просто невозможно придуамать.

    Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты туда _уже_ пойдёшь редактором. И поменять при этом pragma - не проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно и логично.

     
     
  • 8.563, Серб (ok), 17:14, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно и логично - когда не надо менять код под каждый новый стандарт Любая ... текст свёрнут, показать
     
     
  • 9.568, _oleg_ (ok), 18:06, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем его менять, если как предлагается выше, компиляторы поддерживают разные ... текст свёрнут, показать
     
     
  • 10.571, Серб (ok), 18:18, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Например, что бы оптимизации сработали Смотри lto ... текст свёрнут, показать
     
     
  • 11.572, _oleg_ (ok), 18:51, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если pragma version относится только к синтаксической части, то оптимизации здес... текст свёрнут, показать
     
     
  • 12.617, Серб (ok), 12:46, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Стандарты очень часто вводят для включения возможности оптимизации На старых ст... текст свёрнут, показать
     
     
  • 13.618, _oleg_ (ok), 13:20, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Оптимизации - расплывчатое понятие Что я вижу в новых стандартах C и C это не... текст свёрнут, показать
     
     
  • 14.619, Серб (ok), 13:43, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На изменение обработки volatile смотрел ... текст свёрнут, показать
     
  • 14.620, Серб (ok), 13:48, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На расширение того, что при constexpr уйдет в компиле тайм смотрел ... текст свёрнут, показать
     
  • 6.346, Серб (ok), 16:49, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не
    > подойдет.

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

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

    Чем? Вносимые в язык изменения продуманы так, что если что-то работает - то будет работать. Если что-то не работает - то оно не соберётся и ты вынужден будешь внести изменения.

     
  • 4.338, Аноним (115), 15:58, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.

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

     
  • 2.335, Аноним (115), 15:52, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хотелось подёргать хипстерам из команды разработчиков. Другими словами, разработан с учётом опыта языков с низким практическим применением.
     
  • 2.559, _oleg_ (ok), 16:48, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование
    > на шаблонах) попадет в ядро то туши свет. Rust хоть и
    > имеет более непривычный синтаксис чем С++, но все же разработан с
    > учетом опыта многих других языков.

    Про C++ согласен. Но и rust не нужен. Пусть пишут свои проекты. Зачем в ядро лезть. Там всё норм.

     

     ....большая нить свёрнута, показать (18)

  • 1.272, Аноним (263), 13:01, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >метапрограммирование
    >произвольные вычисления во время компиляции
    >безопасная работа с памятью

    Чего только не сделают, лишь бы переизобрести лисп в своем языке...
    Отправляйте всех любителей оного в нашу палату, пусть лучше на человеческом языке Mezzano OS пилят, а не гробят Линукс своими прогрессивными франкенштейнами.

     
  • 1.301, Аноним12345 (?), 14:28, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    хруст до добра не доведет
     
  • 1.355, Миллион глаз (?), 17:53, 15/01/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     
  • 1.359, DEF (?), 18:05, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. C++ такой же морально устаревший динозавр, как и C, просто еще более уродливый и окостыленный. Вот Rust, Carbon или Zig - более лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры этого языка.
     
     
  • 2.369, Аноним (194), 18:35, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Никаких новых парадигм в расте нету.Тогда уже лисп давайте
     
     
  • 3.428, Вы забыли заполнить поле Name (?), 22:55, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Никаких новых парадигм в расте нету.Тогда уже лисп давайте

    Путались в указателях, теперь будут путаться в скобочках.

     
  • 2.386, Аноним (386), 19:04, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. Раст требует грёбанного тулчейна.
    2. Хотя-бы потому, что на крестах доступны растопримитивы и это позволит инкрементно переводить код на раст. То есть сначала потихоньку сишный код переписывается на кресстовый. Потом крестовый приводится к растоподобному стилю. Потом переписывается на раст, фиксятся баги компиляции, фиксы бэкпортируются на кресты. Каждый патч проходит ревью. Тем самым обеспечивается преемственность, последовательность и контроль на каждом этапе.
     
     
  • 3.496, Аноним (499), 10:38, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Именно, а Раст без тулчейна и с unsafe теряет свои главные преимущества и принципиально ничем не отличается от Си.
     
  • 3.508, Советский инженер (ok), 12:20, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Раст требует грёбанного тулчейна.

    а с или с++ не требуют грёбанного тулчейна !?
    как же тогда текстовые файлы с исходным кодом преобразуються в выполняемые бинари/библиотеки?

     
  • 2.558, _oleg_ (ok), 16:47, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сам ты морально устаревший C такой же устаревший как ложка с вилкой Да что это... большой текст свёрнут, показать
     
     
  • 3.627, Аноним (631), 17:25, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Да что это за болезнь такая тащить всё модное всюду без разбора?

    Обычная болезнь зумеров. Знаний - мало, энергии - много, страсть ко всему новому (для их мозга). Увидели - слюни потекли, побежали ставить/канпелять. Плюс, такие же клоуны как они подливают масла в огонь своими "хелловорлдными" статейками (которыми только подтереться). И вот уже кто-то всерьёз обсуждает Раст.... *фэйспалм*

     

  • 1.381, Товарищ (?), 18:57, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Нет, к чёртовой матери таких товарищей.
     
  • 1.480, Вы забыли заполнить поле Name (?), 03:18, 16/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не узнаю вас, анонимы. Ловко вас провели. Что, уже идея с растом не так плоха как раньше?
     
     
  • 2.495, Аноним (499), 10:36, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Судя по реакции, скорее наоборот. Под угрозой включения Rust в ядро все уже согласны и на C++. Тем более что его последние стандарты сильно продвинулись по вопросу безопасности памяти.
     

  • 1.532, хрю (?), 14:57, 16/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.
     
     
  • 2.544, Вы забыли заполнить поле Name (?), 15:43, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.

    * Нужна поддержка сбоки модулей на другом языке.
    * Нужно выработать единый интрефейс для модулей на языке.

    Сейчас ядро про эти языки ничего не знает. Вот если сделать чтобы модули можно было писать независимо на любом языке. Насколько я понимаю для WASI (https://wasi.dev/) - это одна из целей.

     
     
  • 3.607, Аноним (-), 07:07, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот если сделать чтобы модули можно было писать независимо на любом языке

    Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. У них мышление не нормальное.

     
     
  • 4.634, Вы забыли заполнить поле Name (?), 02:53, 18/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>Вот если сделать чтобы модули можно было писать независимо на любом языке
    > Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию.
    > У них мышление не нормальное.

    Что плохого в идее WASI?

     

  • 1.535, Аноним (-), 15:25, 16/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс запретить. Всё! Такие вопросы вообще не должны обсуждаться.
     
     
  • 2.552, Аноним (499), 16:20, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода ядра на C++ продолжается, а ты можешь и дальше писать свои бессильные гневные комментарии.
     
  • 2.556, _oleg_ (ok), 16:43, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс
    > запретить. Всё! Такие вопросы вообще не должны обсуждаться.

    Да ладно бы ОО. C++ даже как ОО не очень. Просто страшное недоразумение какое-то. Сложный, запутанный и кривой.

     
     
  • 3.588, Вы забыли заполнить поле Name (?), 23:11, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не тролинга ради вопрос: в каком языке ООП сделано как надо?
     
     
  • 4.592, DEF (?), 23:26, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальное ООП должно быть основано на интерфейсах. Никакого наследования. Тем более множественного. Более-менее нормальное ООП в Java.
     
     
  • 5.608, Аноним (608), 07:34, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Никакого наследования.

    Да ты чё, сам придумал? Но тогда почитай, на каких столпах основано это самое ООП.

     
  • 4.612, _oleg_ (ok), 11:18, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Не тролинга ради вопрос: в каком языке ООП сделано как надо?

    smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, что видел. C++ и Java точно не из этого. Но в java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, выкинув некоторые извращения и ненужные усложнения.

     
     
  • 5.639, Серб (ok), 14:37, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не тролинга ради вопрос: в каком языке ООП сделано как надо?
    > smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того,
    > что видел. C++ и Java точно не из этого. Но в
    > java хотя бы насколько смогли улучшили ситуацию по сравнению с C++,
    > выкинув некоторые извращения и ненужные усложнения.

    Набор микросервисов с динамической типизацией. В качестве примера ООП это лучше не приводить. Он был первым, который вступил на тропу. Но свернул совсем не туда.

     
  • 5.682, fuggy (ok), 23:49, 22/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного класса от default interface теперь не многие назовут.
    А вы эти static utils *anything видели. Анемичные модели. Это разве похоже на ООП? Типичный процедурный стиль уровня C, с той разницей что все функции должны в классах лежать.
     
     
  • 6.683, _oleg_ (ok), 11:36, 23/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного
    > класса от default interface теперь не многие назовут.
    > А вы эти static utils *anything видели. Анемичные модели. Это разве похоже
    > на ООП? Типичный процедурный стиль уровня C, с той разницей что
    > все функции должны в классах лежать.

    Кто ж сказал, что java идеальна? C# в этом плане получше, по свидетельствам очевидцев.

     
  • 4.626, Аноним (631), 17:21, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Например, в D (чистый преемник С++). Нет множ.наследования (порождающие больше проблем, чем решающие). Есть traits. Шаблоны. Да вообще ВСЁ, что может понадобиться адекватному ООПщику - чего не пишется, спрашивается??
     
     
  • 5.640, Серб (ok), 14:40, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет множ.наследования (порождающие больше проблем, чем решающие).

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

     

  • 1.555, _oleg_ (ok), 16:41, 16/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что ж людям-то не работается спокойно. То rust с его кошмарным синтаксисом, то C++ - кромешное нагромождение всего и вся - пытаются запихнуть в ядро. Ёплки-палки, да работайте просто уже. Хернёй не страдайте.
     
     
  • 2.560, Аноним (-), 16:53, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >C++ - кромешное нагромождение всего и вся

    Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором есть всё в виде объектов.

     
     
  • 3.562, _oleg_ (ok), 17:04, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>C++ - кромешное нагромождение всего и вся
    > Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором
    > есть всё в виде объектов.

    Дело не в том, что там всё в виде объектов. Дело в том, что там просто кошмарный ужас из всего. Если хочется ООП, то надо смотреть на другие ЯП. C++ это не ООП. Это наркоманский приход. И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Он добился своего :-). Но мы этим пользоваться не обязаны.

     
     
  • 4.597, Вы забыли заполнить поле Name (?), 02:33, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся.

    Можно ссылку?

     
     
  • 5.598, Полная отсебятина (?), 02:57, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В книге The C Programming Language, 4th Edition, подчеркиваеться что Страустру... большой текст свёрнут, показать
     
  • 5.613, _oleg_ (ok), 11:22, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся.
    > Можно ссылку?

    Не могу найти оригинал. Перепечатка тут: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all . Хз насколько это троллинг, но, зная C++ в сравнении с другими ЯП, охотно воспринимается за чистую монету.

     

  • 1.605, Аноним (20), 04:39, 17/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Майкрософт вот не тупит и на расте уже Винду переписывает: https://www.theregister.com/2023/04/27/microsoft_windows_rust/

    А комментаторы опеннета всё живут умом где-то в в 90-ых.

     
     
  • 2.606, Аноним (-), 07:04, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Приводить Майкрософт (компанию, которую все презирают), как пример для подражания. Ну, это даже не шутка, это жирнейший троллинг.
     
  • 2.625, Аноним (631), 17:16, 17/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То, что в M$ работают индусские м@к@ки, порождает и соотв. решения - вот Раст к примеру :)) Абсолютно необоснованное решение. Как и попытки заигрывания в Линукс внутри венды.
    Сейчас M$ далеко не "гигант ИТ" - это монстр, который полностью сгнил внутри и идёт чисто как зомби - по инерции. Венда-10-11 - это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание.
    На плаву держатся серверные системы и MS SQL (видимо, обезьян не подпускают к золотой курице).

    Другими словами, найдите пример поинтереснее.

     
     
  • 3.657, Аноним (-), 20:20, 19/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > внутри и идёт чисто как зомби - по инерции. Венда-10-11 -
    > это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в
    > ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание.

    Да это вы просто не видели что они с виндофоном вытворяли. Еще и нокию за собой утопили, угробив все наработки UI/UX от нокии, с...ки!

     

  • 1.621, Аноним (631), 14:41, 17/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Заскорузлые мозги => устаревшие решения.

    Почему не D ?? Для кого развивали "преемника С++"? Там же всё по-уму сделано, а популяризация его в линукс-камьюнити только ещё больше поможет языку.

     
     
  • 2.632, Аноним (632), 00:09, 18/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если бы его грамотно пиарили и больше людей в разработку включили, а так имеем что имеем. Но он еще вполне жив, так что посмотрим.
     

  • 1.667, Аноним (667), 13:34, 20/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты с их шаблонной магией и прочими непотребствами стандарта на много тысяч страниц. Таким образом резко повышается порог вхождения.
     
  • 1.671, Аноним (671), 03:53, 21/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С++ и С имеют множества недостатков от которых некоторые современные языки вылечены. Проблема в том что разработчики компиляторов и железа в первую очередь поддерживают С,С++ и в стандартизации — разных поставщиков и наборе инструментов. Поэтому выигрывает тот язык, который сумеет буквально его поглощать трансляцией в другой язык. Таких пока вроде нет и вряд ли будет — из-за множества ньюансов дешевле нанять команду разработчиков которые будут переводить из С на свой язык библиотеки и фреймворки. А вот локальные миссии по созданию цифровой экосистемы могли бы дать результат, если целенаправленно двигаться лет так 10–15. Но миссии это у американцев, потому что у них agile процессы.
     
     
  • 2.693, Аноним (693), 14:10, 28/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поток сознания
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру