Читаю статьи про это не догоняю - неужели в каждом интерпритаторе есть глобальный массив с количеством ссылок на каждую переменную ? И как он определяет где какая переменная в этом массиве особенно если переменная в параметрах функции?
Глобальный массив - нехорошее решение. Обычно счётчик ссылок инкапсулируется в сам объект. Когда количество ссылок на объект уменьшается - это триггер для GC, чтобы проверить связность объекта с другими. Современные GC вынуждены анализировать графы объектов, так как просто уменьшение счётчика ссылок и сверка его с нулём не есть гарантия стабильной очистки мусора, так как имеют место быть структуры с циклическими ссылками, образующие петли: 1. Объект A ссылается на объект B 2. Объект B ссылается на объект C 3. Объект C ссылается на объект A Задача хорошего GC - обнаруживать такие петли.
в нормальном, да... есть реализации, которые используют чистый RC (reference counting), с каждым объектом ассоциируется целое число ссылок на него, когда это целое число равно нулю, то объект просто удаляется, но такая реализация хоть и проще анализа графов, но не способна выявлять циклические ссылки... вроде в Squirrel чистый RC... есть реализации конкатинирующих языков, которые работают исключительно только со стеком ВМ, то есть объекты существуют только на стеке и дублируются, если это надо, что исключает циклические ссылки, но серьезно влияет на производительность и расходы по памяти... смотрите всякие Forth'ы для этого...
но как тогда обойти все обьекты и выявить нулевое значение ссылок? как я понимаю должен быть глобальный массив или список ... а можно пример кода чтобы интерпритатор так запутался (как я понимаю можно ограничится ссылками на объекты а ссылку на ссылку при создании заменить на ссылку на объект)
Ну на самом деле структуры могут быть посложнее, оптимизированные под параллельную работу в несколько потоков. Так я же привёл пример с ссылкой объектов друг на друга по кругу.
Генерация мусора понятие определённое. Это нужно что бы обмануть аверский детектор. Довольно эффективный метод, даже можно сказать что годный. SadKo, > Обычно счётчик ссылок инкапсулируется в сам объект. Дайте определение ссылке". Даже я в этом не то что путаюсь, не понимаю сути термина. "Указатель на указатель" или это понятие чисто скрипта ?
Понятие ссылки было введено в С++. Чисто для удобства, в классическом си нет никаких ссылок. Вот простой пример для понимания, есть у вас функция: Code (Text): void summa (int a,int b, int *summ) { *summ=a+b; return; } Это запись в классическом си, int *summ это указатель на int в памяти. Но разработчикам С++ такая запись показалась неудобным, в основном это связано с ООП, хорошо-бы работать с объектами, как по имени. Поясню примером, та-же запись, но уже в С++: Code (Text): void summa (int a,int b, int &summ) { summ=a+b; return; } int &summ - Это уже ссылка, как видите summ=a+b вам не нужно разыменовывать указатель, более того вы можете вызвать потом функцию так: int a=5; int b=5; int summ=0; summa (a,b, summ); И всё будет работать в С++ Другое дело, как в классическом си нужно вызывать уже так: summa (a,b, &summ); Так-что ссылка это всего-лишь навороты языка. В классическом си используют в основном для работы с многомерными массивами. Либо когда в функцию нужно передать указатель и поменять этот указатель, а потом вернуть его из функции. Вообще работа с указателями одна из самых сложных тем в си, понимание приходит только с практикой.
Понятие ссылки для каждого языка своё. В С++ - это указатель на объект, который лишён арифметики указателей. В современных языках с GC ссылка на объект - это средство для определения местонахождения объекта в памяти (в целях оптимизации совпадает с адресом объекта), совместно реализующий ещё целый ряд задач по определению, является ли объект, на который ссылаются, мусорным или нет. В Java люая валидная ссылка, в том числе, может выступать как объект синхронизации.
SadKo, Вся суть в том, что это понятие нельзя применить на низком уровне. Оно существует пока апп не собрали, те в пределах компилера.
На низком уровне, разумеется, проц ничего не знает про ссылки. У проца есть только одно понятие - адрес расположения чего-то там в памяти. Однако практика показывает, что операция такими адресами далеко небезопасна, т.к. есть высокая вероятность отстрелить себе ногу и испортить данные. Ссылки, по сути, получается, ещё выполняет конвенциальную роль - как данными можно манипулировать, а как - нет. Но это всё, разумеется, касается ссылок для нормальных объектно-ориентированных языков, а не C++.
объекты могут ссылаться друг на друга как в связанном списке или в в виде графа/дерева и инкапсулировать указатели внутри себя, тогда достаточно одной ссылки/указателя на первый/корневой элемент списка/дерева...
Объекты с нулевым значением удаляют, а не обходят. Ссылки ввели до C++. Это деталь реализации. В С++ ссылка — это ещё одно имя объекта. (http://eel.is/c++draft/dcl.ref#1.note-1: [ Note: A reference can be thought of as a name of an object. — end note])
Обьяснение более чем достаточное. Данный термин использовать не следует, я так и думал. Как работает скрипт - особо значения не имеет
пример какие будут ссылки понятен, а вот что может привести к такому? пожалуйста приведи пример программы которая так может запутать
при программировании графических приложений виджеты вкладываются друг в друга сохраняя в себе ссылку на родительский виджет, если виджет в глубине дерева виджетов получает и хранит у себя ссылку на родителя на одну или несколько ступеней выше - получаете вполне себе циклическую ссылку...
Кольцевой буфер, построенный по принципу двунаправленного списка, где каждая запись ссылается на следующую и предыдущую, то есть, в буфере нет последнего и первого элемента.