기본 콘텐츠로 건너뛰기

delete this

[16] Freestore management, C++ FAQ Lite (내 맘대로 번역)
[16.15] Is it legal (and moral) for a member function to say delete this?
[16.15] 멤버함수에서 'delete this'가 올바른 구문인가?

As long as you're careful, it's OK for an object to commit suicide (delete this).
주의 깊게 사용한다면, 객체가 자살하는 구문(delete this)은 괜찮다.

Here's how I define "careful":
어떻게 "주의 깊게" 사용하냐면:

  1. You must be absolutely 100% positive sure that this object was allocated via new (not by new[], nor by placement new, nor a local object on the stack, nor a global, nor a member of another object; but by plain ordinary new).
    이 객체는 new연산자(new[]도 아니고, new 오버라이딩도 아니고, 스택에 있는 지역 객체도 아니고, 전역 객체도 아니고, 다른 객체의 멤버변수도 아닌 순수 그 자체 new연산자)로 만들어진다는 100% 확신이 있어야한다.
  2. You must be absolutely 100% positive sure that your member function will be the last member function invoked on this object.
    'delete this'를 호출한 멤버함수는 이 객체에서 호출한 가장 마지막 멤버함수라는 100% 확신이 있어야한다.
  3. You must be absolutely 100% positive sure that the rest of your member function (after the delete this line) doesn't touch any piece of this object (including calling any other member functions or touching any data members).
    'delete this' 구문 다음에 호출되는 이 객체의 다른 멤버함수는 이 객체의 그 어떠한 것이라도 건들이지 않는다는(다른 멤버 함수호출이나 멤버 변수에 접근까지 포함) 100% 확신이 있어야 한다.
  4. You must be absolutely 100% positive sure that no one even touches the this pointer itself after the delete this line. In other words, you must not examine it, compare it with another pointer, compare it with NULL, print it, cast it, do anything with it.
    'delete this' 다음에는 그 어떠한 것(심지어 'delete this'를 호출한 멤버함수까지도)도 'this'포인터를 참조하지 않는다는 100% 확신이 있어야한다. 예로, this포인터를 시험하거나, 다른 포인터와 비교하거나, NULL과 비교하거나, 포인터를 찍어보거나, 다른 형변환을 하는 등 이 모든 것이 금지 대상이다.

Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor.
보통 이러한 주의사항은 'this'포인터가 가상 소멸자가 없는 부모 클래스의 포인터일 때 적용할 수 있다.


뭐, 한 마디로 '잘 쓴다면 상관 없는 구문이야~'라는 말이다. 문제는 '잘 쓴다면'이 꽤나 신경을 쓰게 만드니 문제다. 개인적인 취향으로 이러한 것은 머릿속 관리목록에 추가해야하는 녀석이기에 싫어한다. 정말이지 애초에 설계가 그렇게 만들어진 것을 어쩔 수 없어 떠안는 것이 아니라면 이런 것은 정말정말 쓰지 않았으면 하는 바이다.




덧글: 아무리 번역이 날림이라도 퍼가기 전에 알려줬으면 하는 바이다.

댓글

이 블로그의 인기 게시물

Bash Array, Map 정리

Bash에서 Array, Map에 대한 정리. (매번 찾기 귀찮) 찾아보진 않았지만, Bash에서 Array든 Map이든 동일하게 Map(C++에서 Unordered Map)으로 동작하는 것 같다. 왜냐하면, Array의 Index가 연속하지 않아도 동작한다. 그저 Key가 0 이상의 정수인 Map이랑 비슷하게 동작한다. 예) 1, 2, 3, 9, 10 Array # 생성 declare -a empty_array declare -a ar=(haha hoho baba "long string haha hoho") # 접근 echo "ar[0]=${ar[0]}" echo "all as array=${ar[@]}" # 큰따옴표 안에서 각 원소를 따로따로 전달한다. echo "all as one=${ar[*]}" # 큰따옴표 안에서 각 원소를 문자열 하나로 합쳐 전달한다. echo "indexes=${!ar[@]}" echo "indexes=${!ar[*]}" echo "length=${#ar[@]}" echo "length=${#ar[*]}" echo "last=${ar[-1]}" echo "last=${ar[@]: -1}" # 콜론 뒤에 빈 칸이 꼭 필요하다. 옛 방식 # 현재 상황 declare -p ar #(출력) declare -a ar=([0]="haha" [1]="hoho" [2]="baba" [3]="long string haha hoho") ar[100]=hello # 인덱스를 건너 뛰어도 동작한다. declare -p ar #(출력) declare -a ar=([0]="haha" [1]="hoho" [2]="baba" [3]=&

설치한 패키지에서 RPM 추출하기

오래된 패키지를 관리할 저장소가 없어졌고, 기존 패키지로 다른 서버를 세팅해야할 일이 생겼다면 RPM의 리패키지 기능을 이용해보자. $ rpm -e --repackage [PACKAGE_NAME] 위와 같이 리패키지하면, /var/spool/repackage/ 에 생성한 RPM파일이 있다. :-)