Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[Qraizer]

Я пользую только два, shared и auto. Думаю, что третий - weak_ptr - когда-нибудь да понадобится, но что-то долго уже как-то без надобности.

[D_KEY]

Цитата korvin @ 24.03.11, 21:22

Цитата D_KEY @ 24.03.11, 21:14

Это насчитал не ты, а Роб Пайк, что он и показывал на одной из презентации go.
Кстати, поясни, где именно ты их насчитал и для чего каждый нужен ?
Сразу скажу, что в стандарте их всего один. В новом стандарте он deprecated, но будут два других из этого списка.

хы, значит у нас с ним мысли немного сходятся =)) я считал независимо, я просто перечисли то, что вспомнил по упоминаниям в инете, понятия не имею для чего каждый нужен (это и пугает)

в стандарте может и один, но судя по интеу, пользуются многими в зависимости от ситуации

Это все из разных библиотек. Ладно.
smart_ptr - не знаю что ты под ним имеешь в виду, обычно это просто общее название для умного указателя.
auto_ptr - стандартный умный(правда не очень) указатель, предназначенный для одиночного владения и автоматического удаления памяти. Имеет кучу недостатков.
shared_ptr - (boost, новый стандарт) наиболее часто используемый указатель. Реализует подсчет ссылок.
weak_ptr - (boost, новый стандарт) реализует семантику "слабых ссылок" для shared_ptr.
unique_ptr - (новый стандарт) замена для auto_ptr, без его изначальных недостатков(в частности, их можно помещать в контейнеры).
scoped_ptr - (boost) замена для auto_ptr, с запретом копирования. будет, в принципе, не нужен с появлением unique_ptr.
intrusive_ptr - (boost) предназначен для объектов, которые сами уже умеют осуществлять подсчет ссылок, лично я никогда не использовал.

Итак, подводим итоги. Есть указатель для единовластного владения объектом(unique_ptr, auto_ptr/scoped_ptr - устарели), указатель для подсчета ссылок(shared_ptr, intrusive_ptr - для особых случаев) и дополнительный указатель для добавления "слабых" ссылок к механизму подсчета ссылок(weak_ptr).
В итоге все становится не сложнее(учитывая специфику С++), чем в C# и Java, где точно также есть, например, мягкие и слабые ссылки, которые пришлось фактически зашить в язык, в отличие от С++, где все реализовано в библиотеках штатными средствами языка.
В других библиотеках могут быть другие указатели, реализующие какие-то специфичные вещи.
Если кто-то может исправить/дополнить, то не молчите

Сообщение отредактировано: D_KEY - 25.03.11, 08:21

[korvin]

что такое слабая ссылка? В чем ее особенность?

[D_KEY]

Цитата korvin @ 25.03.11, 08:29

что такое слабая ссылка? В чем ее особенность?

В том, что она не владеет объектом, на который ссылается(не учитывается сборщиком мусора или не работает с счетчиком при подсчете ссылок). Ты у нее всегда запрашиваешь временную "настоящую" ссылку и если объект уже был удален, то тебе вернут null/nil/nullptr.

[korvin]

ну не знаю как в яве и C#, но ни в CL, ни в Схеме, ни в Хаскелле об этом задумываться не приходится =) ну да ладно

[D_KEY]

Цитата korvin @ 25.03.11, 10:20

ну не знаю как в яве и C#, но ни в CL, ни в Схеме, ни в Хаскелле об этом задумываться не приходится =) ну да ладно

А можно подробнее?
Вот, например, у нас есть некий список объектов, которые на что-то подписываются. Если ссылки будут жесткими, то объекты, которые у нас подписались, никогда не будут удалены сборщиком мусора.
Кстати, при подсчете ссылок мягкие ссылки используются еще и для устранения основной проблемы этого механизма - циклических ссылок.

Сообщение отредактировано: D_KEY - 25.03.11, 12:05

[Qraizer]

D_KEY, а unique передаёт владение при копировании, как auto?

Добавлено 25.03.11, 13:49
korvin, фактически weak - это простой указатель, но проверяющий в run-time валидность своей ссылки.

[D_KEY]

Цитата Qraizer @ 25.03.11, 13:47

D_KEY, а unique передаёт владение при копировании, как auto?

Именно копирование у него запрещено, взамен он реализует move-semantic с помощью r-value ссылок.

Цитата

korvin, фактически weak - это простой указатель, но проверяющий в run-time валидность своей ссылки.

Ну не совсем. Без shared_ptr он не работает.

[korvin]

Цитата D_KEY @ 25.03.11, 12:05

А можно подробнее?
Вот, например, у нас есть некий список объектов, которые на что-то подписываются. Если ссылки будут жесткими, то объекты, которые у нас подписались, никогда не будут удалены сборщиком мусора.
Кстати, при подсчете ссылок мягкие ссылки используются еще и для устранения основной проблемы этого механизма - циклических ссылок.

можно подробней, что значит "на что-то подписываются"? и да, нормальные ПС работают не по алгоритму подсчета ссылок =)

Добавлено 25.03.11, 17:14

Цитата Qraizer @ 25.03.11, 13:47

korvin, фактически weak - это простой указатель, но проверяющий в run-time валидность своей ссылки.

не, я кажется понял, что это, даже могу смоделировать такое поведение в Racket(Scheme), но не очень представляю практическую пользу =/

Добавлено 25.03.11, 17:16

Цитата D_KEY @ 25.03.11, 12:05

Цитата korvin @ 25.03.11, 10:20

ну не знаю как в яве и C#, но ни в CL, ни в Схеме, ни в Хаскелле об этом задумываться не приходится =) ну да ладно

А можно подробнее?

