달력

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
  •  
  •  
  •  
  •  
  •  




이번 항목부터 리소스 누수, 예외처리에 대한 이야기가 펼쳐진다.
와~ 신난다.

본론으로 바로 들어가자.

1. 데이터를 받아서, 기록하려 한다.

2. 데이터를 파일에 저장되어 있다.

3. 파일안에는

"개"
"고양이"
"코끼리"
...

여러 동물들에 대한 이름과 정보가 들어가 있다.

다음과 같은 상황에서 DB를 구축한다고 하였을 때,

AAA라는 추상 클래스를 생성 -> ex) "동물"

AAA를 상속받은 BBB 클래스 -> ex) "개"
AAA를 상속받은 CCC 클래스 -> ex) "코끼리"
AAA를 상속받은 DDD 클래스 -> ex) "고양이"

라고 한다면,

다음 클래스가 대충 이해가 갈 것이다.


복잡하려나--; 가능한 쉽게 한다고 하는데..
뭐, 정 복잡하면.

이 부분만 봐도 된다.

readAAA 안에서는 새로운 객체를 생성하여
return AAA* 를 하게 되는데,
만약.

이 부분에 예외가 발생하면 어떻게 될까?
delete 부분은 수행되지 않을 것이고.
메모리 누수가 발생할 것이다.

그래서 예지력이 뛰어난 우리는 누수를 막기 위해,
다음과 같은 예외처리를 삽입하였다.

아 정말 뛰어난 예외처리다. 이제 문제가 발생해도,
메모리 누수가 일어 나지 않을꺼야.
라고 좋아 하고 있는데,
뭔가 이상하다.
만약 pa의 이름이 바뀌어서.
pa2가 되었다면.
catch안에 있는 pa도...
밖에 있는 pa도, ps2로 바꿔주는 귀찮음이 생길 수 있고.
delete pa 를 2번 쓴다는것 자체가 뭔가 무의미 하고 복잡하게 느껴진다.

라고 생각이 든다고 한다.(진짜?)
즉, 수정하고 나니 뭔가 잘못된 것 아니야? 라고 느낀다는 것이다.

쉽게 말해, 예외가 발생하든, 발생하지 않든.
pa는 삭제 되어야 한다는 것이고
구지 2번 쓸 필요 없이 다른 방법을 찾아 보자. 라는것이다.

먼저 그 해결책에 대해서 2가지 방법을 제시 하고 있는데,

그 첫번째. 스마트 포인터.

자세한 내용은 후에 항목에서 소개가 될테니 넘어가고.

쉽게 이야기 하면,
자신의 유효범위를 벗어나면 자신이 가리키고 있는 메모리를 삭제 할 수 있는 "포인터처럼 동작하는 객체"라고 한다.

일단 c++ 라이브러리에는 auto_ptr 이라는 "그런 일"을 하는 객체가 이미 정의되어 있다고 한다.
대충 개념만 따지면 다음처럼 말이다.

"보고 있나 플머?"
뭐 여튼, 포인터 같이 활동하는 객체 라는것을 주의하면서
생성자, 소멸자를 통해 메모리 누수를 막고 있다는 것을 파악하면 된다.

책에서는 "사실, 단순 데이터를 보관하는거면 그냥 stl의 vector를 쓰세요."
라고도 말 하고 있지만....;;
일단! 다음과 같이 auto_ptr이라는 객체를 통해
기존의 코드는 이처럼 바뀌게 될 것이다.

자, 이렇게 함으로써,
pa->process();
에서 예외가 발생하더라도, 메모리 누수는 발생하지 않을 것이다.
"보고 있나 플머?"ㅋ

또한, 이와 같은 형식으로 해결 하는 또 하나의 누수 막기 스킬이 존재 한다고 하는데,
이는 window handle 에서도 사용할 수 있다고 한다.
코드를 보자.

이 코드의 문법상이나 올바름을 보지 말고.
흐름을 보도록하자.
핸들을 통해 window를 생성하고.
작업을 진행하고.
해제하는 일을 하는 함수인 displayInfo는.
예외가 발생하면 리소스 누수를 일으킬 수 있는 여건을 가지고 있다.

이와 같은 부분에 대해서 해결책은 auto_ptr과 매우 흡사하다.
바로 코드를 보도록 하자.

