forum.boolean.name - Программное самоубийство

forum.boolean.name (http://forum.boolean.name/index.php)

- Болтовня (http://forum.boolean.name/forumdisplay.php?f=25)

- - Программное самоубийство (http://forum.boolean.name/showthread.php?t=12372)

Программное самоубийство

Здравствуйте.

Упрощённая модель "убивающего" себя объекта (субъекта-человека), программная реализация.

Делюсь размышлениями. Желающим пнуть по возможности поставлю блок.

Итак.
Допустим, есть желающий покончить с собой. Однако, покончить нужно таким образом, чтобы не оставить следов.

Где он? В какой-то глобальной хеш-таблице или векторе (допустим).

У него есть "метод" Free() или Release(), который освобождает все занимаемые им ресурсы.
И этот метод может быть вызван в момент самоубийства.
Теперь бы только удалиться из вектора! Как это сделать?

Не лучший вариант (это Java-код):

Код:

public void Release()

{

    data = null;

    RemoveFromGlobalList(this);

}

А что за функция RemoveFromGlobalList()?
приходит на ум такой её вид:

Код:

public static void RemoveFromGlobalList(CObject obj)

{

    CResourceManager.RemoveFromList(obj);

    

    //или через экземпляр

    //resMng.RemoveFromList(obj);

}

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

А что же остаётся? Вполне естественным представляется такое взаимодействие с менеджером объектов (который имеет ту самую хеш-таблицу), при котором он заведует удалением извне.

И происходить всё может в методах обновления, вот так:

для объекта:

Код:

public int Update()

{

    if(subState == SUBSTATE_FULL_DEPRESS || IsLifeTheShit() == true)

    {

        boolean rez = fnTryToDieSomehow();

        if(rez == true)

        {

            Release();

            return STATE_DEAD;

        }

    }

    return 0;

}



public void Release()

{

    data = null;    

}

для менеджера:

Код:

public int Update()

{

    int rez;

    CObject obj;

    for(int k=0;k<objCount;++k)

    {

        obj = vectorObjs.elementAt(k);

        rez = obj.Update();

        if(rez == CObject.STATE_DEAD)

        {

            //obj.Release(); //можно тут освобождать память

            vectorObjs.removeElementAt(k);

        }

    }

    return 0;

}

Кстати, "data = null;" убивает указатель на данные, а сами данные живут до вызова System.gc(); (его аналога)
А какой интервал вызова жизненного коллектора?:) может статься, что не мгновенный.

Ещё: коллектор удаляет те объекты, на которые больше нет ссылок. А на нашего самоубийцу такое распространяется-нет?

например:

Код:

man = new CObject();

man.SetName("Женя");

man.SetParents(papa, mama);

man.SetFriend(man1790897);

man24.SetFriend(man); ////ВНИМАНИЕ! ссылка на чувака у man24

и тут ещё:

Код:

public void SetParents(CObject pp, CObject mm)

{

    papa = pp;

    mama = mm;

    pp.SetChild(this); //ВНИМАНИЕ! ссылка на чувака у папы

    mm.SetChild(this); //ВНИМАНИЕ! ссылка на чувака у мамы    

}

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

Мораль сей басни такова: самоубийца может лишь освободить занимаемые им ресурсы, однако исчезнуть совсем - нет, и это уже решается на уровне менеджера объектов.

вот обновлённый апдэйт:

Код:

public int Update()

{

    int rez;

    CObject obj;

    for(int k=0;k<objCount;++k)

    {

        obj = vectorObjs.elementAt(k);

        rez = obj.Update();

        if(rez == CObject.STATE_DEAD)

        {

            if(obj.GetExperience() >= MIN_EXP_FOR_RELEASE)

                vectorObjs.removeElementAt(k);

            else

                RecreateObject(obj);

        }

    }

    return 0;

}

ПС: видимая связь между моей подписью и этой статьёй отсутствует.

До свидания.

Ответ: Программное самоубийство

Интересно :super:

Ответ: Программное самоубийство

1) reference counter форева
2) в случае если убийство описано в методе интерфейсного класса то удаление из менеджера нельзя сделать по логике вещей (хотя физически можно, только это говнокод), ибо мы пишем просто структуру для хранения данных и методы работы с ней
3) удаление надо описывать в классе который имеет возможность работать с манагером
4) хороший тон удалять через манагер, без самоубийств, тогда не нарушается архитектура зависимостей

для некоторых вещей я считерил, к примеру для ресурсов игры бывает такая ситуация что огромную текстуру загрузят, потом откажутся от её использования, а через 4 секунды опять загрузят, делаем чтобы менеджер тоже получал reference на объект, тогда если все откажутся от объекта то всё равно будет один reference - сам манагер, он по этому и определяет нужна кому-то текстура или нет, и когда от неё отказались, сколько времени стоила загрузка и стоит ли выгружать тогда

Ответ: Программное самоубийство

Цитата:

Сообщение от jimon (Сообщение 144694)

1) reference counter форева

Как он поможет субъекту самоудалиться?:)

Цитата:

Сообщение от jimon (Сообщение 144694)

2) в случае если убийство описано в методе интерфейсного класса то удаление из менеджера нельзя сделать по логике вещей

Вот это я не понял.:)

Цитата:

Сообщение от jimon (Сообщение 144694)

3) удаление надо описывать в классе который имеет возможность работать с манагером

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

Цитата:

Сообщение от jimon (Сообщение 144694)

4) хороший тон удалять через манагер, без самоубийств, тогда не нарушается архитектура зависимостей

Как раз эту мысль я и принёс в массы в статье.:)