<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Дискуссия об использовании языка C++ для разработки ядра Linux</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html</link>
    <description>В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра...&lt;br&gt;&lt;br&gt;Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60436&lt;br&gt;</description>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (wyry)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#695</link>
    <pubDate>Tue, 20 Aug 2024 11:19:48 GMT</pubDate>
    <description>У меня поменялось мнение по поводу Carbon: профитнее лучше изучить сами плюсы, чем внедрять левый язык. В C++ УЖЕ есть все инструменты чтобы писать простой и безопасный код, нужно лишь научиться и разработать хорошие гайдлайны для последователей, в этом значительно больше смысла, чем разработка очередного языка, как будто сейчас мало языков.&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (freehck)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#694</link>
    <pubDate>Tue, 25 Jun 2024 11:05:50 GMT</pubDate>
    <description>&amp;gt; Люди думают понятиями а не раздельно существующими матрицами свойств.&lt;br&gt;&lt;br&gt;Что ближе к корове, трава или курица?&lt;br&gt;&lt;br&gt;Аналитик ответит, что курица, потому что они оба -- животные.&lt;br&gt;Холист ответит, что трава, потому что корова её ест.&lt;br&gt;&lt;br&gt;Надо уметь думать и так, и эдак. Тезис о том, что &quot;люди думают понятиями&quot; -- это ошибка и одновременно оправдание, чтобы не осваивать мышление иного рода.&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#693</link>
    <pubDate>Thu, 28 Mar 2024 11:10:24 GMT</pubDate>
    <description>Поток сознания&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (n00by)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#692</link>
    <pubDate>Thu, 25 Jan 2024 14:02:47 GMT</pubDate>
    <description>&amp;gt; Линуса просто уже ранее настойчиво попросили быть повежливее..&lt;br&gt;&amp;gt; Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus &lt;br&gt;&amp;gt; C++ is a horrible language. It&apos;s made more horrible by the fact &lt;br&gt;&amp;gt; that a lot of substandard programmers use it, to the point &lt;br&gt;&amp;gt; where it&apos;s much much easier to generate total and utter crap &lt;br&gt;&amp;gt; with it. Quite frankly, even if the choice of C were &lt;br&gt;&amp;gt; to do *nothing* but keep the C++ programmers out, that in &lt;br&gt;&amp;gt; itself would be a huge reason to use C.&lt;br&gt;&lt;br&gt;На это я отвечал в #211&lt;br&gt;&lt;br&gt;&amp;gt; и про ядро: &lt;br&gt;&amp;gt; In fact, in Linux we did try C++ once already, back in &lt;br&gt;&amp;gt; 1992.&lt;br&gt;&amp;gt; It sucks. Trust me - writing kernel code in C++ is a &lt;br&gt;&amp;gt; BLOODY STUPID IDEA.&lt;br&gt;&lt;br&gt;И на это тоже. Правда, не на цитату Линуса, а на изложенный экспертом похожий смысл. Подсказывать не хочу -- думайте сами над очевидным ляпом, если считает себя знатоком С++.&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Stellarwind)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#691</link>
    <pubDate>Thu, 25 Jan 2024 12:39:26 GMT</pubDate>
    <description>Линуса просто уже ранее настойчиво попросили быть повежливее..&lt;br&gt;&lt;br&gt;Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus&lt;br&gt;&lt;br&gt;C++ is a horrible language. It&apos;s made more horrible by the fact that a lot of substandard programmers use it, to the point where it&apos;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.&lt;br&gt;&lt;br&gt;и про ядро:&lt;br&gt;&lt;br&gt;In fact, in Linux we did try C++ once already, back in 1992.&lt;br&gt;It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#690</link>
    <pubDate>Wed, 24 Jan 2024 03:18:39 GMT</pubDate>
    <description>Резюмируя два.&lt;br&gt;Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела.&lt;br&gt;Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет.&lt;br&gt;Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник.&lt;br&gt;&lt;br&gt;Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Tron is Whistling)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#689</link>
    <pubDate>Tue, 23 Jan 2024 19:32:25 GMT</pubDate>
    <description>Почему? Потому что по законам Мерфи первым сдохнут датчики для вашего софта.&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Tron is Whistling)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#688</link>
    <pubDate>Tue, 23 Jan 2024 19:16:02 GMT</pubDate>
    <description>А ваш софт умеет думать, пока МК дымится вместе с платой? :)&lt;br&gt;</description>
</item>

<item>
    <title>Дискуссия об использовании языка C++ для разработки ядра Lin... (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/132575.html#687</link>
    <pubDate>Tue, 23 Jan 2024 19:14:50 GMT</pubDate>
    <description>&amp;gt; Если у вас на плате нет защиты от превышения тока кроме софта &lt;br&gt;&lt;br&gt;По законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;)&lt;br&gt;&lt;br&gt;И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать &quot;без причины&quot;. А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще.&lt;br&gt;&lt;br&gt;Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя.&lt;br&gt;&lt;br&gt;По причинам выше - быстродействующий предохранитель, &quot;на грани&quot; - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя</description>
</item>

</channel>
</rss>