마찬가지로 흐름을 보자.
문법은 조금 옳바르지 않을 수 있다.
여튼, 다음처럼 windowhandle을 받는 클래스를 생성하였고.
이제 displayInfo는 메모리 누수를 일으키지 않을 것이다.

auto_ptr과 마찬가지로 추가적인 delete 작업,
즉, destroyWindow는 하지 않아도 된다.

이 처럼, 이번 항목에서 의미 하는 것은,
예외가 발생하였을 때 생기는 메모리 누수를 막기 위해선,
해당 객체를 그냥 포인터로 선언하지 말고,
생성과, 해제를 포괄적으로 담당하는 객체를 생성하라는 것이다.

하지만 이런 부분에 대해서도 문제는 존재 하는데,
바로, 소멸자에서 리소스를 자동으로 해제하다가 생기는 예외처리.

이 부분에 대해선 항목 10, 11에 대해서 다시 언급한다고 하니.
일단 이번장에서 배운것 부터 재대로 기억하고 있자.
Posted by 안식의후크



흔히 쓰는, ++, -- 연산자에 대해서 설명하고 있는 항목이다.

i++이나, ++i냐,
i--이냐, --i냐...
이것의 원리를 좀 알아 보고자 하는거 같다.

역시나 가장 기본은,
사용 후 더하느냐,
더한 후 사용 하느냐.

라고 보면 되겠지만
조금 자세히 파보자.

먼저 i++, ++i의 차이인데,
증가, 감소 연산자는 전위형태이든, 후위형태이든, 인자를 받지 않는(사용하지 않는) 구조이다.

그렇기 때문에 오버로딩을 하기 위해서 걸리는 매개변수의 타입이나, 갯수등으로 구별 하기가 까다로워 진 것이다.

이를 위해 약속한 것이,
전위는 그냥두고, 후위 형태는 int 타입의 인자를 받는 것으로 하자.
라고 약속하였다고 한다.

다음과 같이 말이다.

다음은, 전위, 후위 형태의 내부 구조이다.

쉽게 말해서 전위, 후위를 나누기 위해 후위의 경우 인자 int를 받고 있지만,
전혀 의미가 없다는 것을 알 수 있다.

이제 내부 구조를 조금 살펴 보면,
후위 구조의 경우 return 값이 const를 가지고 있다.
쉽게 말해서 i++++; 을 방지 하기 위해서 이다.
저 i++++을 사용한 의도가 뭘까?
i+=1 이후 계산 한 다음..? ++?
아니면 i +=2 이후 계산?
어떻게 생각해도 애매한 코드이다. 그런 부분을 일절 용납 하지 않겠다는 것이다.

마지막으로, ++i, i++ 뭐가더 빠를까?
물어볼 것도 없다. 당연히 ++i 가 더 빠른 것이다.
이리저리 뺑 돌아가긴 했지만, 결국 여기서 의도한 것은
가능하면 i++ 을 쓰지 말고 ++i을 써라,
어차피 후위 연산자를 사용하면, 전위 연산자를 지나칠 수 밖에 없기 때문이다.

Posted by 안식의후크




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

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




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


다음 예제를 보자.

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

explicit

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

Posted by 안식의후크




차암.. 이 부분은 읽으면 읽을 수록,
"아. 어쩌라고 ㅋㅋ"
라는 말이 절로 나온다.

쉽게 풀어 설명하면,


다음과 같은 클래스가 있다고 치자.
사용자는 무언가 생성할때 ID를 같이 초기화 하고 싶은것이다.
각 id는 중복 되서는 안되고, 고유의 id를 가지고 있다고 치자.
그렇기 때문에 생성할 때 id를 넣어 주는 식의 방법을 채택 하였는데,
문제는 이거다.

