OberonCore

Странное дело, всегда думал, что NEW для безтеговых указателей выдаёт ошибку. Но это не так. Компилится.


Что скажете? Есть ли смысл запретить выделение памяти через NEW для безтеговых указателей?

Логика тут простая. Безтеговые указатели это не Оберон-указатели. Это биндинги, низкий уровень, сторонние библиотеки, которые выделяют себе память сами, поэтому примешивать туда NEW как-то нехорошо и опасно.

Другое дело, если будет NEW(p, 1); pu := p; - тут хотя бы ясно, что безтеговый указатель используется на теговой сущности как низкоуровневый. Но наоборот будет весьма нехорошо.
(pu := p не компилится, ошибка несовместимого присваивания, что правильно)

Лично мне непонятно зачем безтеговый указатель как-то взаимодействует со сборкой мусора. По идее, он вообще неотслеживаемый.

Если будут аргументы за NEW(untagged), указывайте примеры, где бы это было полезно. Я сходу не могу таких придумать.

Компилится, а работает ли?

NEW в ББ динамически настраивается на адрес Kernel.NewRec/NewArr. Они требуют параметром тег типа. У безтегового указателя тега типа нет... Т.е. выполниться это не может.

А, стоп.

POINTER [untagged] TO ARRAY/RECORD - не то же самое, что POINTER TO ARRAY/RECORD [untagged].

POINTER [untagged] - это когда объект сам ББ-шный, а указатель - нетрассируемый сборщиком мусора, не являющийся якорем.

Да вот я тоже так думал, а теперь сомневаюсь. Раз на нём можно NEW делать...

Больше похоже на то, что любой указатель, что тегированный, что безтеговый, не будет трассироваться сборщиком, покуда на нём не сделают NEW. Поэтому в биндингах часто применяются указатели без [untagged]. Меня это смущало, когда я думал, что безтеговость указателя не даёт выделять под него память по NEW. Ну а раз даёт, тогда в чём разница?

Оно же запрещено

Смотри, отец родной - пока ты не сделаешь NEW, конечно, он NIL - сборщик по нему не пойдёт

Безтеговость указателя (POINTER [untagged] TO SomeRec) - это когда сам RECORD ББ-шный, тегированный. Т.е. этот указатель совершенно совместим по присваиванию с POINTER TO SomeRec, с полностью контролируемым указателем.
Просто для POINTER [untagged] поля внутри записи или глоб переменной она не регистрируется в таблице трассируемых указателей - и сборщик вообще не пойдёт по этому указателю, он не станет якорем. Если только такой указатель есть, то объект будет собран (а повисший указатель останется).

А POINTER TO RECORD [untagged] - это когда сама запись динамически выделена не диспетчером памяти ББ, тега типа не имеет, расширяться не может, WITH/IS не поддерживает и т.п.

В биндингах - ошибочно применять без RECORD [untagged] (именно RECORD, а не POINTER)! (только если это не действительно случай передачи во внешнюю либу указателя на ББшный объект, который обычный - и надо к его телу пустить внешнюю либу).
Если в биндинге именно к тебе в ББ, "на приём" приходит не-untagged-указатель, то это крах. Крах для сборщика: он пытается пойти по этому указателю, посмотреть по -4 адрес Kernel.Type-а для него - и всё.
Однако, если такой указатель побыл чисто на стеке - то да, этого никто не заметит. Ибо маркировка стека - консервативная, без разбора метаинформации.

Это всё конечно очень замечательно. Но где возмущения по поводу того, что NEW(untagged) всё-таки компилится?

Вопрос сейчас только про безтеговость указателя. Предлагаю разграничить POINTER и POINTER [untagged] именно по критерию разрешения выделять на нём память по NEW, или нет. Да, если хотите, попробуйте пробить этот вопрос на форуме Центра, а лично я уже устал что-то кому-то доказывать.

