Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Принципы » Проверяние ссылок(borrow checking), 6.5 лет отставания от Rust-2010-06


Проверяние ссылок(borrow checking), 6.5 лет отставания от Rust-2010-06

Сообщений 1 страница 4 из 4

1

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

Если объект передаётся в функцию при помощи borrow (&) (то есть как как параметр "по ссылке"), то в конце функции такой объект не удаляется.

immutable borrow: Объекты переданные по ссылке менять нельзя внутри функции (потому что ссылка имеет свойство неизменяемости (immutable))
mutable borrow: Бывают и &mut ссылки - это указатели. То есть, объект всё равно не удаляется внутри функции, но его можно менять.
any borrow must last for a scope no greater than that of the owner.
In Rust, borrowing is tied to the scope that the borrow is valid for.

you may have one or the other of these two kinds of borrows, but not both at the same time:
-  one or more references (&T) to a resource,
-  exactly one mutable reference (&mut T).

А если объект передаётся в функцию без borrow (как бы "по значению", но тут другие термины используются, с другими смыслами), то после функции его уже нельзя использовать в вызывающей программе.

cannot borrow `x` as immutable because it is also borrowed as mutable
the mutable borrow prevents subsequent moves, borrows, or modification of `x` until the borrow ends

чтобы понять как это, надо прочитать три страницы:
https://doc.rust-lang.org/book/ownership.html
https://doc.rust-lang.org/book/referenc … owing.html
https://doc.rust-lang.org/book/lifetimes.html

Поскольку русские языки с кучей не работают (я Кумир имею в виду), то и проблем с передачей параметров в функции у них нет. Пора это дорабатывать.

2

Лис
Вам бы Вирта почитать. Он про это тоже писал ещё в том веке.

Тут как бы 3 вопроса.
1) Автоматическое удаление мусора.
2) Как не дать выстрелить себе в ногу.
3) Соглашение о вызовах функций (ABI).

Самое простое соглашение это всё передавать через ссылку.
Но это чревато косяками и упсами. Поэтому надо ввести классификацию чего можно делать чего нельзя.

Мне нравится Виртовский подход параметры делятся на 3 вида
образцовые, переменные, постоянные.
образцовые параметры это те которые в паскале идут без служебных слов var и const.

А ссылки это или передача значение определяет вид параметра.

Но я бы подумал отом что-бы отказаться от указателей как в Си# или покруче.

3

Павиа написал(а):

Лис
Вам бы Вирта почитать.

Я так не думаю. А вот то, что Вы невежливо указываете что делать, это я вижу.

4

Поскольку Кантор начал разрабатываться всего на год позже Rust (2006-2007), по концепциям никакого отставания нет. Отставание по деньгам -- на 10 лет. Результат пропорционален финансированию. :(

Начиная разрабатывать Кантор, я придерживался гипотезы так называемого "графа доступности", но не был уверен в его реализуемости. За прошедшее время стало понятно, что всё реализуемо, ибо работает в реализации COM-интерфейсов в Delphi. Еще я переоткрыл систему передачи параметров Ады, как выяснилось позже. Логично, ибо в своих размышлениях я ориентировался на PL/SQL, который адаптация Ады под Oracle.

Короче, получилось как в Rust, но проще. Если тема найдет отклик, попробую расписать тут или у себя на ресурсе.


Вы здесь » Ремесло программиста » Принципы » Проверяние ссылок(borrow checking), 6.5 лет отставания от Rust-2010-06