да и что подробнее? ни в одной литературе по этим языкам нет упоминания о различии типов ссылок. даже в "Thinking in Java" не припомню такого

[amk]

Цитата korvin @ 25.03.11, 17:12

могу смоделировать такое поведение в Racket(Scheme)

Смысла в этом действительно ноль, поскольку там нодовая организация ссылок, обеспечивающая очень эффективную реализацию сборщика мусора. Ты можешь не бояться потерять где-нибудь в памяти закольцованный список. В C++ сборщика мусора нет вообще, поэтому иногда единственный способ обеспечить корректность работы указателей - явно разделить указатели на владеющие объектом (shared) и просто ссылающиеся (weak), что тебе действительно могло бы быть из этой пары полезным, так это отслеживание вторым типом указателей времени жизни объекта, указуемого указателями первого типа.

[D_KEY]

Цитата korvin @ 25.03.11, 17:12

Цитата D_KEY @ 25.03.11, 12:05

А можно подробнее?
Вот, например, у нас есть некий список объектов, которые на что-то подписываются. Если ссылки будут жесткими, то объекты, которые у нас подписались, никогда не будут удалены сборщиком мусора.
Кстати, при подсчете ссылок мягкие ссылки используются еще и для устранения основной проблемы этого механизма - циклических ссылок.

можно подробней, что значит "на что-то подписываются"?

Да любая подписка на любые события.

Цитата

да и что подробнее? ни в одной литературе по этим языкам нет упоминания о различии типов ссылок. даже в "Thinking in Java" не припомню такого

http://en.wikipedia.org/wiki/Weak_ref

Добавлено 25.03.11, 19:42

Цитата korvin @ 25.03.11, 17:12

и да, нормальные ПС работают не по алгоритму подсчета ссылок =)

Подсчет ссылок решает проблему управления памятью, если у тебя нет циклических ссылок. А когда они появляются, в большинстве случаев, их можно устранить с помощью тех же weak_ptr'ов. Но согласен, сборка мусора гораздо мощнее, вот только и она не во всех системах приемлема. Кстати, вариант питона, где работает подсчет ссылок + отдельный запуск сборки мусора, мне нравится.
Вообще язык программирования должен предоставлять возможность осуществлять любую стратегию управления памятью, которая подходит к данной ситуации...

Сообщение отредактировано: D_KEY - 25.03.11, 19:42

[korvin]

Цитата D_KEY @ 25.03.11, 19:37

Да любая подписка на любые события.

все равно не понял, на более низком уровне -- хранение ссылок на объекты-отправители внутри объекта по слаой ссылке?

Цитата D_KEY @ 25.03.11, 19:37

http://en.wikipedia.org/wiki/Weak_ref

наверное мы не так поняли друг друга: при использовании лиспа, хаскела, джавы(на уровне чтения "философии" Эккеля) мне ни разу не приходилось задумываться о существовании разных видов ссылок

и да, "лисп" в этой статье все равно, что написать "ЯП", слишком большое множество разных языков =)

Цитата D_KEY @ 25.03.11, 19:37

Подсчет ссылок решает проблему управления памятью, если у тебя нет циклических ссылок. А когда они появляются, в большинстве случаев, их можно устранить с помощью тех же weak_ptr'ов. Но согласен, сборка мусора гораздо мощнее, вот только и она не во всех системах приемлема. Кстати, вариант питона, где работает подсчет ссылок + отдельный запуск сборки мусора, мне нравится.
Вообще язык программирования должен предоставлять возможность осуществлять любую стратегию управления памятью, которая подходит к данной ситуации...

сборщик мусора с подсчетом ссылок -- УГ, копирующие GC пока что единственный правильный вариант GC

Сообщение отредактировано: korvin - 25.03.11, 19:49

[D_KEY]

Цитата korvin @ 25.03.11, 19:47

Цитата D_KEY @ 25.03.11, 19:37

Да любая подписка на любые события.

все равно не понял, на более низком уровне -- хранение ссылок на объекты-отправители внутри объекта по слаой ссылке?

Хранения ссылок на объекты-получатели.
Представь, подписываешься на события, потом твой объект уже никому не нужен, ссылок на него уж и нету, но в списке он висит, следовательно, GC не в состоянии его удалить. И из списка исключить этот объект уже не кому.

Цитата

Цитата D_KEY @ 25.03.11, 19:37

http://en.wikipedia.org/wiki/Weak_ref

наверное мы не так поняли друг друга: при использовании лиспа, хаскела, джавы(на уровне чтения "философии" Эккеля) мне ни разу не приходилось задумываться о существовании разных видов ссылок

А он и нужен не так часто. Собственно, weak_ptr тоже.

Цитата

сборщик мусора с подсчетом ссылок -- УГ, копирующие GC пока что единственный правильный вариант GC

Лично я считаю, что подсчет ссылок - это вообще не GC
Если ты про питон, то в нем эти механизмы работают параллельно. То есть все переменные имеют счетчик ссылок, а за удаление циклических ссылок отвечает уже сборщик.

[korvin]

Цитата D_KEY @ 25.03.11, 20:04

ссылок на него уж и нету, но в списке он висит

взаимоисключающие парграфы

Цитата D_KEY @ 25.03.11, 20:04

Если ты про питон, то в нем эти механизмы работают параллельно. То есть все переменные имеют счетчик ссылок, а за удаление циклических ссылок отвечает уже сборщик.

то-то пистон такой тормаз =))

Сообщение отредактировано: korvin - 25.03.11, 20:18

[D_KEY]

Цитата korvin @ 25.03.11, 20:17

Цитата D_KEY @ 25.03.11, 20:04

ссылок на него уж и нету, но в списке он висит

взаимоисключающие парграфы

Может хватит придираться? Других ссылок, кроме той, что в списке, на него нет.