처음에 입력한 닉네임과
추후에 불러오는 닉네임이 다릅니다.
당연합니다.
다른 객체를 넣었으니 말이지요.
이렇게 넣으면 뜰 듯 하네요.
해결.
이제 가상함수를 쓸 생각에 가슴이 떨립니다.
정말 바로 에러가 뜨는군요. 하긴 그냥 해도 나는 에러이니, 확정적으로 난다고 했으면 날만 합니다.
그래요. 일단 Player는 버츄얼이 되어버렸습니다. 이제 이걸 상속받을 전사를 만들어 줍시다.
그 이전에 아주 중요한 걸 알았습니다. 항상 헤더 파일을 생상할 때마다 마주하던 친구입니다.
#pragma once : 중복 포함 방지 장치
- 헤더 파일이 여러 번 include되어도 문제가 생기지 않게 막는 장치가 필요
- 같은 설계도를 여러 번 책상 위에 올려도, 실제로는 한 번만 참고하게 하는 표시
라고 합니다. Include Guard라는 전통적인 방식도 있군요.
#ifndef WARRIOR_H
#define WARRIOR_H
// Warrior 클래스 선언
#endif
이런식으로 진행한다고 합니다. 의미는
WARRIOR_H가 아직 정의되지 않았다면
지금 이 파일 내용을 읽고
WARRIOR_H를 정의해서
다음부터는 다시 읽지 않게 함
이런식인가 보군요. 약간 std::과 using namespace std;를 보는 기분입니다. 저는 야비하게 편한 걸 써보겠습니다.
나는 Player를 기반으로 만들어진 클래스라는 선언도 해주었습니다.
여기에 attack함수를 넣어주면 수정이 가능해지겠죠?
cpp를 작성하러 가봅시다. 이제 초록 스파게티 면은 덜 두려운 기분이 듭니다.
무언가 많이 잘못되었습니다.
목표 흐름은 이렇습니다.
Warrior 생성자 → Player 생성자 호출 → Warrior 전용 직업 값 설정 → attack() 구현
Player 생성자 호출을 어떻게 하는지 모르겠군요.
: Player(name, hp, mp, power, defence)
이걸 현재 함수 뒤에 덧붙이는 형식으로 호출을 한다고 합니다.
= 이건 그냥 뼈란다. 응당 뼈와 피와 살이 있어야 마땅한데 피와 살은 어디있니. 로 들리는 건 기분 탓일 겁니다.
새롭게 알게된 지점 중 하나는 using namespace std; 이 편리하긴 하지만 std::string 가 실무에서 더 많이 쓰인다는 겁니다. 이 이름이 어디에서 온 것인지 명확하게 보여주기 때문이라고 하는군요.
근데 이렇게 하고 보니 확실히 가상함수 부분이 와닿습니다. 언리얼이랑 연결해서 생각해보니 더 연상이 편하기도 하군요.
이제 그럼 가상소멸자 파트입니다.
가상소멸자?
부모 포인터로 자식 객체를 삭제할 때 자식의 정리 과정까지 제대로 실행되게 하려고 필요
Player가 “공통 캐릭터 계약서”이며 Warrior가 실제 캐릭터라고 생각합시다. 게임이 끝나서 캐릭터를 정리할 때, 겉으로는 Player로만 보고 있더라도 실제 안에는 Warrior일 수 있습니다. 이때 소멸자가 가상이 아니면:
“Player 부분만 정리하고 끝”
처럼 동작할 수 있지만
가상 소멸자가 있으면:
“실제 객체가 Warrior였네? 그럼 Warrior 정리부터 하고 Player도 정리하자”
라는 흐름이 된다고 합니다.
핵심 개념
Player 타입으로 Warrior를 가리킴
나중에 그 객체를 삭제함
이때 실제 객체인 Warrior의 소멸자도 호출되어야 함
그래서 부모 클래스인 Player의 소멸자에 virtual을 붙임
정리
Player처럼 상속의 부모로 쓰이는 클래스라면 가상 소멸자를 두는 것이 안전.
- 자식 객체의 소멸자가 제대로 호출됨
- 동적 메모리 정리가 안전해짐
- 다형성을 사용하는 클래스에서 기본적으로 권장됨
형식에 맞게 Player.h에 잘 추가해 둡니다.
직업을 선택할 수 있게끔 함수 작업을 해봅시다.
이전 Upgrade 함수를 응용해서 만들어 봅니다.
실행은 되지만 오류가 사라지지 않습니다. E0308코드...
알고보니 헤더 오류였습니다. 하하. include를 상시 확인합시다.
그리고 이렇게 몬스트 초기화를 해두면 몬스터 추가가 어려워지므로
이렇게 값을 비워두는 게 범용성에서 낫겠습니다.
그리고 main에서 이렇게 불러주면 슬라임이 생성됩니다.
이제 객체화에 조금은 익숙해졌습니다.
