Safe Objective Language

[Berserker]

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

[vlad]

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

Что такое взвешенные счетчики ссылок?

P.S. Кстати, публикация за 2008 год. Я так понимаю с тех пор оно никуда не двинулось?

[Peter Almazov]

http://kolmck.net/sf/SOL2010.htm

[vlad]

http://kolmck.net/sf/SOL2010.htm

Пошел по ссылкам и случайно зацепил вот этот шедевр:

Для каждого типа объекта в памяти статически (на этапе компиляции) создается объект-заглушка данного типа. Все его числовые поля всегда имеют значение 0, все его указатели всегда имеют значение NONE (т.е. ссылаются на заглушки соответствующих типов), все его виртуальные методы ссылаются на заглушки, которые не выполняют никаких действий и просто возвращаются, в случае функций возвращают 0 или NONE. При попытках чтения данных по указателю проверка указателя на равенство NONE может не делаться, обязательная проверка делается только при записи значений в поля объекта, при этом опять же исключения не возникают, просто игнорируются попытки записи в поля объекта, и они продолжают сохранять свои "нулевые" значения.

Закопать.

[Berserker]

при этом опять же исключения не возникают, просто игнорируются попытки записи в поля объекта

Интересен механизм такого игнорирования при записи.

[valexey_u]

http://kolmck.net/sf/SOL2010.htm

Пошел по ссылкам и случайно зацепил вот этот шедевр:

Для каждого типа объекта в памяти статически (на этапе компиляции) создается объект-заглушка данного типа. Все его числовые поля всегда имеют значение 0, все его указатели всегда имеют значение NONE (т.е. ссылаются на заглушки соответствующих типов), все его виртуальные методы ссылаются на заглушки, которые не выполняют никаких действий и просто возвращаются, в случае функций возвращают 0 или NONE. При попытках чтения данных по указателю проверка указателя на равенство NONE может не делаться, обязательная проверка делается только при записи значений в поля объекта, при этом опять же исключения не возникают, просто игнорируются попытки записи в поля объекта, и они продолжают сохранять свои "нулевые" значения.

Закопать.

Откопать. Во многих случаях это хорошая практика. Собственно скажем в мире java это вполне распространенное явление - вместо null'a используют вот такие вот заглушки (для каждого класса формируется такой вот объект). Ибо для ряда задач лучше если скажем в формочке вместо правильного текста выведется заглушка (пустой текст, или спец. текст), чем случится "assert" (null pointer exception) и программа сложится.

Кроме того, в ObjC nil как раз и является такой вот заглушкой.

[Berserker]

vlad,

Weighted reference counting

In weighted reference counting, we assign each reference a weight, and each object tracks not the number of references referring to it, but the total weight of the references referring to it. The initial reference to a newly-created object has a large weight, such as 216. Whenever this reference is copied, half of the weight goes to the new reference, and half of the weight stays with the old reference. Because the total weight does not change, the object's reference count does not need to be updated.

Destroying a reference decrements the total weight by the weight of that reference. When the total weight becomes zero, all references have been destroyed. If an attempt is made to copy a reference with a weight of 1, we have to "get more weight" by adding to the total weight and then adding this new weight to our reference, and then split it.

The property of not needing to access a reference count when a reference is copied is particularly helpful when the object's reference count is expensive to access, for example because it is in another process, on disk, or even across a network. It can also help increase concurrency by avoiding many threads locking a reference count to increase it. Thus, weighted reference counting is most useful in parallel, multiprocess, database, or distributed applications.

The primary problem with simple weighted reference counting is that destroying a reference still requires accessing the reference count, and if many references are destroyed this can cause the same bottlenecks we seek to avoid. Some adaptations of weighted reference counting seek to avoid this by attempting to give weight back from a dying reference to one which is still active.

Weighted reference counting was independently devised by Bevan, in the paper Distributed garbage collection using reference counting, and Watson, in the paper An efficient garbage collection scheme for parallel computer architectures, both in 1987.

[ilovb]

...
Закопать.

Откопать.
...

Вандалы   

