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

_>>Это возможно просто неправильная архитектура. ) А может и нормальная — отсюда не видно. ))) Зависит от задачи. Если у тебя там данные, ссылка на которые захватывается (замыканием) коллбеком, реально постоянно создаются/уничтожаются в памяти, то это правильная архитектура. Если же нет, то вместо Rc<RefCell<>> на самом деле должно было быть &'static mut.
TB>Статик мут? Как вообще это возможно? Глобалки делать мутабельными сложновато.

О да, ужасно сложновато: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak )))

TB>Ну и доступ к этой сущности блокируется на всё потенциальное время жизни калбака.

Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе. И кстати она не будет нарушать никаких гарантий, т.к. у тебя и так очевидно не многопоточный код (иначе был бы не Rc<RefCell<>>). Просто компилятор этого не знает (и не может знать), а тут ты с помощью этого unsafe говоришь ему об этом. Собственно RefCell в общем то делает тоже самое, но уже через проверки в рантайме... )))

_>>Вообще тут можно легко смотреть по аналогии с C++. Rc<RefCell<>> должно быть в коде в тех местах, где в C++ был бы shared_ptr (которого кстати обычно стараются избегать). И не более того!
TB>Ээээ, нет. В С++ проще сделать юник и много простых указателей на содержимое, потому что ты знаешь хозяина. Доказать это знание борроу-чекеру в общем случае невозможно.

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

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

_>Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе.

А знаешь что будет если ты таким образом случайно зафигачишь две мутабельные ссылки на один объект?

_>Вот и не стоит засовывать подсчёт ссылок туда, где его не было в C++. Очевидно же, что это означает что в нём нет потребности, а появляется он только от неумения пользоваться другими возможностями языка.

Расскажи, как без Rc сделать архитектуру юник+обычные указатели. Поинтеры из Раста не предлагать.
Ссылки раскидывать внутри графа не получится. Значит, нужен слабый указатель. А он живёт только в паре с Rc, вот так вот

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

DE>>Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.
TB>Если использовать ансейф, то нахрена козе баян?
TB>Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?

Ох, такое впечатления, что тут собрались не бывшие C++ программисты, а какие-то JS/Python любители, которые воспринимают слова типа "указатель" и т.п. как некую чёрную магию.

В Rust'е всё работает абсолютно точно так же как и в C++ и применимы все те же самые приёмы работы с указателями, ссылками и т.п.. И это всё будут не какие-то грязные хаки, а нормальное программирование — для этого данный язык и задумывался!

Единственная принципиальная разница заключается в том, что все нормальные объекты в Rust являются перемещаемым (кстати как раз за счёт этого он бывает частенько быстрее C/C++), так что стандартные игры с указателями/ссылками напрямую применимы только к глобальным объектам. Однако и для локальных это легко меняется с помощью данной https://doc.rust-lang.org/std/pin/ функциональности, приводящий и локальные объекты к привычному C/C++ поведению.

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

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

S>>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?
AD>Какие либы подцепишь, такие он и добавит в exe-шник. Если ничего не подцепишь, то там будет только твой код. Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.

Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))

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

AD>>Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.

_>Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))

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

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

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

Две мутабельные ссылки на один объект это УБ.
Знаешь ли ты, что такое УБ?
Ну вот ты и попался, поздравляю.
Это правило необходимо даже для однопоточного кода.
Более того, ты поимеешь проблемы даже если у тебя будут две мутабельные ссылки на один инт.

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

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

Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.

А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.

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

_>Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.

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

_>А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.

Ну под винду выбор либо ставить полтора гигабайта студии, либо трахаться с гнутым тулчейном.

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

TB> ... либо трахаться с гнутым тулчейном.

Это как?

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

AD>Это как?

Я уже не помню, и боюсь трогать что-то.
Короче когда я ставил таргет -i686-windows-gnu, то там выплывало сообщение в стиле "найди мне минГВ, мне похер где". И я не помню, что я сделал, чтоб оно заработало, может патхи какие-то прописал, потому что у меня так-то был мингв. И когда оно заработало, то я уже не мог выставить таргет -x64-windows-gnu, потому что мингв видимо не тот.

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

TB>Короче когда я ставил таргет -i686-windows-gnu, то там выплывало сообщение в стиле "найди мне минГВ, мне похер где". И я не помню, что я сделал, чтоб оно заработало, может патхи какие-то прописал, потому что у меня так-то был мингв. И когда оно заработало, то я уже не мог выставить таргет -x64-windows-gnu, потому что мингв видимо не тот.

В варианте *-windows-gnu в дистрибутив входит линкер от mingw. Ничего дополнительно ставить не надо. Всё просто работает из коробки. PS: Возможно когда-то давно он туда не входил, не знаю.

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

