Автор Тема: Минимальная поддержка "умных указателей"  (Прочитано 12584 раз)

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Допустим я реализовал свою "строку". Это структура внутри которой лежит целое число -- как бы "умный указатель". Через это число некий ресурс (в данном случае память под буквы) может быть получен/использован/освобождён.

public struct UnmanagedString
{
    private uint handle;
}

Работать с переменными типа UnmanagedString нужно по особой дисциплине: обычная инструкция копирования "=" для структуры UnmanagedString неприемлема. Для копирования нужно использовать не "=", а специальную процедуру.

Эта специальная процедура в данном случае либо выполнит копирование букв в другой участок памяти и вернёт другой handle, либо, что более оптимально, увеличит количество ссылок на существующую строку. В общем случае эта специальная процедура может сделать чёго-то более трудоёмкое.

Так вот. Возникает вопрос. Что надо минимально потребовать от языка программирования, чтобы программирование "умных указателей" не походило на организацию восхода Солнца вручную. Понятно, что в С++ это сделано далеко не минимально.

Можно было бы потребовать следующее: в языке добавить атрибут структуры означающий, что она некопируемая, а компилятору для таких структур проверять, что для переменных её типа нигде не использована инструкция "=" и они не переданы ни в какую процедуру по значению (только по ссылке). Соответственно, структуры и массивы содержащие некопируемые поля тоже должны быть маркированы атрибутом запрещающим копирование. Это можно было бы сделать, но можно сделать и наоборот...

В последней редакции Оберона-07 вообще никакие структуры не могут быть переданы в процедуру по значению, а только по ссылке. То есть Оберон-07 уже полшага к "умным указателям" сделал. Если действовать в духе Оберона, то лучше будет вообще запретить инструкцию копирования ":=" для любых составных типов. Это дёшево и сердито. Разрешаем применять ":=" только для базовых типов и всё. Копирование объектов составных типов пишем ручками через копирование полей (компилятор легко может это потом соптимизировать, если захочет, так что в рантайме оверхеда не будет).

Оптимум где-то по-середине. Некоторым составным типам копирование всё таки было бы полезно.

Короче, вопрос в следующем. Что разрешить для составных типов по умолчанию: копирование разрешено или запрещено? Если подумать, то очевидно по умолчанию копирование объектов составных типов должно быть запрещено, а разрешать применять к ним инструкцию ":=" программист должен явно (это в каком-то смысле всего лишь оптимизация).

DIzer

  • Гость
Re: Минимальная поддержка "умных указателей"
« Ответ #1 : Март 22, 2012, 10:55:03 am »
Не есть гуд -ссылка это ссылка... иногда они создают дополнительный геморрои.. впрочем может ввести аналогично эйфелю  - expanded (развернутые) типы?

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Минимальная поддержка "умных указателей"
« Ответ #2 : Март 22, 2012, 11:53:40 am »
А разьве expanded не тоже самое что и value? Засунули структуру внутрь объекта и всё.

Для строк это не годится - у них длина переменная.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #3 : Март 22, 2012, 07:34:33 pm »
Короче, вопрос в следующем. Что разрешить для составных типов по умолчанию: копирование разрешено или запрещено? Если подумать, то очевидно по умолчанию копирование объектов составных типов должно быть запрещено, а разрешать применять к ним инструкцию ":=" программист должен явно (это в каком-то смысле всего лишь оптимизация).

Запрет копирования структур - это такой страшный сон. Наказание за плохое написание циклов :)

На самом деле тебе нужен конструктор и константные мемберы. Это если подходить со стороны "минимизации". Константный мембер "защитит" от дефолтового копирования. Конструктор обеспечит правильную инициализацию этого мембера (через вызов специальной в твоем случае функции копирования). Да, конструктор подразумевает наличие семантики инициализации переменной (этого нет в обероне).

P.S. Хотя все равно не очень понятно как это будет нормально работать без деструкторов. Это неотъемлемая часть "умных указателей" и именно с деструкторами все непросто.

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Минимальная поддержка "умных указателей"
« Ответ #4 : Март 23, 2012, 02:43:35 pm »
P.S. Хотя все равно не очень понятно как это будет нормально работать без деструкторов. Это неотъемлемая часть "умных указателей" и именно с деструкторами все непросто.
Вот именно. И именно запретом по умолчанию оператора ":=" (в добавок к тому что и так есть в последней редакции Оберона 07) мне видится можно убить большое количество зайцев. Если нет неконтролируемого копирования, значит нет неконтролируемых копий, значит надобность в неявном вызове деструкторов отпадает. А в тех местах где явно/врукопашную скопировал, там же явно/врукопашную и вызвал для этой копии деструктор.