[vlad]

Откопать. Во многих случаях это хорошая практика.

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

И я знаю, что такой подход "маскировать ошибку и до последнего оттягивать конец" имеет своих последователей. А самый типичный представитель ЯП, пропагандирующий такой подход - жабаскрипт. Но лично мне такой подход претит и мешает создавать эти самые надежные программы. Может это чисто психологическое, но тем не менее. Я не могу понять, как можно сопровождать такой код, не "генерируя кучу кирпичей" (с) твой:

Код: [Выделить]

obj.property = 123;
assert(obj.property == 456); // Ха-ха! obj.property - read-only и запись в нее _молча_ _игнорируется_


[valexey_u]

Откопать. Во многих случаях это хорошая практика.

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

И я знаю, что такой подход "маскировать ошибку и до последнего оттягивать конец" имеет своих последователей. А самый типичный представитель ЯП, пропагандирующий такой подход - жабаскрипт. Но лично мне такой подход претит и мешает создавать эти самые надежные программы. Может это чисто психологическое, но тем не менее. Я не могу понять, как можно сопровождать такой код, не "генерируя кучу кирпичей" (с) твой:

Код: [Выделить]

obj.property = 123;
assert(obj.property == 456); // Ха-ха! obj.property - read-only и запись в нее _молча_ _игнорируется_


Это ж не тот случай. тут у тебя obj явно не NONE, и все запишется как надо. Либо будет исключение.

Какой дефолт выбрать (NONE или NULL) - зависит на самом деле от задачи. В некоторых случаях предпочтительней одно, в некоторых другое. Единственное что всегда плохо - неопределенное поведение (UB) по умолчанию.

[vlad]

Weighted reference counting

Спасибо. Может еще кофе не дошло, но я все равно не понял как:
- разруливаются циклические ссылки
- удается избежать доступа к счетчику при копировании ссылок (в том числе доступа на запись) в многопоточной/процессной среде.

[vlad]

Код: [Выделить]

obj.property = 123;
assert(obj.property == 456); // Ха-ха! obj.property - read-only и запись в нее _молча_ _игнорируется_


Это ж не тот случай. тут у тебя obj явно не NONE, и все запишется как надо. Либо будет исключение.

В смысле? Представь, что я этот obj честно получил через третьи руки.

Какой дефолт выбрать (NONE или NULL) - зависит на самом деле от задачи. В некоторых случаях предпочтительней одно, в некоторых другое.

Да-да. Узнаю жабаскрипт: null, undefined, NaN... Закопать без права выкапывать

[valexey_u]

Код: [Выделить]

obj.property = 123;
assert(obj.property == 456); // Ха-ха! obj.property - read-only и запись в нее _молча_ _игнорируется_


Это ж не тот случай. тут у тебя obj явно не NONE, и все запишется как надо. Либо будет исключение.

В смысле? Представь, что я этот obj честно получил через третьи руки.

И что от этого поменяется? У тебя тут ВСЕГДА сработает  assert, просто потому, что поля заглушки не могут иметь такое значение.

[valexey_u]

Да, если хочется падение (или исключение какое) ну воткни ты assert(obj!=NONE) и все. В этом случае одна проверка заменяется другой. Система симметрична.

А вот множество undefined и прочую дрянь следует искоренить :-) (NaN - оставить. Он математически кошерен (плавающая точка, да)). Равно как и искоренить ub у null'а в сях. Это ж не дело, когда оно долгое время с нулями как-то пашет, а потом внезапно на том же обращении к нулю падает.

[vlad]

И что от этого поменяется? У тебя тут ВСЕГДА сработает  assert, просто потому, что поля заглушки не могут иметь такое значение.

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

P.S. Я понимаю, что такую херотень можно на том же С++ написать, не изобретая нового ЯП. Но там, во-первых, для этого надо приложить определенные усилия. А во-вторых, написавшему такое делается внушение и он такое больше не пишет. Кстати, можно посоветовать аффтору поглубже изучить/пописать на С++. Чтоб таких странных идей поубавилось.

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