M>>К модулям это имеет нулевое отношение
DE>Честно говоря, не понял. Возможно, потому что представляю, в первую очередь, то как растовые модули сейчас устроены и не понимаю как приведённый пример их чинит.
Он их не чинит. Он показывает, что модули и условная компиляция ортогональны друг другу.
M>>Што? Зачем удалять и т.п. файл? DE>Сейчас в расте модули в проекте (crate в терминах раста) представляют древовидную структуру, где корнем являет lib.rs/main.rs.
Модули почти везде представляют собой древовидную структуру. Но никто, кроме раста, не требует объявлять модуль не в модуле, а в коде, который вызывает этот модуль.
DE>Конструкция mod <имя_модуля> добавляет модуль в проект.
Что значит «добавляет в проект». Вот он модуль. Уже лежит в проекте. Почему модуль объявляется не в модуле, а в файле, который вызывает этот модуль?
DE>Вообще мне кажется, что мы несколько о разном говорим. Я всё-таки считаю, что mod — это не про импорт, а про построение структуры проекта. Импорт (из библиотек) или других модулей проекта делается вполне очевидно (через use).
mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Здравствуйте, Mamut, Вы писали:
M>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Файл mod.rs позволяет делать реэкспорт модулей и прочих сущностей из других модулей. Они тут, возможно, сымпровизировали по мотивам того, что похожий реэкспорт модулей умеет делать Haskell.
D>Файл mod.rs позволяет делать реэкспорт модулей и прочих сущностей из других модулей. Они тут, возможно, сымпровизировали по мотивам того, что похожий реэкспорт модулей умеет делать Haskell.
Здравствуйте, Mamut, Вы писали:
M>Он их не чинит. Он показывает, что модули и условная компиляция ортогональны друг другу.
Не понимаю как в приведённом примере взаимодействует указание пути и "что.угодно.где.угодно". Цель как раз в том чтобы в зависимости от настроек компиляции можно было сделать use/import только на один из нескольких взаимоисключающих модулей.
M>Что значит «добавляет в проект». Вот он модуль. Уже лежит в проекте. Почему модуль объявляется не в модуле, а в файле, который вызывает этот модуль?
Хорошо, что такое проект? Все файлы, которые лежат в определённой директории?
Как должна выглядеть иерархия модулей в таком случае? Соответствовать один к одному файловой структуре?
Как запретить лезть в подмодули из других частей проекта?
M>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Нет, отношение как раз прямое. Можно посмотреть на внешние подмодули как на частный случай объявленных внутри файла — они не самостоятельны и модуль верхнего уровня решает что будет видно снаружи.
M>>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
DE>Нет, отношение как раз прямое. Можно посмотреть на внешние подмодули как на частный случай объявленных внутри файла — они не самостоятельны и модуль верхнего уровня решает что будет видно снаружи.
//a.rs
mod c
use c::...
-----------
//b.rs
mod c
use c::...
-----------
c.rs
этот файл и есть модуль. Но объявить его модулем
невозможно. Почему? Потому что.
Вместо этого его надо объявлять модулем по месту
вызова. Што?
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
Тут занятный отчет человека, что в embedded на голом железе писал и перешел с С++ на Раст, что получилось и как он доволен: http://cliffle.com/blog/m4vga-in-rust/
Здравствуйте, D. Mon, Вы писали: DM>Тут занятный отчет человека, что в embedded на голом железе писал и перешел с С++ на Раст, что получилось и как он доволен: DM>http://cliffle.com/blog/m4vga-in-rust/
Я так понял, что у него система хард-реалтайм со статической памятью. Довольно важная и критичная к багам ниша, но там скорее с C конкурировать надо, чем с C++. Aргумент "std::vector::push_pack" не работает полноценно без динамики и RTTI как-то странен в контексте статической памяти. Нужна статика — не используй std::vector, ведь последний вовсе не затачивался под подобное использование, а один контейнер не может удовлеторить нужды всех приложений. Статический вектор довольно просто изобразить на std::aligned_storage. Вот и он тоже написал, что в реализации на плюсах переписал все зависимости на "безопасные". Это также (помимо камня в огород слабой предсказуемости ран-тайм поведения стандартной библиотеки и реверанса в сторону растовского no_std) говорит о том, что сама система маленькая, раз один человек осилил переписать все зависимости, не важно, на каком языке.
__>а один контейнер не может удовлеторить нужды всех приложений.
А хорошо бы, чтобы мог Ну ладно, не всех приложений, но хотя бы более-менее разумного их спектра. Микроскопический embedded на каких-нибудь уже мало кому нужных восьмибитных AVR, или вполне еще живых и любимых китайцами STM8, так уж и быть, отбросим. Но неприспособленность std::vector к вполне мощным в своей весовой категории STM32 в сценарии bare metal, realtime, no exceptions, no RTTI firmware – это провал ортогональности по Степанову. Понятно, что есть кастомные аллокаторы, но спасут ли они от прибитости гвоздями к RTTI?
__>говорит о том, что сама система маленькая, раз один человек осилил переписать все зависимости, не важно, на каком языке.
Или же говорит о том, что рантайм привычных систем неоправданно сложен (или монолитен, или лапшеобразен), т.к. требует более одного человека на перепиливание столь базовых вещей.
когда доводов не хватает тогда начинаются сливы по типу — а хочу что бы из каробки аля std::
если же смотреть на процесс разработки с самого начала
то в нем есть один два синьора, которые уже все знают и умеют
и проблем ни с векторами ни с ртти итд нет
когда же процесс разработки построен так что вместо синьоров сидят и варятся десяток джунов
тогда все именно так как вы описываете
Microsoft recently created a stir after revealing it was taking some ideas from the popular Rust programming language to create a new language for 'safe infrastructure programming' under the banner Project Verona.
R>когда доводов не хватает тогда начинаются сливы по типу — а хочу что бы из каробки аля std::
Сливы в саду у дяди Вани В ржавом же, по утверждению джентльмена из статьи, core портируется легче, чем даже сишный newlib. Что говорить — Rust и на 8-ми битах уже успешно гоняют. Большой плюс в "системность". Что, впрочем, не отменяет его слабых сторон: например, аллес с полнотой и актуальностью документации, многие фичи только в nightly, непонятное будущее Mozilla, странное community, метапрограммирование так себе (в отличие от D и Nim).
R>то в нем есть один два синьора, которые уже все знают и умеют R>и проблем ни с векторами ни с ртти И так далее нет
Понятно, что нет. Т.к. std:: вменяемые люди изначально обходят десятой дорогой. У EA – EASTL, у Блумберга – BSL, у WebKit и Blink – WTF, у Qt – свой Qt Core и т.д. Ничего, в принципе, плохого в этом нет, но если у Rust получится успешно таскать стандартную библиотеку от мелкоконтроллеров до мейнфреймов — будет круто.
R>когда же процесс разработки построен так что вместо синьоров сидят и варятся десяток джунов
То изначально понятно, что вообще ничего не получится.
Ну ладно, не всех приложений, но хотя бы более-менее разумного их спектра. Микроскопический embedded на каких-нибудь уже мало кому нужных восьмибитных AVR, или вполне еще живых и любимых китайцами STM8, так уж и быть, отбросим. Но неприспособленность std::vector к вполне мощным в своей весовой категории STM32 в сценарии bare metal, realtime, no exceptions, no RTTI firmware – это провал ортогональности по Степанову. Понятно, что есть кастомные аллокаторы, но спасут ли они от прибитости гвоздями к RTTI?
