Здравствуйте, DarkEld3r, Вы писали:

DE>Это ты потратил столько слов, чтобы поделиться "тайным знанием" про noalias?..

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

Здравствуйте, T4r4sB, Вы писали:

TB>Это одно из последствий двух мутабельных ссылок, но не единственное.

Ок, а второе? В СПб перебираться не планирую. (:

Здравствуйте, DarkEld3r, Вы писали:

DE>Здравствуйте, T4r4sB, Вы писали:

TB>>Это одно из последствий двух мутабельных ссылок, но не единственное.

DE>Ок, а второе? В СПб перебираться не планирую. (:

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

Здравствуйте, T4r4sB, Вы писали:

_>>Ну давай, расскажи о том какие будут проблемы. )))
TB>Сначала скажи, не хочешь ли ты в СПб переехать?

Вряд ли может возникнуть достаточно существенная причина для подобного. ) А вот просто заехать выпить в Питер я вполне могу иногда. ))) И конечно же всегда могу организовать подобное же в Москве. )))

TB>Потому что обычно я этими вопросиками гружу потенциальных растаманов на собесах. Слишком много людей хорошо выучило правило про две мутабельные ссылки, но не понимают, зачем оно, и от каково количества разнообразных граблей оно защищает, причём местами геморрой на обход защиты превышает геморрой на поиск бага в аналоге на С++

Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом). И ничего страшного от этого не происходит. Единственная разница в том, что при этом ещё добавлена рантайм проверка на тот факт, что ссылки не используются одновременно и всё. В случае однопоточного кода это элементарно делается просто по построению (например ссылка формируется только при создание колбека).

И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))

Здравствуйте, alex_public, Вы писали:

_>Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html),

И то и другое — это одни и те же яйца, только с разных углов )) Структурно твой код на расте почти не будет отличаться от кода сишника с использованием HAL STM32 )) Т.к. динамическое выделение памяти практически не используется, преимуществ у раста почти нету. А если сравнивать с плюсами и его constexpr, то плюсы лично для меня предпочтительнее. У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.

Лично моё мнение, что киллер-фичи раста (крутые макросы, на которых основан в том числе рефлекш, итераторы, async, алгебраические типы, паттерн-матчинг) практически бесполезны при разработке для младших МК и ничего не дают по сравнению с си или плюсами (ну кроме повышения ЧСВ, т.к. ты пишешь ембед на расте ))))

N>Пишут это в контексте C/C++, но пример с энергоэффективность почему-то касается javascript.
Node.JS написано на С++, а раст быстрее чем javascript, а значит быстрее чем С++. Шах и мат сишники.

Здравствуйте, alex_public, Вы писали:

_>Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом).

Да, но у него есть маааленький нюанс, для него не генерится кой-какой атрибутик в LLVM-IR коде, от которого всё потенциально поедет нафиг, если ты сделаешь подобное не для refcell а для интов.

_>И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))

Ну я хочу ещё тебя помучать) Я на первой странице ещё рассказал про один атрибутик, которые генерит Раст, но не имеет права генерить С++. И про него на этой странице уже вспомнили)

Здравствуйте, T4r4sB, Вы писали:

_>>Только в C++ нет пакетного менеджера для таких пакетов с библиотеками-заглушкам под ОС АПИ — подразумевается, что они уже лежат в системных путях. Ну и ты же не забыл, что многие Rust библиотеки внутри зависят от C/C++ библиотек и делают их сборку внутри себя?
TB>Не, я всё равно не понял. Вот я объявил функцию как импортную из системной дллки а каким-то именем. Разве компоновщику что-то нужно знать дополнительно, чтобы скомпилировать екзешник?

Ты предлагаешь руками их объявлять? ))) Всё же для этого используют специальные библиотеки... В Rust эти библиотеки (-sys) ставят пакетным менеджером. А в C++ они прилетают с тулчейном. )))

Здравствуйте, alex_public, Вы писали:

_>Ты предлагаешь руками их объявлять? )))

А разве не так делается?
Скачиваешь из интернета заголовок, в котором руками объявлены импорты всех функций ВинАПИ, не?

Здравствуйте, ArtDenis, Вы писали:


AD>У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.

Интересно, а можно где-то глянуть?

Здравствуйте, Reset, Вы писали:

R>Сейчас идет активная работа по включению возможности писать на Rust модуля ядра Linux. Уже прошло несколько итераций (4 или 5), внесли некоторые изменения в библиотеку Rust и, возможно, компилятор. Раньше в Rust были какие-то ограничения, кажется, в виде поддержки в runtime чего-то, что для ядра неприемлемо и Panic, когда не надо. Сейчас уже многое исправлено, причем в стабильной версии компилятора и библиотек и теперь Rust близок к тому, чтобы на нем можно было писать модули ядра Linux.

Пропал калабуховский дом

Впрочем, буханка не нужна и так

Здравствуйте, Marty, Вы писали:

M>Интересно, а можно где-то глянуть?

https://github.com/art-den/stm32_pll_calculator