Кстати, в ББ безтеговость записи перетекает в безтеговость указателя на неё, то есть, POINTER TO RECORD [untagged] будет эквивалентно POINTER [untagged] TO RECORD [untagged]. Я вижу смысл иметь безтеговые указатели на записи/массивы с тегом (для тех самых низкоуровневых нужд), поэтому разделил бы эти сущности. Чего не делает BlackBox. В тегированных указателях на безтеговые записи/массивы смысла конечно нет. Или есть?

А вот нет. Попробуйте скомпилить код из первого поста темы.

Нуу, операция-то выполнимая.
NEW можно выполнить, если тип самой записи - тегированный, есть дескриптор типа.
Дальше можно поработать с объектом - и выкинуть сразу )
На стеке, например.

Т.е. для специального системного средства дополнительно что-то запрещать - дело десятое.

Это выглядело бы запретом, если бы не было обычных указателей.

Просто сбивает с толку то, что безтеговых указателей в BlackBox'е фактически нет. А судя по принятому стилю описания указателей — они как бы должны быть. И вот я описываю вроде бы безтеговый указатель, но как только над ним стоит сделать NEW — он становится тегированным и отслеживаемым сборщиком, независимо от того, как объявлен. Получается дублирование сущностей POINTER и POINTER [untagged].

У кого-нить есть соображения, почему вообще существует POINTER [untagged], наряду с POINTER TO ARRAY [untagged] и POINTER TO RECORD [untagged] ?

Олег, пожалуйста, перечитай внимательно ещё раз обсуждение.

Когда ты делаешь NEW - то указатель не становится каким-то другим. Просто, т.к. адресуемый тип - тегированный, то разместить такой RECORD в куче можно. И указатель на него кладётся в нетрассируемую переменную. По которой сборщик не ходит и якорем её не считает.

Сбивает с толку, что использована такая же метка [untagged], надо было бы [untraced]. Видимо, сканер учить отдельному токену лень было

Илья, ну смотри. Теговый указатель присваивается только через NEW, ему присвоить произвольный адрес вручную нельзя, так? (вернее, можно, но нельзя — себе дороже). А безтеговому можно — это делают сторонние библиотеки. По крайней мере, я так думал до вчерашнего дня. В моей голове вот это самое POINTER [untagged] именно так и разложилось.

Предлагаю обсудить внедрение сущности "нетрассируемый указатель, на котором нельзя сделать NEW". Пусть будет тег [untraced]. Полностью чужеродный для Оберон-рантайма и защищённый от посягательств сборщика мусора на 100%. Вся инфраструктура для его реализации уже готова, синтаксис устаканен, а семантика просится сама собой.

POINTER TO ARRAY — обычный указатель на тегированный Оберон-массив
POINTER [untraced] TO ARRAY — нетрассируемый указатель на тегированный Оберон-массив
POINTER [untraced] TO ARRAY [untagged] — нетрассируемый указатель на безтеговый массив

P.S. Кстати, сейчас ARRAY [untagged] — безтеговый, но если на этапе компиляции известна длина массива, то эквивалентен теговому.

Илья, а ты в этом точно уверен?

Судя по нашим с SovietPony изысканиям, консервативный сборщик ББ будет считать якорем даже произвольное 32-битное значение из стека, полученное пробегом по стеку с выравниванием на границу 32 бит, если это значение (будь оно куском данных массива/записи или куском значения LONGINT) случайно совпадёт с адресом выделенного блока.

Верно, сборщик засчитает такое значение из стека.


Верно, что если в куче структура с untagged указателями, то по ним сборщик не ходит.

Думаю, эту возможность кто-то придумал для использования как weak pointers. Да не доделал, т.к. как только мы говорим untagged, теряем управление целостностью указателей.

Так это POINTER TO RECORD [untagged].

А POINTER [untagged] TO RECORD - это вот то, что сказал Дмитрий Викторович! ) Делали, не доделали - ещё и на ключевом слове сэкономили ))