C ++에서 게임 오브젝트가 실수로 자신을 삭제하는 것을 피하는 방법

내 게임에 플레이어를 폭발시킬 수있는 몬스터가 있다고 가정 해 봅시다. 이 괴물의 이름을 무작위로 선택합시다 : 크리퍼. 따라서 Creeper클래스에는 다음과 같은 메소드가 있습니다.

void Creeper::kamikaze() {
    EventSystem::postEvent(ENTITY_DEATH, this);

    Explosion* e = new Explosion;
    e->setLocation(this->location());
    this->world->addEntity(e);
}

이벤트는 대기하지 않고 즉시 전달됩니다. 이로 인해 Creeper호출 내부의 어딘가 에서 객체가 삭제됩니다 postEvent. 이 같은:

void World::handleEvent(int type, void* context) {
    if(type == ENTITY_DEATH){
        Entity* ent = dynamic_cast<Entity*>(context);
        removeEntity(ent);
        delete ent;
    }
}

메소드가 여전히 실행되는 Creeper동안 오브젝트가 삭제 되므로 kamikaze액세스하려고 하면 오브젝트가 충돌합니다 this->location().

한 가지 해결책은 이벤트를 버퍼에 대기시키고 나중에 전달하는 것입니다. 이것이 C ++ 게임의 일반적인 솔루션입니까? 그것은 약간의 해킹처럼 느껴지지만 다른 메모리 관리 방법을 가진 다른 언어에 대한 나의 경험 때문일 수 있습니다.

C ++에서 객체가 실수로 메소드 중 하나에서 자신을 삭제하는이 문제에 대한 더 나은 일반적인 해결책이 있습니까?

삭제하지 마십시오 this

암묵적으로도.

-이제까지-

멤버 함수 중 하나가 여전히 스택에있는 동안 오브젝트를 삭제하면 문제가 발생합니다. ( "실수로"여부)이 일어나는 결과는 모든 코드 아키텍처를 객관적으로 나쁜 이며, 위험 ,되어야한다 즉시 리팩토링 . 이 경우, 몬스터가 'World :: handleEvent'를 호출 할 수있게 된다면 어떤 상황에서도 해당 함수 안의 몬스터를 삭제하지 마십시오!

(이 특정 상황에서, 나의 일반적인 접근 방식은 몬스터가 자체에 '죽은'깃발을 설정하고 월드 객체 또는 이와 비슷한 것을 프레임마다 한 번씩 '죽은'깃발을 테스트하여 그 객체를 제거하는 것입니다. 월드의 오브젝트 목록에서 삭제하거나 몬스터 풀 또는 그 밖의 적절한 것에 반환합니다. 현재 월드는 삭제에 대한 알림을 전송하므로 월드의 다른 오브젝트는 몬스터가 현재 존재하는 객체가 없다는 것을 알 때 세계는 안전한 시간 에이 작업을 수행하므로 스택이 특정 지점으로 풀리는 것에 대해 걱정할 필요가 없습니다. 'this'포인터는 사용 가능한 메모리를 가리 킵니다.)

버퍼에서 이벤트를 큐에 넣는 대신 버퍼에서 삭제 를 큐에 넣습니다 . 지연된 삭제는 논리를 크게 단순화 할 수있는 잠재력을 가지고 있습니다. 객체에 흥미로운 일이 없다는 것을 알면 실제로 프레임의 끝이나 시작 부분에서 메모리를 확보하고 절대적으로 어디에서나 삭제할 수 있습니다.

세계가 삭제를 처리하도록하는 대신 다른 클래스의 인스턴스가 삭제 된 모든 엔터티를 저장하는 버킷 역할을하도록 할 수 있습니다. 이 특정 인스턴스는 ENTITY_DEATH이벤트를 수신하고 대기하도록 이벤트를 처리해야합니다. 는 World프레임이 렌더링 차례로 엔티티 인스턴스의 실제 삭제를 수행 할 '명확한'이 양동이, 한 후 다음으로 반복 이러한 경우 이상 및 사후 죽음의 작업을 수행 할 수 있습니다.

이러한 클래스의 예는 다음과 같습니다. http://ideone.com/7Upza

게임의 모든 게임 오브젝트 할당에 사용되는 팩토리를 구현하는 것이 좋습니다. 따라서 새로운 전화를하는 대신 공장에서 무언가를 만들라고 지시 할 것입니다.

예를 들어

Object* o = gFactory->Create("Explosion");

객체를 삭제하려고 할 때마다 팩토리는 다음 프레임에서 삭제 된 버퍼에 객체를 푸시합니다. 대부분의 시나리오에서 지연 파괴는 매우 중요합니다.

또한 한 프레임 지연으로 모든 메시지를 보내십시오. 즉시 보내야 할 경우가 많지만 대부분의 경우 예외가 있습니다.

C ++에서 관리 메모리를 직접 구현할 수 있으므로 ENTITY_DEATH호출 될 때 발생하는 모든 참조 수가 1 씩 줄어 듭니다.

나중에 @John이 모든 프레임의 구걸에서 제안한 것처럼 쓸모없는 엔티티 (0 참조가있는 엔티티)를 확인하고 삭제할 수 있습니다. 예를 들어 boost::shared_ptr<T>( here 문서화 됨 ) 또는 C ++ 11 (VC2010)을 사용하는 경우std::tr1::shared_ptr<T>

풀링을 사용하고 실제로 객체를 삭제하지 마십시오. 대신 등록 된 데이터 구조를 변경하십시오. 예를 들어 객체를 렌더링하는 경우 렌더링, 충돌 감지 등을 위해 장면 객체와 모든 엔티티가 어떻게 든 등록되어 있습니다. 객체를 삭제하는 대신 장면에서 분리하여 죽은 객체 풀에 삽입하십시오. 이 방법은 메모리 문제 (예 : 객체 자체 삭제)를 방지 할뿐만 아니라 풀을 올바르게 사용하면 게임 속도를 높일 수도 있습니다.

우리가 게임에서 한 일은 새로운 게재 위치를 사용하는 것이 었습니다

SomeEvent* obj = new(eventPool.alloc()) new SomeEvent();

eventPool은 큰 메모리 배열로 각 세그먼트에 대한 포인터가 저장되었습니다. 따라서 alloc ()은 사용 가능한 메모리 블록의 주소를 반환합니다. eventPool에서 메모리는 스택으로 취급되었으므로 모든 이벤트가 전송 된 후 스택 포인터를 배열의 시작 부분으로 다시 재설정했습니다.

이벤트 시스템의 작동 방식으로 인해 evetns에서 소멸자를 호출 할 필요가 없었습니다. 따라서 풀은 단순히 메모리 블록을 사용 가능한 것으로 등록하고 할당합니다.

이것은 우리에게 큰 속도를 주었다.

또한 ... 실제로 게임이 종료 될 때 풀에 남아있는 객체가있는 경우 메모리 누수를 찾는 좋은 방법 이었기 때문에 개발 중에 동적으로 할당 된 모든 객체에 대해 메모리 풀을 실제로 사용했습니다. 멤 누출.