class Shape{};
class Circle: public Shape{};
Shape& s = Circle{};
위와같은 상황에서 만약에
if(typeid(s) == typeid(Circle))
{
auto& c = dynamic_cast<Circle&>(s);
~~~
}
이런 코드가 필요하다면, 저 dynamic_cast 자리를 static_cast로 바꿔도 상관 없겠지??
class Shape{};
class Circle: public Shape{};
Shape& s = Circle{};
위와같은 상황에서 만약에
if(typeid(s) == typeid(Circle))
{
auto& c = dynamic_cast<Circle&>(s);
~~~
}
이런 코드가 필요하다면, 저 dynamic_cast 자리를 static_cast로 바꿔도 상관 없겠지??
상관 없음 캐스팅이 가능하다는게 확실하다면 캐스팅 동작 자체가 다르지는 않음 다만 typeid, dynamic_cast는 RTTI 때문에 오버헤드가 있고 typeid로 타입을 비교하는 코드 자체도 좋다고 보기 힘들어서 최대한 지양하셈
해보면되잖음 왜 질문을함
근데 그렇게 쓸거면 애초에 shape로 왜묶음?
저 클래스들을 함수제작자가 만든게 아니고 함수 인자로 어떤 서브클래스의 객체가 넘어올지고 모르는데 서브클래스별로 동작은 다르게해야하는 좆같은 상황은 또 생기게 마련임 존나 안티패턴이지만 상황자체가 안티여서 노답인 경우 생김
그걸 하지 말라는 얘긴데 몰라서 단것처럼 보이는구나
106.101/ 내가볼깨는 해야만하는 상황의 방법을 말하는데 하지 말라는 말이 좀더 우매해보임
A여서 B해야하는데 어떡함? => A하지 말라고 => ??
본문만 보고 해야만 하는 상황이란걸 깨달았음? 뭐 예지력이라도 있어?
39.7의 댓글에 반응해놓고는 원문에 그런 내용 어디있냐는게 논리에 맞냐?
본문에는 'a여서' 가 없고 'b해야하는데' 만 있잖아 애초에 Circle& c 하면 안돼?
"저 클래스들을 지가 만든게 아니고 ~~' >> 본문에 그 내용이 없는데 그 얘기 해서 무슨 의미가 있냐고 ㅋㅋ
전제를 깔고 전개된 발언에 전제 자체를 공격하는 오류 게다가 댓글보면 그것조차 아닌데 우기는 것
ㅋㅋ 본문에 앞뒤상황없이 그냥 어거지로 업캐스팅하는 내용만 있어서 "애초에 왜 그렇게 하느냐" 라고 지적하는게 우기는거라고?
A라는 상황이 생길수도 있으니 B도 할수없이 써야할수 있다는 말에 A를 없애야한다는 도식이 얼마나 무의미한지 생각해보셈
클래스들을 함수제작자가 만든 게 아니고 >> 전혀 그런 내용이 없는데 있지도 않은 상황을 상상해서 아무튼 그럴 수 있으니 어거지로 업캐스팅 하는 거에 한 마디도 하지 말라?
첫 번째 댓글도 애초에 그렇게 하지 말란 내용 아님? 저것도 의미가 없냐?
아니지 그건 당연히 맞는 말이고 그 담에 그게 안되는 경우에 대해 말한 39.7도 맞음 그 담이 문제임
네~ 아무튼 그런 일이 생길 수도 있으니 앞으로 무조건 업캐스팅해서 쓰세요~
나는 애초에 circle용 triangle용 함수 따로 만들테니까 니는 shape 받는 함수 하나 만들어서 업캐스팅해서 쓰세요~
그렇게 하라고 누가 가르쳤는지 잘 가르쳤네
이게 다른언어에서는 스마트 캐스팅이라면서 알아서 해주더라 - dc App
다형성이랑 패턴매칭 같이 써야할때 이런식으로 하잖음 - dc App