Обновить
82
-0.1
Даниил Тутубалин@DandyDan

Пользователь

Отправить сообщение

По крайней мере, эти генераторы текста умеют расставлять знаки препинания в отличие от...

Только ускорение направлено, как и положено, в сторону центра масс.

Структуру S мы можем создать только одним способом
А потом добавляем метод, который иногда нарушает инвариант...

Ладно, про +1 ошибся ) Отредактировать уже нельзя, пусть мой позор вечно тут хранится.

В UAE особенно зелени много. И закаты такие красивые - в облачка. Воздух чистый, свежий, никакой пыли. Летом вообще красота.

Так любой перевод - это звено какой-то цепи. И если в этой цепи где-то найдётся кто-то не тот...

Тут главный вопрос звучит так: каким образом госорганы соответствующей страны могут узнать о том, что у вас где-то там остался в загашнике незакрытый счет?

Не знаю, как сейчас, раньше при оформлении турвизы нужно было предоставить выписку из банка. Ну и, наверняка, эти данные где-то запоминаются. А потом заезжаешь уже не как тур - и вуаля.

Если алгоритм написан правильно, то абсолютно без разницы, сколько внутри unsafe.

Так я о том же говорил: зачем нужны эти пляски с бубном, если можно просто взять и хорошо написать на С?

И ваш код через сырые указатели только подтверждает, что borrow checker нафиг не нужен, только мешает.

Кстати, алгоритм у вас неправильный - tail никогда не обновляется ;)
И, думаю, компилятор к этому никаких претензий не имеет ;)

Да и сделать +1 ко всем элементам списка не выйдет - значение иммутабельное:

struct LinkedListNode<T> {
    data: T,
    ...
}

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

Конечно же код вы не предоставите, сославшись на какие-нибудь отговорки, хотя реальная причина проста - Rust на это не способен.

P.S.
Просто на всякий случай: вот такое - это не safe API.
Это сокрытие проблем от компилятора и разработчиков.

fn that_is_safe_i_guarantee(...):
   // SAFETY: постарайтесь не передавать аргументы, 
   // которые могут всё сломать
   unsafe { ... }

Можно. Я выше даже написал рецепт.

  1. Пишем unsafe код.

  2. Оборачиваем его в runtime проверки.

  3. Пишем в первой главе руководства, что всё за нас делает компилятор без оверхеда.

  4. ???

  5. PROFIT!

Сам по себе Weak не решает проблему

fn borrow_mut(&mut self) -> &mut T

Для получения ссылки на мутабельные данные нужна мутабельная ссылка на Weak. Чтобы получить мутабельную ссылку на Weak, нужна мутабельная ссылка на ту структуру, которая содержит Weak (нод списка в нашем случае). А так как список двусвязный, нужны две мутабельные ссылки, а это запрещено. Поэтому без RefCell и внутренней мутабельности не обойтись.

Вы отрицаете что у нее можно сделать безопасное API?

Если небезопасное так легко превращается в безопасное, то зачем вообще тогда нужен Rust? Просто пишем на Си и делаем безопасное API.

P.S. Поиронизирую.
"Безопасное API" в переводе с растовского означает "API, которое запрещает вам его использовать для реальных задач. Если хотите чего-то добиться, работайте с ним через unsafe на свой страх и риск".

Без runtime проверок? Отрицаю.

Обе гипотезы подтвердились: Rust на это не способен, и вы так себе разработчик ;)

Хорошо, а деревья приходилось использовать? Просто скажите, что деревья тоже никому не нужны, и мы закончим этот разговор.

Гипотеза: на Rust без использования unsafe (явного или завёрнутого) и без использования runtime проверок невозможно решить задачу из школьного учебника:

Реализуйте функцию, которая проходит по двусвязному списку целых чисел и увеличивает каждое число на 1.

Приведите контр-пример, если вы вообще в принципе умеете в Rust, а не просто менеджер, который где-то начитался хвалебных статеек.

Риторические приёмы и уровень фанатизма всё больше напоминает "в линуксе нет вирусов" ;)

У сишечек хотя бы никто не врёт про якобы безопасность, поэтому всегда нужно быть начеку. Раст же, не предоставляя никаких гарантий кроме кучи препятствий при написании элементарного кода, громко заявляет о своей безопасности, усыпляя бдительность.

Вот это гарантии безопасности!

Как отличить, кто из них safe, а кто unsafe?
Функция не помечена как unsafe.
Опции у cargo install, запрещающей устанавливать "небезопасные" крейты, тоже не вижу.

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

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность