Исходное сообщение
"Линус Торвальдс о проблемах с поиском мэйнтейнеров, Rust и р..." Отправлено Аноним, 08-Июл-20 07:26
> катит, но  пока только для винды и для винды не катит Даже UMDF юзерспейсный драйвер там пишут максимум на С++. Настоящие драйверы уровня ядра на С. Вон том огрызке, который поддерживает MSVC compiler. > но он принципиально не для этого сделан и использовать его так неправильно. Не "неправильно", а не возможно! Неправильно использовать С++ для таких задач. Есть концептуальная проблема. Устройства не работают в этих красивых и прекрасных ООП-моделях. Компьютеры и устройства работают не с объектами и всяким поведением, они работают с данными и состояниями. И это не какая-та там особенность конкретного языка мешает. Это речь о том, что объектно ориентированная абстракция не может быть транслирована в машинный код, пригодный для выполнения сразу. Для того чтобы ООП работало, нужно его переделать в некое промежуточное представление (структуры, процедуры и конечные автоматы) то есть избавить его от ООП-требухи и вот полученный структурный (тоже жесткое условие на самом деле, может быть и частично неструктурный) код промежуточного языка уже можно конвертировать в машинный под нужную платформу. Естественно, некоторые языки свой промежуточный байткод не компилируют, а исполняют на лету, а некоторые компилируют, а в некоторых можно и так и сяк. Все ООП-языки имеют промежуточное представление. Исключений нет. Так вот, если ты программируешь драйверы, тебе нужно знать точно, что делает твой код на самом деле, а не полагаться что компилятор сгенерирует правильное промежуточное представление, которое подойдет под устройство под которое ты пишешь драйвер. Другая проблема - это работа с памятью. Нужно уметь ею управлять. Все языки где присутствуют GC (сборщики мусора) работающие с промежуточными представлениями и/или компилируют на лету (JIT) не подходят для написания драйверов. Исключением могут быть так называемые драйверы пространства пользователя. В Linux их мало, вон FUSE, например. С другой стороны это всего-лишь библиотеки, которые подключаются через специальное API и работают с теми подсистемами, которые можно размещать в юзерспейсе. Но лучше так не делать и для них. C++ тут как раз и прикидывается нормальным решением, хотя таковым не является. Его принципиальным отличием является не наличие указателей, возможности прямой работы с памятью в режиме С с классами, нет... Его отличие от нормальных ООП-языков в том, что С++ - это инвалид детства у которого нет стандарта на промежуточное представление. То есть промежуточное представление есть (компиляторы работают в 2 этапа), но стандарта нет. Именно поэтому он не просто не кросплатформенный, в нем бинарные библиотеки нормально не линкуются, если были собраны в другом компиляторе или в очень старой версии. И вот вопрос, зачем такое для драйверов, даже юзерспейсных в винде разрешают для меня вопрос... видимо один фреимворк в одном компиляторе с кучей специфичных параметров для сборки решает эту проблему. Героическое решение, для проблемы, которая была создана на пустом месте от факта разрешения писать на С++ для части драйверов. Там по-любому что-то исторически сложилось... C# в свою очередь работает поверх CLR, как Java поверх JVM. Это вообще ортогонально любым низкоуровневым задачами. Rust, с другой стороны, я сильно не копал. Синтаксис у него - имхо, фу. Но оно там как раз памятью управляет жестко, GC не имеет, ручное педалирование памяти умеет и не может в ООП, что, в принципе, не исключает его как возможность писать какие-то юзерспейсные дровишки сбоку, если в Linux их побольше завезут. Но, опять же, агрессивный маркетинг Rust тут сам себе противоречит. Адепт Раста: Rust - замена C/C++ они такие-сякие и дальше по тексту... Программист: Но ведь Rust не может... (перечень 100500 ООП-специфичных подходов) Адепт Раста: Ты просто решаешь задачу на ООП, ООП - не задача (это правда, кстати) перерешай задачу по-другому Программист: Но ведь есть же проект, куча народу 100500 тысяч строк зависимого кода от моей либы Адепт Раста: Перепиши на растишку всё, весь проект, все смежные, всю экосистему, дом, квартиру, машину, дачу, контрольную, домашку, небо и Аллаха. Программист: И в чем же тогда замена С++... Ой всё... И они бесят со своей рекламой. "Не найдётся ли у вас минутки поговорить о великом языке программирования Расте, прогрессивно заменяющем отсталые С/С++".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> катит, но пока только для винды > и для винды не катит > Даже UMDF юзерспейсный драйвер там пишут максимум на С++. Настоящие драйверы уровня > ядра на С. Вон том огрызке, который поддерживает MSVC compiler. >> но он принципиально не для этого сделан и использовать его так неправильно. > Не "неправильно", а не возможно! Неправильно использовать С++ для таких задач. > Есть концептуальная проблема. Устройства не работают в этих красивых и прекрасных ООП-моделях. > Компьютеры и устройства работают не с объектами и всяким поведением, они > работают с данными и состояниями. И это не какая-та там особенность > конкретного языка мешает. Это речь о том, что объектно ориентированная абстракция > не может быть транслирована в машинный код, пригодный для выполнения сразу. > Для того чтобы ООП работало, нужно его переделать в некое промежуточное > представление (структуры, процедуры и конечные автоматы) то есть избавить его от > ООП-требухи и вот полученный структурный (тоже жесткое условие на самом деле, > может быть и частично неструктурный) код промежуточного языка уже можно конвертировать > в машинный под нужную платформу. Естественно, некоторые языки свой промежуточный байткод > не компилируют, а исполняют на лету, а некоторые компилируют, а в > некоторых можно и так и сяк. > Все ООП-языки имеют промежуточное представление. Исключений нет. Так вот, если ты программируешь > драйверы, тебе нужно знать точно, что делает твой код на самом > деле, а не полагаться что компилятор сгенерирует правильное промежуточное представление, > которое подойдет под устройство под которое ты пишешь драйвер. Другая проблема > - это работа с памятью. Нужно уметь ею управлять. Все языки > где присутствуют GC (сборщики мусора) работающие с промежуточными представлениями и/или > компилируют на лету (JIT) не подходят для написания драйверов. > Исключением могут быть так называемые драйверы пространства пользователя. В Linux их мало, > вон FUSE, например. С другой стороны это всего-лишь библиотеки, которые подключаются > через специальное API и работают с теми подсистемами, которые можно размещать > в юзерспейсе. Но лучше так не делать и для них. C++ > тут как раз и прикидывается нормальным решением, хотя таковым не является. > Его принципиальным отличием является не наличие указателей, возможности прямой работы > с памятью в режиме С с классами, нет... Его отличие от > нормальных ООП-языков в том, что С++ - это инвалид детства у > которого нет стандарта на промежуточное представление. То есть промежуточное представление > есть (компиляторы работают в 2 этапа), но стандарта нет. Именно поэтому > он не просто не кросплатформенный, в нем бинарные библиотеки нормально не > линкуются, если были собраны в другом компиляторе или в очень старой > версии. И вот вопрос, зачем такое для драйверов, даже юзерспейсных в > винде разрешают для меня вопрос... видимо один фреимворк в одном компиляторе > с кучей специфичных параметров для сборки решает эту проблему. Героическое решение, > для проблемы, которая была создана на пустом месте от факта разрешения > писать на С++ для части драйверов. Там по-любому что-то исторически сложилось... > C# в свою очередь работает поверх CLR, как Java поверх JVM. Это > вообще ортогонально любым низкоуровневым задачами. > Rust, с другой стороны, я сильно не копал. Синтаксис у него - > имхо, фу. Но оно там как раз памятью управляет жестко, GC > не имеет, ручное педалирование памяти умеет и не может в ООП, > что, в принципе, не исключает его как возможность писать какие-то юзерспейсные > дровишки сбоку, если в Linux их побольше завезут. Но, опять же, > агрессивный маркетинг Rust тут сам себе противоречит. > Адепт Раста: Rust - замена C/C++ они такие-сякие и дальше по тексту... > Программист: Но ведь Rust не может... (перечень 100500 ООП-специфичных подходов) > Адепт Раста: Ты просто решаешь задачу на ООП, ООП - не задача > (это правда, кстати) перерешай задачу по-другому > Программист: Но ведь есть же проект, куча народу 100500 тысяч строк зависимого > кода от моей либы > Адепт Раста: Перепиши на растишку всё, весь проект, все смежные, всю экосистему, > дом, квартиру, машину, дачу, контрольную, домашку, небо и Аллаха. > Программист: И в чем же тогда замена С++... Ой всё... > И они бесят со своей рекламой. "Не найдётся ли у вас минутки > поговорить о великом языке программирования Расте, прогрессивно заменяющем отсталые С/С++".
	Введите код, изображенный на картинке: