달력

12

« 2018/12 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  
  •  




이번 항목은 타입변환에 대한 내용.

코드를 통해 문제점 부터 파악해 보자.




사실 코드만 보면 << 에 대한 연산자 오버로딩이 없기 때문에 안될거 같은데? 라고 생각하겠지만,
실제론 형변환이 이루어 지면서 출력이 된다.
이런 상황을 제거하기 위해, operator double가 아닌, 함수로써 변경을 하는 방법이 존재한다.


다음 예제를 보자.

다음과 같이, 암시적 변환을 사용하게 되었을 때는 원하지 않는 결과에 도출하게 된다.
물론 a == b[i]가 의도한 코딩이라면 상관없을지도 모르겠지만,
현재 상황에서 저 코드에 문제가 있다는 것을 시력이 좋거나,
런타임 후에 확인하거나,,
둘중 하나일 것이다.
코드를 하나하나 따라가 보면,
a 의 생성자에 10번,
operator==에 10번 들른다.
그 부분에 대해서는 항목 19에서 다시 설명한다고 한다.
자 문제는 파악 했고, 이제 저런 상황에서 우리가 원하지 않는 암시적 변환을 막고 싶다고 하였을 때,
어떻게 해야 할까? 답은 생각보다 쉬웠다.

explicit

이로써 이전에 if( a == b[i] ) 부분에서 컴파일 오류가 날것이다.
하지만 모든 문제가 해결된 것은 아니다.
비록 암시적 변환은 해결 됐지만,
명시적 타입 변환은 여전히 허용되는 것이다.
현재로썬 저런 어색한 부분에 대한 해결책은 언급하고 있지 않지만,
명시적 타입 변환이라고 해도, 이전에 이야기 했듯이 지나친 형변환은 지양하자는 말이 떠오르는 코드다.
이번 타입 변환과는 별개로, 2번째 if문에 존재하는 > > 사이의 공백에 대해 언급을 하고 있는데,
저곳에 공백을 넣지 않으면 operator >> 를 호출 한다고 하니, 주의하도록 하자.
(필자는 그냥 무조건 공백을 주는 습관을 가지고 있으니 괜찮다!)
이 후에는 explicit 를 지원하지 않는 컴파일러에서의 해결 방법을 이야기 하고 있는데,
안봐도 되지만, 내용이 프록시 클래스 라는 것에 대해 미리 이야기 하고 싶었던것 같다.
한번 그냥 훑어 보는 정도로 넘어가면 될듯.

Posted by 안식의후크
2010.03.24 16:57

explicit, mutable 프로그래밍/C++2010.03.24 16:57







명시적인 것만을 허용하는 explicit 키워드



예외를 허용하는 mutable 키워드

explicit 같은 경우에는 프로그래머가 원한다면 애용하는 것도 나쁘지 않다고 생각하지만,
mutable 같은 경우엔 차라리 없는게 나을지도 모르겠다.
const를 붙혀준 함수에서 꼭 데이터를 수정해야 하는가 하는 의문도 들고,
정말로 수정을 원한다면 차라리 const를 지워서 사용을 하던지 하는게 낫지 않을까??
책에 있길래 포스팅은 해봤지만 자주 할것 같이 보이진 않는다.
그냥 남이 썻을때 그런 의도가 있다는 것만 파악 할 수 있는 수준이면 충분할듯.

'프로그래밍 > C++' 카테고리의 다른 글

상속의 개념  (0) 2010.03.24
public: private: 그리고 protected:  (0) 2010.03.24
explicit, mutable  (0) 2010.03.24
static  (0) 2010.03.24
멤버 이니셜 라이저(member initializer)  (0) 2010.03.23
복사 생성자, 디폴트 생성자 그리고 디폴트 복사 생성자.  (0) 2010.03.21
Posted by 안식의후크