А, если ты имеешь в виду то, что refcount хранится в данных ссылаемого объекта а не объекта-ссылки, так это несущественно, учитывая, что конечный информационный объект (строка, число, массив SVшек) ссылается из этого объекта ссылки.
Посмотрел исходники:
Код по работе с SvREFCNT/SvREFCNT_inc/SvREFCNT_dec
Отличие от C++-сных умных указателей (точнее, от машинального их использования) в том, что всё это делается неавтоматически - например количество ссылок на скаляр увеличивается _перед_ поклажей в массив или хэш, а последним вообще пофиг до ссылок на хранимые данные. За счёт этого достигается "переоптимизированность" перла, которая когда-то была очень нужна, а сейчас, с приходом во все скриптовые языки JIT, стала менее актуальной.
GC же - другое. Насколько я понимаю - это когда есть связанный список разных объектов, и специальный тред или функция пробегает по этому списку в моменты нужды и как-то обнаруживает, что на этот объект больше никто живой не ссылается, после чего грохает. И круче это тем что будучи реализованным на уровне объектной модели уменьшает перегрузку процессора от постоянного мониторинга рефкаунта при почти каждом обращении к переменной (даже такой тривиальной, как строка или число).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2008-09-04 07:20 pm (UTC)Посмотрел исходники:
Код по работе с SvREFCNT/SvREFCNT_inc/SvREFCNT_dec
А вот код для контроля:
#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && !defined(PERL_GCC_PEDANTIC)
# define SvREFCNT_dec(sv) \
({ \
SV * const _sv = (SV*)(sv); \
if (_sv) { \
if (SvREFCNT(_sv)) { \
if (--(SvREFCNT(_sv)) == 0) \
Perl_sv_free2(aTHX_ _sv); \
} else { \
sv_free(_sv); \
} \
} \
})
#else
#define SvREFCNT_dec(sv) sv_free((SV*)(sv))
#endif
Отличие от C++-сных умных указателей (точнее, от машинального их использования) в том, что всё это делается неавтоматически - например количество ссылок на скаляр увеличивается _перед_ поклажей в массив или хэш, а последним вообще пофиг до ссылок на хранимые данные. За счёт этого достигается "переоптимизированность" перла, которая когда-то была очень нужна, а сейчас, с приходом во все скриптовые языки JIT, стала менее актуальной.
GC же - другое. Насколько я понимаю - это когда есть связанный список разных объектов, и специальный тред или функция пробегает по этому списку в моменты нужды и как-то обнаруживает, что на этот объект больше никто живой не ссылается, после чего грохает. И круче это тем что будучи реализованным на уровне объектной модели уменьшает перегрузку процессора от постоянного мониторинга рефкаунта при почти каждом обращении к переменной (даже такой тривиальной, как строка или число).