Можно сделать немного по-другому. Например, так: в родном модуле, в котором структура объявлена, для неё оператор ":=" разрешён, а в остальных модулях по умолчанию запрещён.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #5 : Март 23, 2012, 05:23:23 pm »
Можно сделать немного по-другому. Например, так: в родном модуле, в котором структура объявлена, для неё оператор ":=" разрешён, а в остальных модулях по умолчанию запрещён.

Запрет на копирование мне кажется чересчур жестоким, без смайликов. При этом особого профита все равно не видно - компилятор ничего не контролирует, все делаем ручками.

Мне кажется, что от идеи деструкторов в традиционном ЯП все равно никуда не уйти и она должна быть представлена хоть в каком-то виде. Не надо делать кальку с C++. Пойти непосредственно от идеи: контролируемая (автоматически) инициализация/деинициализация. Контролируемая не только в скопе, но и явная передача контроля вверх/вниз по стеку - это покроет 90% случаев, когда хочется полуавтоматического контроля за ресурсами. И для реализации этой идеи не надо всех тех наворотов, которые есть в С++ (конструкторы копирования, операторы присваивания и т.д.).

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Минимальная поддержка "умных указателей"
« Ответ #6 : Март 24, 2012, 02:42:12 pm »
Пойти непосредственно от идеи: контролируемая (автоматически) инициализация/деинициализация. Контролируемая не только в скопе, но и явная передача контроля вверх/вниз по стеку - это покроет 90% случаев, когда хочется полуавтоматического контроля за ресурсами.
Я не понял о чём ты.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #7 : Март 24, 2012, 03:20:59 pm »
Я не понял о чём ты.

Забей :) Когда будет у меня нормальный пропозал - напишу сюда.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #8 : Март 26, 2012, 02:15:29 pm »
Я тут ковыряю Go (может в принципе по работе пригодиться), возможно вот это будет тут в тему: http://golang.org/doc/go_spec.html#Defer_statements
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #9 : Март 26, 2012, 03:23:17 pm »
Я тут ковыряю Go (может в принципе по работе пригодиться), возможно вот это будет тут в тему: http://golang.org/doc/go_spec.html#Defer_statements

Ну да, это один из возможных "минимальных" подходов. Очень минимальных. Как я понял - он не реюзается. И его нельзя мувать вверх/вниз по стэку.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #10 : Март 26, 2012, 03:31:20 pm »
Я тут ковыряю Go (может в принципе по работе пригодиться), возможно вот это будет тут в тему: http://golang.org/doc/go_spec.html#Defer_statements

Ну да, это один из возможных "минимальных" подходов. Очень минимальных. Как я понял - он не реюзается. И его нельзя мувать вверх/вниз по стэку.
Вроде бы да, нельзя. А зачем тебе перетасовывать стек?

PS. Если бы подобное было бы в симбиане… Быть может он и не сдох бы. Ибо это сняло бы процентов 60 того BDSM'a c которым приходилось иметь дело разработчику.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #11 : Март 26, 2012, 03:43:22 pm »
Вроде бы да, нельзя. А зачем тебе перетасовывать стек?

В смысле я хочу вернуть такую штуку из функции. Или передать в функцию. И чтоб оно сделало свою работу (финализирующую) автоматически, гарантировано, и без отвлекания внимания.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #12 : Март 26, 2012, 03:53:43 pm »
Вроде бы да, нельзя. А зачем тебе перетасовывать стек?

В смысле я хочу вернуть такую штуку из функции. Или передать в функцию. И чтоб оно сделало свою работу (финализирующую) автоматически, гарантировано, и без отвлекания внимания.

ну, это ж statement а не expression. shared_ptr через это не сделать. а вот scoped_ptr - легко.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Минимальная поддержка "умных указателей"
« Ответ #13 : Март 26, 2012, 04:37:28 pm »
Я тут ковыряю Go (может в принципе по работе пригодиться), возможно вот это будет тут в тему: http://golang.org/doc/go_spec.html#Defer_statements
Это синтаксический сахар. Он ничего не добавляет по сути.

У меня задача вот какая. Те UnmanagedString о которых я говорил создаются в одном потоке как поля объекта-сообщения, далее этот объект-сообщение обрабатывается в другом потоке и удаляется (фактически помещается в пул для повторного использования). Во время уничтожения все его поля чистятся, соответственно у UnmanagedString вызываются деструктор и она отправляется в свой пул для повторного использования. Так вот мне хочется от языка и от компилятора гарантии, чтобы нигде эта строка никуда не была скопирована простым оператором ":=". Время её жизни равно времени жизни объекта-сообщения и если кто-то её скопирует себе простым оператором ":=", то потом получит сюрприз. Вот поэтому я и думаю о запрете оператора ":=" для некопируемых структур.


vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Минимальная поддержка "умных указателей"
« Ответ #14 : Март 26, 2012, 04:47:17 pm »
Вот поэтому я и думаю о запрете оператора ":=" для некопируемых структур.

Я так понимаю, что спрятать структуру за указатель нельзя, потому что мы боремся с GC?