Там некоторые параметры указаны по умолчанию, но их тоже можно задавать (MinVcoFreq, MaxVcoFreq и т.п.) полезно при сильном разгоне чипа, если это вдруг понадобилось.

Здравствуйте, ArtDenis, Вы писали:

M>>Интересно, а можно где-то глянуть?

AD>https://github.com/art-den/stm32_pll_calculator

AD>Там некоторые параметры указаны по умолчанию, но их тоже можно задавать (MinVcoFreq, MaxVcoFreq и т.п.) полезно при сильном разгоне чипа, если это вдруг понадобилось.


Спс

Здравствуйте, T4r4sB, Вы писали:

_>>1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
_>>2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.
TB>Ну давай, есть граф, его вершины хранятся в юниках, каждая вершина хранит ссылки на другие вершины в виде сырых указателей. Корректна ли эта архитектура? Нет, ведь если мы вытащим юник вершину и грохнем граф, то в вершине будут висячие ссылки. Корректна ли архитектура, если мы запретим вытаскивать вершины и поклянёмся, что вершина будет удаляться только вместе со всеми ведущими на неё ссылками? Да. Можем ли мы это доказать компилятора Раста? Нет, не может.

Сомнительная архитектура что для Rust, что для C++. Я бы для начала попробовал бы так (код на Rust, но на C++ переписывается дословно):

struct Node {
    name: String,
    children: Vec<usize>
}

struct Graph {
    nodes: HashMap<usize, Node>
}

impl Graph {
    fn insert(&mut self, node: Node, parent: Option<usize>) -> usize {
        let id = self.nodes.len();
        self.nodes.insert(id, node);
        parent.map(|p| self.nodes.get_mut(&p)).flatten().map(|p| p.children.push(id));
        id
    }
}

Здравствуйте, ArtDenis, Вы писали:

_>>Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html),
AD>И то и другое — это одни и те же яйца, только с разных углов )) Структурно твой код на расте почти не будет отличаться от кода сишника с использованием HAL STM32 ))

Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет?

AD>Т.к. динамическое выделение памяти практически не используется, преимуществ у раста почти нету. А если сравнивать с плюсами и его constexpr, то плюсы лично для меня предпочтительнее. У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.
AD>Лично моё мнение, что киллер-фичи раста (крутые макросы, на которых основан в том числе рефлекш, итераторы, async, алгебраические типы, паттерн-матчинг) практически бесполезны при разработке для младших МК и ничего не дают по сравнению с си или плюсами (ну кроме повышения ЧСВ, т.к. ты пишешь ембед на расте ))))

Я с тобой полностью согласен, что у Rust тут преимуществ нет (как у языка). Нюанс в том, что для получения красивого (с типами и т.п.) кода на C++ мне надо будет его самому написать. А в случае Rust я его получаю подключением зависимости.

Т.е. преимущество у Rust всё же есть, но не техническое, а так сказать историческое (в нём от рождения начали пытаться решить по красивому, а в C++ в промышленных библиотеках до сих пор не дошли до этого).

Здравствуйте, T4r4sB, Вы писали:

_>>Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом).
TB>Да, но у него есть маааленький нюанс, для него не генерится кой-какой атрибутик в LLVM-IR коде, от которого всё потенциально поедет нафиг, если ты сделаешь подобное не для refcell а для интов.

С чего бы это он не генерится то? )))

_>>И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))
TB>Ну я хочу ещё тебя помучать) Я на первой странице ещё рассказал про один атрибутик, которые генерит Раст, но не имеет права генерить С++. И про него на этой странице уже вспомнили)

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

Здравствуйте, T4r4sB, Вы писали:

_>>Ты предлагаешь руками их объявлять? )))
TB>А разве не так делается?
TB>Скачиваешь из интернета заголовок, в котором руками объявлены импорты всех функций ВинАПИ, не?

Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)?

Здравствуйте, alex_public, Вы писали:

_>Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет?

Ну покажи свой (или чужой) код с использованием stm32-rs. Инициализацию периферии, устройств, которые к ней подключены и т.п.

Здравствуйте, alex_public, Вы писали:


_>Сомнительная архитектура что для Rust, что для C++.

Да нормальная. Ты предлагаешь вместо ссылок индексы. Это лишняя индирекция, а ещё тебе надо протаскивать мутабельную ссылку на граф во все методы вершин. Это надёжнее и легче отлаживать, но и исходный вариант оптимален.

Здравствуйте, alex_public, Вы писали:

_>С чего бы это он не генерится то? )))

С того, что RefCell содержит внутри некую Lang Item. То есть компилятор знает, что именно для определённой структуры из std не надо генерить этот атрибутик.
Если у тебя есть rust на компе, то всегда можешь сгенерить релизный код с --emit=llvm-ir и посмотреть.

_>Ты лучше расскажи какие такие ужасы могут возникнуть из-за твоего атрибутика при условие отсутствия одновременной работы с несколькими мутабельными ссылками (но при одновременном существование этих ссылок).

Как ты думаешь, что делается с кодом при наличии этого атрибутика?