물론 아키텍쳐나 컴파일러의 구현에 따라 퍼포먼스가 다를 수 있지만 일반화시켜서 말할 수는 없습니다. 뭐 보통은 heap allocation/deallocation (new/delete)의 overhead 때문에 stack이 약간 빠를 수 있다고 말은 하지만 보통의 경우엔 프로그램 전체의 퍼포먼스에서 보면 별 차이가 있다고 생각하지 않습니다.
여기서는 A 가 B 를 소유하고 있는 경우인데, new B 로 B를 생성하게 되면 A 가 stack 에 있던지 heap 에 있던지 B는 무조건 heap 에 생성됩니다. 하지만 A를 local scope에서 쓰기 위해 그냥 a=A; 처럼 만든다면 A가 소유하고 있는 B의 object 가 heap에 가야 할 이유는 일반적으로는 없죠. 하지만 두 가지 예외가 있습니다.
첫번째 예외는 A 가 죽어도 B가 살아 있어야 하는 경우입니다. 이 경우는 B의 포인터를 나중에 누군가에게 넘겨 주거나, 아니면 애초에 다른 누군가에게서 넘겨 받은 경우이죠. 이렇게 논리적으로는 A가 B를 소유하고 있지만 B의 본체는 A의 바깥에 있고 A는 단지 B를 참조하게 되는 형태를 aggregation이라고 합니다. 반면에 A가 B를 완전히 내부에 소유하게 되는 (그래서 A가 죽으면 B가 죽는게 당연한 형태)를 composition 이라고 부릅니다. 즉 new를 사용해 B를 만든다는 것은 B를 누구에서 넘겨 받을 수 있거나 (그래서 누가 주지 않는 경우 default로 생성하거나) 하니면 A가 죽고 나서도 B가 살아 있어야 하는 이유가 있는 경우입니다.
두번째 예외는 B가 커서 stack 메모리에 들어갈 수 없는 경우입니다. 보통 1MB정도 되는데 이보다 크면 heap 에 생성해야겠죠.
성능은 문제없을 것 같고...
저라면 new delete 하기가 짜증날 것 같은...
뭐 간단하면 new delete 몇개 안 쓰겠지만 말이예요.
지금 말씀하시는
지금 말씀하시는 것은 코드 재사용을 고려하지 않은 것입니다.
재사용을 고려한 코드라면, '클래스 B가 A의 멤버로만 사용되고, A는 힙에만 생성될 것이다'라는 가정은 할 수 없으니까요.
만약 재사용될 일이 없는 코드라면 질문하신 내용의 답은,
아무렴 어떻겠습니까.
편하신대로 하시면 됩니다.
가 될 것같습니다.
성능이 걱정된다고 하셨는데, new-delete가 성능에 큰 영향을 미칠 것이라고 생각하기는 힘들군요.
만약 그것이 정말 문제가 된다면, 그때가서 고치면 됩니다.
A에서 포함하고있는
A에서 포함하고있는 B를 A에서 생성하지마고
생성되어 있는 B를 포인터로 얻어와서 쓰심 빠르리라고 보입니다.
그렇지안타면 B를 인라인으로 A안에 포함시켜 버림이..
예전 C를 배울때 누군가 했던 말이 생각나는군요
malloc -> m얼록 -> 말록 -> 몰락
new 도 마찬가지.. ㅋ
전혀 마찬가지가
전혀 마찬가지가 아닙니다.
C++의 클래스는 생성자와 소멸자가 있고,
new/delete를 사용하면 생성자/소멸자가 자동으로 호출되므로
멤버변수의 동적할당의 깊이를 추적할 필요는 없습니다.
각클래스가 자기가 할당한 분만 해제해주면 됩니다.
xylosper 님 오해를
xylosper 님 오해를 ``
마찬가지라고 한거는 new도 malloc 와 마찬가지로 heap 에 잡힌다는 이야기 입니다.
간단한 게임 --> 어느정도 까지인가 문제겠지만
쓸데없는 new 를 생성 하지 않게 해서
불필요하게 new 및 delete를 최소화 시킨다는 말인데 ``
약간 오해하신듯 ``
A()안에 B를 생성하는것보다
B의 포인터 만 얻어와서 엎어 쓰심이라고말했는데. ``
stack 과 heap 의 차이는 수명이지 퍼포먼스가 아닙니다.
물론 아키텍쳐나 컴파일러의 구현에 따라 퍼포먼스가 다를 수 있지만 일반화시켜서 말할 수는 없습니다. 뭐 보통은 heap allocation/deallocation (new/delete)의 overhead 때문에 stack이 약간 빠를 수 있다고 말은 하지만 보통의 경우엔 프로그램 전체의 퍼포먼스에서 보면 별 차이가 있다고 생각하지 않습니다.
여기서는 A 가 B 를 소유하고 있는 경우인데, new B 로 B를 생성하게 되면 A 가 stack 에 있던지 heap 에 있던지 B는 무조건 heap 에 생성됩니다. 하지만 A를 local scope에서 쓰기 위해 그냥 a=A; 처럼 만든다면 A가 소유하고 있는 B의 object 가 heap에 가야 할 이유는 일반적으로는 없죠. 하지만 두 가지 예외가 있습니다.
첫번째 예외는 A 가 죽어도 B가 살아 있어야 하는 경우입니다. 이 경우는 B의 포인터를 나중에 누군가에게 넘겨 주거나, 아니면 애초에 다른 누군가에게서 넘겨 받은 경우이죠. 이렇게 논리적으로는 A가 B를 소유하고 있지만 B의 본체는 A의 바깥에 있고 A는 단지 B를 참조하게 되는 형태를 aggregation이라고 합니다. 반면에 A가 B를 완전히 내부에 소유하게 되는 (그래서 A가 죽으면 B가 죽는게 당연한 형태)를 composition 이라고 부릅니다. 즉 new를 사용해 B를 만든다는 것은 B를 누구에서 넘겨 받을 수 있거나 (그래서 누가 주지 않는 경우 default로 생성하거나) 하니면 A가 죽고 나서도 B가 살아 있어야 하는 이유가 있는 경우입니다.
두번째 예외는 B가 커서 stack 메모리에 들어갈 수 없는 경우입니다. 보통 1MB정도 되는데 이보다 크면 heap 에 생성해야겠죠.
댓글 달기