책에서는 여러 가지 방법들이 보여지는데,
이래저래 쭉 읽다 보면 결론은,
그냥 내비 둬라(?) ... 라는 결론이 나오게 되는데,
해결책의 첫번째에는, 생성을 객체의 배열을 포인터로써 생성한다는 방법인데,
사실 이 부분도, 결과적으론 최종 생성할때 생성자에 인자를 넣어 주는 방식이고,
(어찌 보면 괜히 메모리만 더 먹는거 같기도 하다.)
다음 부분은 기본 생성자를 생성하여 문제를 직접 해결하고,
추후에 값이 올바른지 그렇지 않은지 예외 조건을 넣으라는 것이다.
하지만 그 부분은 포퍼먼스가 많이 떨어지고, 다른 작업자가, 그런 예외 처리를 해주지 않을 수도 있다는 것이 단점,
근데 솔직히 내가 생각 했을 때 가장 편한건,
기본생성자를 하나 넣어주고, static이나, 전역 변수를 하나 잡아주어,
중복을 피하는 식으로 무작정 데이터를 삽입하는게 어떤가 싶은데,
내 예상 해결책은 다음과 같다.

하지만 이 부분에 문제점은 여전히 존재한다.
사실상, 어떤 값이 어떻게 들어 가게 될지 예측을 못한다는 것이다.
순차적으로 들어갈 수도 있고, 중간에 뛰엄뛰엄 들어갈 수도 있고..
의도한다면 중복된 값또한 넣을 수 있다는 것이다.

이 부분에 대해선 사실 정해진 답이 존재 한다기 보단,
생성자에 대해서 정확히 파악하고,
생길 수 있는 문제에 대해서 미리 한번 생각해 보라...
라는것을 말하고 있다고 생각한다.
Posted by 안식의후크




제목이 뭐랄까 복잡하지만, 내용을 보니 그정도 까진 아닌거 같다.

다형성이라는 정의를 좀 쉽게 설명하면,

"AAA 클래스를 상속받은 BBB 클래스가 있다.
그리고 AAA 클래스의 객체가 BBB 클래스를 접근하는 것이 가능하다. "

라고 표현 할 수 있겠는데...

아.. 써놓고 보니 쉽지 않은거 같기도 하고--;;

자세한 내용은 다형성에 대해서 "객체 포인터"라는 부분에서 정리를 예전에 해 두었으니 해깔리면

그걸 먼저 보는것이 나을 것 같다.

예제는 2가지정도 존재 하지만,
첫번째 예제만 봐도.
"아!... 위험하네." 싶다.


이런 상황이라고 하였을 때,
쉽게 프로그래머의 의도는, AAA arr[10]; 를 만든 이후,
그 값을 출력하기 위해 printAAA 를 만들었다고 보면 되겠다.
하지만,

다음과 같은 상황이 생겼을 때 문제가 발생하는 것이다.
물론 운이 좋게 컴파일러에서 미리 캐치를 해서, 값이 잘 보일 수도 있겠지만.
(실제로 내 컴파일러에서 출력에는 이상이 없긴 했다.)
문제는 delete 라던가, 다른 os나 pc 상황에서 분명 의도하지 않은 결과가 나올 수 있다는 것이다.
AAA의 메모리 크기는 8byte(예상) 라고 했을 때,
BBB의 메모리 크기는 8byte(AAA 클래스의 크기) + 8byte(BBB 클래스의 크기) 라는 것이다.
배열을 +1씩 증가 한다고 했을 때,
8byte씩 삭제 하다 보면,, 나머지 8byte는.. 과연 어디로 증발할지 아무도 모르는 것이다.
물론 BBB라는 클래스가 AAA를 상속받지 않거나, 존재하지 않는다면,
큰 문제가 없을 지도 모른다. 이와 관련되서 추후 항목에 다룬다고 하니, 그 때 다시 한번 확인하여 보자.
Posted by 안식의후크






먼저 static_cast, const_cast 부터 알아 보자.

다음은, dynamic_cast!!
마지막으로 reinterpret_cast이다.
사실 별거 아닌 부분들일 지도 모른다.
쉽게 생각해서 자신없으면 cast하지 않고, 있는 그대로만 잘 사용해도 왠만한 코드는 다 짤 수 있을 것이다.
하지만 알고 있는것과 모르는 것,
모르기에 사용하지 못하는것과, 알면서 사용하지 않는것은, 분명 차이가 있을 것이다.
cast부분에 대해서는 좀더 활용성을 찾아 보아야 할 것 같고,
이런 부분들은 추후 디자인 패턴에 대해 포스팅 할때 좀더 명확하게 집고 넘어 가려고 한다.
마지막으로 항목2 초반에 저자가 말하길, goto문과 같이 써서는 안되는 1급 기피대상이 cast(형변환) 이라고 한다.
하지만 무작정 안쓰는게 좋다기 보단, 적절한 상황에 적절하게...; 사용한다면 분명 안쓰는것 보단 나을 것이라 생각한다.
(애초에 사용해서는 안되는 것이라면 지원해 주는것 자체가 이상하지 않은가?)
이제 막 포스팅을 시작한 만큼, 더 많은 준비를 통해 좋은 발전의 결과를 내기 위해 노력할 생각이다.
Posted by 안식의후크





