Oberon space
General Category => Общий раздел => Тема начата: Freeman от Январь 24, 2013, 12:15:32 pm
-
Есть гипотеза, что для автоматического управления памятью можно обойтись без сборщика мусора -- подсчетом ссылок, если в системе наряду с объектами существуют обычные переменные с тремя видами доступа -- in, out и var.
Мысль заключается в том, что в системе со сборщиком мусора именно он выступает фактическим владельцем всех объектов, являясь чем-то вроде бога для ходящих под себя грешных программ (процедур). А в системе с тремя типами доступа -- своего рода "вольтеровская демократия" -- "свобода вашего кулака кончается у моего носа", -- не требующая вмешательства бога.
Разграничение out и var дает возможность передавать владение, и все ссылки в конце концов упираются в переменные, -- локальные либо глобальные. Циклических ссылок при этом не возникает, поскольку эпилог процедуры отличает владеющие ссылки от невладеющих и финализирует только владеющие, -- в рамках своей ответственности.
Покритикуйте, пожалуйста.
-
Есть гипотеза, что для автоматического управления памятью можно обойтись без сборщика мусора -- подсчетом ссылок, если в системе наряду с объектами существуют обычные переменные с тремя видами доступа -- in, out и var.
Мысль заключается в том, что в системе со сборщиком мусора именно он выступает фактическим владельцем всех объектов, являясь чем-то вроде бога для ходящих под себя грешных программ (процедур). А в системе с тремя типами доступа -- своего рода "вольтеровская демократия" -- "свобода вашего кулака кончается у моего носа", -- не требующая вмешательства бога.
Разграничение out и var дает возможность передавать владение, и все ссылки в конце концов упираются в переменные, -- локальные либо глобальные. Циклических ссылок при этом не возникает, поскольку эпилог процедуры отличает владеющие ссылки от невладеющих и финализирует только владеющие, -- в рамках своей ответственности.
Покритикуйте, пожалуйста.
Критикую: как в такой системе сделать двусвязный список?
-
У подсчёта ссылок проблема в циклических ссылках -- поэтому GC лучше, чем подсчёт ссылок.
С другой стороны, есть способы управления памяти методом регионов памяти
http://en.wikipedia.org/wiki/Region-based_memory_management
В нём смысл такой -- создаётся некий регион памяти, содержащийся в нём мусор будет уничтожен одним махом когда область действия выходит за область видимости региона...
-
Критикую: как в такой системе сделать двусвязный список?
И де же тут критика? о_О
-
Критикую: как в такой системе сделать двусвязный список?
И де же тут критика? о_О
Критика в том, что двусвязный список создает циклические ссылки, а язык без возможности создания двусвязного списка, не нужен.
-
Критикую: как в такой системе сделать двусвязный список?
И де же тут критика? о_О
Критика в том, что двусвязный список создает циклические ссылки, а язык без возможности создания двусвязного списка, не нужен.
А вдруг он щас как выкатит рабочую реализацию двусвязного списка, сделанного с учётом перечисленных им ограничений? ))
-
А вдруг он щас как выкатит рабочую реализацию двусвязного списка, сделанного с учётом перечисленных им ограничений? ))
Это было бы очень хорошо.
-
Описание какое-то сумбурное. Имеется три абзаца, но ни одного я не понял: слишком много явных или косвенных отсылок вовне. Можно ли какими-нибудь другими словами объяснить? Без подробностей - для меня достаточно понять хотя бы идею.
-
Есть гипотеза, что для автоматического управления памятью можно обойтись без сборщика мусора -- подсчетом ссылок, если в системе наряду с объектами существуют обычные переменные с тремя видами доступа -- in, out и var.
Что понимается под " объектами"?
-
Критикую: как в такой системе сделать двусвязный список?
И де же тут критика? о_О
Geniepro - попали в воздух... это не критика, если рассматривать последний, как контейнер со скрытой реализацией но определенным интерфейсом доступа, насрав к тому же на производительность кода то хватит и односвязанного..
-
Покритикуйте, пожалуйста.
Это все есть в С++ (передача владения и подсчет ссылок) и это никак не помогает от циклических ссылок.
Лично мне было бы интересно решить проблему хотя бы с передачей владения. А именно - избавиться от ошибок обращения к переменной, которая уже передала владение.
-
Покритикуйте, пожалуйста.
Это все есть в С++ (передача владения и подсчет ссылок) и это никак не помогает от циклических ссылок.
Лично мне было бы интересно решить проблему хотя бы с передачей владения. А именно - избавиться от ошибок обращения к переменной, которая уже передала владение.
Ответ на это прост: Rust.
http://sysdev.me/rust-memory-model/
http://rsdn.ru/forum/philosophy/5016733.flat#5016733
Rust в случае owned box указателя (уникального указателя) проверяет владение на этапе компиляции. После y = x, x становится не доступен (x,y - указатели)
-
Ответ на это прост: Rust.
Гхм. А как он такое разруливает:
if (x) // значение x неизвестно на этапе компиляции
move(y);
move(y); // ?
-
Ответ на это прост: Rust.
Гхм. А как он такое разруливает:
if (x) // значение x неизвестно на этапе компиляции
move(y);
move(y); // ?
Посмотри простыню на rsdn - там обсуждалось. Вроде бы будет ошибка компиляции.
-
Гхм. А как он такое разруливает:
if (x) // значение x неизвестно на этапе компиляции
move(y);
move(y); // ?
Посмотри простыню на rsdn - там обсуждалось. Вроде бы будет ошибка компиляции.
И таки да. Проверил.
За такое:
fn main() {
let x = ~10;
if (rand::random()>0) {
let y = x;
io::println(y.to_str());
}
let z = x;
io::println(z.to_str());
}
Вот так меня компилятор обругал:
hello.rs:9:12: 9:13 error: use of moved variable: `x`
hello.rs:9 let z = x;
^
hello.rs:6:16: 6:17 note: move of variable occurred here
hello.rs:6 let y = x;
^
error: aborting due to previous error
-
Вот так меня компилятор обругал:
Ну хорошо. А чего делать-то? Как проверить, что она не была мувнута и мувнуть?
-
Вот так меня компилятор обругал:
Ну хорошо. А чего делать-то? Как проверить, что она не была мувнута и мувнуть?
Ты учти пожалуйста, что это не единственный тип указателей в Rust'e.
Ну и придумай какой-нибудь юзкейс более-менее реалистичный, чтобы на примере можно было поиграться с этими указателями.
-
Критика в том, что двусвязный список создает циклические ссылки, а язык без возможности создания двусвязного списка, не нужен.
Да, хорошая задача. Подумаю. Вызов принят, как говорится. :)
-
Ну и придумай какой-нибудь юзкейс более-менее реалистичный, чтобы на примере можно было поиграться с этими указателями.
Просто должен быть механизм "восстановления" типа до "немувнутого". Типа:
if (movable)
// здесь movable опять можно использовать
else
// а здесь нельзя - ошибка компиляции
Что-то другое трудно придумать.
-
Ну и придумай какой-нибудь юзкейс более-менее реалистичный, чтобы на примере можно было поиграться с этими указателями.
Просто должен быть механизм "восстановления" типа до "немувнутого". Типа:
if (movable)
// здесь movable опять можно использовать
else
// а здесь нельзя - ошибка компиляции
Что-то другое трудно придумать.
Все оказалось проще. Вот такая модификация того моего кода отлично работает:
fn main() {
let x = ~10;
if (rand::random()>0) {
let y = x;
io::println(y.to_str());
} else {
let z = x;
io::println(z.to_str());
}
}
-
Да, а еще в Rust'e принципиально нет null'я или там nil'а какого, ни их аналогов :-)