_>>Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе.
TB>А знаешь что будет если ты таким образом случайно зафигачишь две мутабельные ссылки на один объект?

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

_>>Вот и не стоит засовывать подсчёт ссылок туда, где его не было в C++. Очевидно же, что это означает что в нём нет потребности, а появляется он только от неумения пользоваться другими возможностями языка.
TB>Расскажи, как без Rc сделать архитектуру юник+обычные указатели. Поинтеры из Раста не предлагать.
TB>Ссылки раскидывать внутри графа не получится. Значит, нужен слабый указатель. А он живёт только в паре с Rc, вот так вот

Я пока по описанию не понял твою задачу (непонятно как у тебя там определяются времена жизни). Но уверен что у тебя наблюдается ровно один из двух случаев:
1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.

Какой из вариантов верен можно понять только уже из конкретного кода. Но уверен что один из них верен. )))

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

AD>В варианте *-windows-gnu в дистрибутив входит линкер от mingw. Ничего дополнительно ставить не надо. Всё просто работает из коробки. PS: Возможно когда-то давно он туда не входил, не знаю.

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

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

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

Ну вот ты и попался. Знаешь, что такое УБ?)
Я могу на довольно конкретных примерах показать, что этим правилом пренебрегать никогда нельзя, даже если у тебя однопоток. Даже если у тебя только примитивные типы.
Да, в С++ можно, в Расте нельзя. Есть кой-какой нюанс, который я ещё на первой странице рассказал про генерацию кода для бэкенда.
Кстати, насколько далеко от СПб живёшь?

_>1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
_>2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.

Ну давай, есть граф, его вершины хранятся в юниках, каждая вершина хранит ссылки на другие вершины в виде сырых указателей. Корректна ли эта архитектура? Нет, ведь если мы вытащим юник вершину и грохнем граф, то в вершине будут висячие ссылки. Корректна ли архитектура, если мы запретим вытаскивать вершины и поклянёмся, что вершина будет удаляться только вместе со всеми ведущими на неё ссылками? Да. Можем ли мы это доказать компилятора Раста? Нет, не может.

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

_>>Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))
AD>Писать на расте можно, но код на расте по структуре и идеологии будет похож на код на си. И особо не понятно, зачем в данном случае нужен именно раст. Лично мне в расте пока не хватает некоторых фич, чтобы на него перейти для использования при написании прошивок

Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html), не смотря даже на удобный графический Cube (который кстати всё равно удобно использовать, чтобы накидать схему, но уже без генерации кода). Вот в последнем как раз матёрый C с классами, в то время как в Rust возможно красивое программирование на типах. В C++ оно конечно же тоже возможно, но почему-то все общепринятые библиотеки написаны максимально не так. А в Rust только такие и делают.

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

_>>Далее, стандартное правило компилятора для ссылок (никаких других при наличие одной мутабельной) следует не из какие-то внутренних особенностей языка, а было придумано для помощи в написание корректного кода в тяжёлых внешних условиях (многопоточное программирование и т.п.). Если в твоём коде другая ситуация, то не факт что будет полезным продолжать соблюдать это правило.
TB>Две мутабельные ссылки на один объект это УБ.
TB>Знаешь ли ты, что такое УБ?
TB>Ну вот ты и попался, поздравляю.
TB>Это правило необходимо даже для однопоточного кода.
TB>Более того, ты поимеешь проблемы даже если у тебя будут две мутабельные ссылки на один инт.

Ну давай, расскажи о том какие будут проблемы. )))

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

_>Ну давай, расскажи о том какие будут проблемы. )))

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

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

_>>Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.
TB>Не понял про винапи. Это же всё в дллках, которые с вендой в комплекте. А библиотеки, которые подключают нужную функцию из нужной дллки, они пишутся на самом языке.

Только в C++ нет пакетного менеджера для таких пакетов с библиотеками-заглушкам под ОС АПИ — подразумевается, что они уже лежат в системных путях. Ну и ты же не забыл, что многие Rust библиотеки внутри зависят от C/C++ библиотек и делают их сборку внутри себя?

_>>А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.
TB>Ну под винду выбор либо ставить полтора гигабайта студии, либо трахаться с гнутым тулчейном.

У меня на рабочем компьютере задолго до Rust'а жили и WindowsSDK (студия сама не нужна вообще то) и MinGW. При переходе на Rust я предпочёл вариант с MinGW и ни разу не пожалел об этом.

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

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

Не, я всё равно не понял. Вот я объявил функцию как импортную из системной дллки а каким-то именем. Разве компоновщику что-то нужно знать дополнительно, чтобы скомпилировать екзешник?

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

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

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