Войти
ФлеймФорумПрограммирование

[c#] обнулить все ссылки на обьект (6 стр)

Страницы: 15 6 7 816 Следующая »
#75
11:40, 15 июня 2019

Polyflow3d
Объяснять сложно. Да и у тебя наверняка припасена дебильная аргументация против доводов. Как вот тебе что то объяснить, если тебе кажется что достаточно только обнулить ссылки в коллекциях.


#76
11:53, 16 июня 2019

Polyflow3d
Тебе тут пытались рассказать (хотя не удивительно, что у них не получилось) про общую концепцию weakptr. Конкретно в C# очистка слабых ссылок завязана на сборщик мусора. Но общая концепция может быть реализована ручками на любом языке программирования.
Вот набросал тебе пример, чтобы ты понял принцип работы слабых ссылок:
https://rextester.com/DDRX61123
В контексте C# они просто вызывают аналог Unlink в момент финализации. Ты же можешь сделать свои слабые ссылки, и вызывать unlink в любой момент.

#77
(Правка: 12:49) 12:49, 16 июня 2019

MrShoor

Читайте документацию по weak pointers именно в c# и не надо тут выдумывать бред и отсебятиину.
"Общие концепции" тоже обсуждайте в других темах, меня интересует конкретное решение в конкретном языке - c#

Вот набросал тебе пример, чтобы ты понял принцип работы слабых ссылок:  . Ты же можешь сделать свои слабые ссылки, и вызывать unlink в любой момент.

Сейчас ты просто один reference type завернул в другой reference type, и чо?


private GameObject obj;
        public void Unlink()
        {
            obj = null;
        }

вот это обоссака. Ты считаешь что если ты написал private , то obj-ем полностью владеет класс WPtr?

Ну вот такой код.

GameObject go = new GameObject(13);
GameObject[] objs = new GameObject[1000];
for (int i = 0; i<objs.Length; i++){
  objs[i] = go.WPtr().Obj();
}
go.Unlink();

В массиве как были, так и остались 1000 сылок на go.
Твой WPtr с его Unlink() это по сути черезжопный способ сделать тупо флаг IsAlive(или IsLinked или IsDeleted как угодно его называй).
Ну , я уж лучше унаследуюсь от какого нибудь базового класса в котором будет isAlive flag, чем делать новый обьект внутри другого лишь для того что бы у него спрашивать == null.

Не ребят, ну не смешно уже.
Может тут буду писать те кто знаком с с#, а не теоретизировать?

#78
12:51, 16 июня 2019

MrShoor
Понель? Не туды ты полез со своими вик поинтерами)

#79
13:18, 16 июня 2019

cNoNim

Понель? Не туды ты полез со своими вик поинтерами)

конечно не туда.
Как и ты, клоун.

#80
(Правка: 18:52) 18:48, 16 июня 2019

Polyflow3d
> Читайте документацию по weak pointers именно в c# и не надо тут выдумывать бред
> и отсебятиину.
Читай что тебе пишут.

Polyflow3d
> Сейчас ты просто один reference type завернул в другой reference type, и чо?
И то, что в С# WeakReference работает ровно таким же образом. С единственным отличием: он делает Unlink в момент, когда GC чистит память.

> вот это обоссака.
Надеюсь в этот момент рядом с тобой никого не было же. А то позор позор.

> Ну вот такой код.
> В массиве как были, так и остались 1000 сылок на go.
А ты не складывай в этот массив GameObject-ы. Попробуй складывать слабые ссылки:

GameObject go = new GameObject(13);
WPtr[] objs = new WPtr[1000];
for (int i = 0; i<objs.Length; i++){
  objs[i] = go.WPtr();
}
go.Unlink();

> Ну , я уж лучше унаследуюсь от какого нибудь базового класса в котором будет
> isAlive flag, чем делать новый обьект внутри другого лишь для того что бы у
> него спрашивать == null.
А я ведь тебе с самого начала говорил, что это самый простой вариант.

> Может тут буду писать те кто знаком с с#, а не теоретизировать?
Тебе уже написали те, кто знаком. В c# сделать то, что ты хочешь - невозможно. Есть только варианты с флагом isAlive и WeakPtr.
Может ты уже пойдёшь делать кривые плечи на всякие там реалтайм 3д модели? Программирование явно не твоя стихия.
И еще могу посоветовать к психологу записаться. А то нервишки не бесконечные.

#81
0:40, 17 июня 2019

Интересно, где в шарпе хранятся ссылки на ссылки на объект?

#82
7:39, 17 июня 2019

monobogdan
> Зависит от реализации GC конечно, я привёл один из самых простых и быстрых кейсов.
  Трассирующий сборщик быстрее, а иногда и проще. Чтобы понять насколько достаточно вспомнить, что GC на счётчиках используют только во всяком медленном говне типа Питона или VBA.

#83
(Правка: 8:55) 8:53, 17 июня 2019

Zefick
> GC на счётчиках используют только во всяком медленном говне типа Питона или VBA
Питон и VBA медленные не из-за GC, рефкаунты наоборот самый быстрый вариант, потому что позволяют узнать, нужен ли ещё объект ещё на этапе присвоения ссылки. Но в некоторых случаях он может ликать, да, поэтому наверное имеет смысл добавить ручное управление рефкаунтом(сделав манагед язык отчасти анманагед).