이번 새로 이력서를 넣기 위해 게임 동영상을 찍다 보니, 여기에 올리는것도 좋을것 같아서 올리게 되네 ㅎ
Posted by 안식의후크
2011.02.01 14:20

맵툴 시연용 영상 게임이야기/제작2011.02.01 14:20







'게임이야기 > 제작' 카테고리의 다른 글

포트폴리오 영상들.  (0) 2011.06.27
Catch Me If You Can_게임 동영상  (0) 2011.04.20
맵툴 시연용 영상  (0) 2011.02.01
KGCA 19기 졸업 프로젝트 -팀 : Pathfinder, 터치다운(함정을 달리다)-  (0) 2011.02.01
MapTool - Ver 1.0  (0) 2011.01.24
WrapUp!  (0) 2010.12.08
Posted by 안식의후크
2011.01.24 11:34

MapTool - Ver 1.0 게임이야기/제작2011.01.24 11:34






이번 졸작때 완성된 맵툴의 스크린샷.

'게임이야기 > 제작' 카테고리의 다른 글

맵툴 시연용 영상  (0) 2011.02.01
KGCA 19기 졸업 프로젝트 -팀 : Pathfinder, 터치다운(함정을 달리다)-  (0) 2011.02.01
MapTool - Ver 1.0  (0) 2011.01.24
WrapUp!  (0) 2010.12.08
MapTool - 완성본  (0) 2010.12.06
API-Catch Me If You Can  (0) 2010.06.10
Posted by 안식의후크




*어디까지나 제가 사용한 기준으로써, 저를 위한 포스팅입니다.

현재 SVN은 Tortoise SVN을 사용하고, 서버는 네이버 개발자 센터에 등록하여 사용합니다.

1. SVN 설치( Tortoise SVN )
2. 네이버 개발자 센터에 등록
3. 커밋, 업데이트 사용법


1. SVN 설치
[download] -> [TortoiseSVN 32-Bit (32비트) or TortoiseSVN 64-Bit(64비트)]
에서 SVN을 다운 받는다.

영문으로 쓰기에는 영어 실력이 많이 부족한 관계로, 하단에 보이는 한글패치를 받는다.
마찬가지로 32bit or 64bit 중 택해서 받는다.

다운 받은 SVN 설치
설치에서 특별한 부분은 없기 때문에, 그냥 Next, 설치 폴더등을 지정하여 설치를 완료한다.

2. 네이버 개발자 센터에 등록
프로젝트 생성을 하기 위해 [마이페이지] -> [프로젝트 등록]에서 이름, 아이디 설명등을 입력 후 프로젝트를 생성한다.

프로젝트 생성을 하면 약 10분 정도의 시간이 흐른 이후에 생성되니 주의.

프로젝트를 생성하고.
[회원정보] -> [코드저장소 비밀번호 설정]을 통하여 코드를 올릴때 필요한 암호를 설정한다.

3. 커밋, 업데이트 사용법
SVN에 커밋 & 업데이트할 폴더를 하나 생성한 이후
폴더안에서 마우스 오른쪽 버튼 ->[TortoiseSVN] -> [Setting] -> [한국어] 로 세팅
그 후 [SVN 체크 아웃] 네이버 ID : 코드 저장소 비밀번호 설정에서 설정했던 암호를 입력
커밋 & 업데이트를 사용 할 수 있다.


ps : 뭔가 자세히 적고 싶지만 orz 나도 잘 몰라서

기억나는것만 적었음.

'프로그래밍 > 자주 애용하는것' 카테고리의 다른 글

SVN - 간단한 설치법  (0) 2010.12.29
내가 쓰는 코딩용 글자 폰트  (0) 2010.03.15
visual assist 1738  (0) 2010.03.04
Posted by 안식의후크