#84
9:23, 17 июня 2019

monobogdan
> Питон и VBA медленные не из-за GC
  Именно поэтому авторы и не стали вставлять туда нормальный GC: потому что это уже никак не поможет. Вроде не сложно догадаться. В быстрых языках такой ерунды уже нету.

> рефкаунты наоборот самый быстрый вариант
  Лишь ещё раз повторю, что это не так. Рефкаунты требуют проделать гораздо больше работы, чем обычный трассирующий сборщик. Периодически запускать процедуру, которая отследит живые объекты, которых всего 1% от общей массы созданных, на порядки быстрее, чем при каждом присваивании (которых в типичном коде примерно 1 на строку) дёргать атомарный счётчик.

> потому что позволяют узнать, нужен ли ещё объект ещё на этапе присвоения ссылки.
  Ну узнал ты что он не нужен, дальше что? Сразу удалять кинешься? Почитай на досуге как вообще нормальные GC работают. Там всё совсем не так как себе мамкины программисты представляют и мёртвым объектам уделяется гораздо меньше внимания, чем ещё живым.

#85
9:45, 17 июня 2019

Получается, если реализовывать замысел автора, то нужно, чтобы любой вызов метода объекта локал указатель на этот объект (чтобы какой-то олень из другого потока в момент исполнения метода не удалил этот объект)? Ведь обычные проверки типа if(obj != null) obj.Foo(); очевидно ничего не гарантируют.
Автор представляет, какой оверхед будет, если все методы в программе будут это делать?

#86
(Правка: 10:02) 9:59, 17 июня 2019

Zefick
> Именно поэтому авторы и не стали вставлять туда нормальный GC
Ну так это языки для совершенно других задач. Зачем сравнивать жопу с пальцем?

Zefick
> Лишь ещё раз повторю, что это не так. Рефкаунты требуют проделать гораздо
> больше работы, чем обычный трассирующий сборщик. Периодически запускать
> процедуру, которая отследит живые объекты, которых всего 1% от общей массы
> созданных
На практике GC отрабатывает только когда засрано половину кучи, и создаёт нереальные фризы, потому что ему не только надо собрать ссылки, но и освободить нативные объекты(если такие есть) и только затем освободить память. Не неси бред.

> на порядки быстрее, чем при каждом присваивании (которых в типичном
> коде примерно 1 на строку) дёргать атомарный счётчик.
Ты сам GC копал или говоришь так, как тебе кажется? Какая потеря производительности от инкремента/декремента счётчика?
Но даже если сферически в вакууме ты себе представил, что рефкаунтинг медленный - в любом случае лучше иметь константную потерю про-сти, чем когда у тебя софтина зависает, только потому что кучи начинает не хватать.

> Сразу удалять кинешься
Да. Что плохого в том, чтобы удалять объект когда он не нужен?)

#87
11:10, 17 июня 2019

monobogdan
> Зачем сравнивать жопу с пальцем?
  Ну это ты зачем-то начал сравниваешь GC на счётчике ссылок с нормальными GC.

> Ты сам GC копал или говоришь так, как тебе кажется?
  Я отлично знаю как устроены самые быстрые на текущий момент сборщики и какие они в разных языках. На RC они обычно во всяком говне, которое я выше перечислял. В C#, а следовательно и в юнити, он трассирующий. И V8, который сейчас во всех браузерах работает - тоже трассирующий.

> Какая потеря производительности от инкремента/декремента счётчика?
  Если тебе слово "атомарный" ни о чём не говорит, то медицина тут уже бессильна.

> в любом случае лучше иметь константную потерю про-сти, чем когда у тебя
> софтина зависает, только потому что кучи начинает не хватать.
  В нормальных GC это всё давно решено, прогресс на месте не стоит (например, диванным экспертам невдомёк, что кучу можно разделить на регионы и собирать мусор в разных регионах независимо, что сократит время пауз). Другое дело, что в C# он не совсем нормальный и за двадцать лет это никак не исправили.

> Что плохого в том, чтобы удалять объект когда он не нужен?)
  Проблема в том, что нормальные GC вообще не тратят время на удаление объектов. Так что считай что ты просто получил оверхэд на ровном месте.

#88
11:54, 17 июня 2019

Polyflow3d
> Речь о том , чтобы назначать массово null всем ссылкам на один и тот же
> обьект.
Ну как бы так просто не принято делать ни в одном языке.
Если надо какое-то поле поменять, то меняешь это поле.

#89
12:13, 17 июня 2019

Polyflow3d
> это пример (в контексте обсуждения) для тупых, которые не помнят\не понимаю что
> они пишут в предыдущей строчке своего кода а потом обмазываются (для типа
> безопасности) проверками и обсерверами. .
Но ведь ты сам пытаешься протолкать решение в стиле "пусть ГЦ ещё и логику за меня делает". Неет, он не для этого. А так тебе помогут слабые ссылки, всё верно.

Страницы: 15 6 7 816 Следующая »
ФлеймФорумПрограммирование