블로그 이미지
대갈장군

calendar

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

Notice

'목록들'에 해당되는 글 157

  1. 2010.03.18 The Boost.Threads Library2
  2. 2010.03.11 FBO (FrameBuffer Object) 사용하기2
  3. 2010.03.11 프로그램의 원리 (컴파일, 링크, DLL)
  4. 2010.03.11 싱글 스레드에서 멀티 스레드로... 왜 /MD 인가?
  5. 2010.03.06 유니코드 (Updated!)4
  6. 2010.03.06 언니가 최고에요오오오오~ 이히히히히
  7. 2010.03.05 Managed 코드, Unmanaged 코드 그리고 Native 코드에 대한 이야기3
  8. 2010.02.26 The Ten Man Experience!
  9. 2010.02.24 Convex Hull, Concave Hull
  10. 2010.02.24 OpenGL 블렌딩3
  11. 2010.02.24 레이져 빔으로 모기 죽이기
  12. 2010.02.23 크레용 미사일 발사도전기
  13. 2010.02.23 진실 = 변하지 않는 마음
  14. 2010.02.23 OpenGL Viewing - Viewing, Modeling, Projection, Viewport transformation2
  15. 2010.02.19 glPolygonMode()와 glCullFace()
  16. 2010.02.19 개+사람?
  17. 2010.02.18 Finding Convex Hull (Graham's Scan) - 외곽선 찾기, 임의의 사각형 내부에 임의의 점 존재 확인8
  18. 2010.02.18 Alaska
  19. 2010.02.18 OpenGL Rendering Pipeline
  20. 2010.02.03 기도2
  21. 2009.12.19 객체 지향의 이해 1 - 클래스
  22. 2009.11.24 '무한도전' 논란에 대한 내 생각1
  23. 2009.11.21 네이비 필드 대박!2
  24. 2009.11.17 윈도우 - 차일드, 팝업
  25. 2009.11.17 윈도우 - SetClassLongPtr(), SetWindowLongPtr()
  26. 2009.11.17 윈도우 - WNDCLASS 구조체
  27. 2009.11.17 윈도우 - CreateWindow()
  28. 2009.09.10 x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e69679896
  29. 2009.07.30 C/C++ 메모리 오류에 대하여1
  30. 2009.07.28 STL (Standard Template Library)
2010. 3. 18. 06:25 프로그래밍/C++

불과 몇년 전만 하더라도 멀티 스레드를 사용하는 프로그램은 드물었다. 오늘날의 인터넷 서버 프로그램은 다수의 클라이언트 연결을 위해 여러개의 스레드를 이용한다. 효율과 생산성을 최대화 하기 위해서 트랜잭션 서버들은 분리된 여러개의 스레드를 이용하곤 한다. GUI 프로그램 또한 오랜 시간이 걸리는 작업은 분리된 스레드를 통해 백그라운드로 작업을 하면서 동시에 사용자의 입력은 실시간을 받아들인다. 이런식으로 나열하면 수도 없이 많다. 그만큼 멀티 스레드는 보편화 되었다는 것.

기존의 C++ Standard는 멀티 스레드에 대해 언급조차 하지 않는다. 심지어는 프로그래머에게 멀티 스레드 C++ 프로그램이 작성 가능한지 조차 알려주지 않는다. (과거 C나 C++ 은 멀티 스레드 환경에서 설계 되지 않았기 때문) 물론 기본적인 함수를 이용한 멀티 스레드 프로그램이 작성 불가능 한것은 아니지만, 프로그래머는 그럼에도 불구하고 운영체제가 지원하는 스레드 관련 라이브러리를 이용해서 작성한다. 자, 이것은 두가지 문제를 가지고 있다. 우선, 이 운영체제에서 제공하는 라이브러리들은 거의 C 라이브러리들인데다가 C++에서 사용시에는 주의해야 한다. 그리고 각각의 운영체제는 자신만의 멀티 스레드 조작 함수를 사용한다는 것이다. 이렇게 만들어진 코드는 우선 'Non-Standard(비기준)' 인데다가 'Non-Portable(비호환성)' 이다. 운영체제마다 쓰는 함수가 다르니 윈도우에서 돌리던 프로그램 유닉스에서 돌리려면 코드를 다 뜯어 고쳐야 한다는 말... 고로, Boost.Therads 라는 라이브러리를 만들었다는 말이다. 이 두 문제를 한방에 해결하기 위해서...

Boost는 C++ Standards Committee Library Working Group의 멤버들이 C++의 새로운 라이브러리를 만들이 위해 시작되었다. 현재 대략 2000명이나 된다구. 수많은 boost의 라이브러리를 thread-safe 하게 사용하기 위해서 바로 이 Boost.Threads가 만들어 졌다...

많은 C++ 전문가들이 Boost 디자인을 위해 생각들을 내어놓았고 인터페이스는 바닥부터 차근 차근 설립한 기초공사부터 시작했단다. 걍 원래 있는 C 스레드 API 함수를 가져다 쓰는게 아니라 이말이다. 많은 C++의 특징들이 흡수되었고 (예로 생성자, 파괴자, 함수 객체, 템플릿등) 인터페이스를 보다 유연하게 만들었다. 현재 Boost가 돌아가는 환경은 POSIX, Win32, Mac 등이래요. 뭐 거의 크로스 플랫폼을 달성했다고 봐도...

Thread Creation

boost::thread는 std::fstream 클래스가 파일을 표현하는 것과 같은 방식으로 스레드의 실행을 표현한다. Default 생성자가 현재의 실행 스레드를 나타내는 객체를 생성한다. 오버로딩된 생성자는 입력 변수가 없고 리턴하는 것이 없는 함수 객체를 받는다. 이 생성자는 새로운 실행 스레드를 시작하는데 이는 결국 함수 객체의 호출이며 해당 함수의 호출이다.

첫눈에 보기에는 이 방식의 디자인이 기존 C의 방식보다 후져 보인다. 왜냐면 기존 C는 void 포인터를 새 스레드 생성시 데이터를 넘겨주기위해 사용할 수 있기 때문이다. 하지만 Boost.Threads는 함수 포인터 대신 함수 객체를 사용하기 때문에 이 함수 객체가 스레드에 필요한 데이터를 소유 할 수 있다. 이 접근법은 타입 점검을 정확히 하며 보다 유연하다. 다른 함수 라이브러리들, 예를 들어 Boost.Bind와 같은 것과 연동되면 이 방식은 어떤 형태의 데이터라도 (많든 적든) 새로 만들어진 스레드로 전달하기가 매우 쉽다. 

현재로써 Boost.Threads로 할수 있는건 많지는 않다. (이 글이 작성된게 2002년인걸 감안하면 이렇게 말할만도 하다.) 사실 딱 두개의 연산자만 사용할 수있다. (지금은 바뀌었겠지?) == 과 != 연산자를 이용하면 간단하게 같은 스레드인지 아닌지 확인 가능하다. 그리고 boost::thread::join을 이용하면 스레드가 작업을 다 할때까지 기다릴수 있다. 다른 스레드 라이브러리들은 스레드와 관련된 다른 작동을 할 수 있게 도와 준다. (예를 들면 우선순위 설정) 

아래 리스트 1은 아주 간단한 boost::thread 클래스의 사용을 보여준다. 새로운 스레드가 생성되고 이 스레드는 아주 간단한 hello() 함수를 호출한다. 이걸 하는 동안 main 스레드는 대기한다. 
#include <boost/thread/thread.hpp>
#include <iostream>

void hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } int main(int argc, char* argv[]) { boost::thread thrd(&hello); thrd.join(); return 0; }

VS 2008으로 위 코드를 돌려봤더니 잘 돌아간다. 그리고 실행중에 디버깅을 해보면 아래 그림에 나온 것 처럼 hello() 함수 호출후 join 함수로 스레드 실행의 완료를 기다린후 return 0; 바로 직전에 브레이크 포인트를 자세히 보면 친절하게도 '이 프로세스나 스레드는 바로 직전에 변경되었습니다.'라고 알려준다. 참 친절하신 VS 2008. :)

 

Mutexes

멀티 스레드의 최대 약점은 자원 경쟁에 의한 오작동이다. 프로그램 짜본 사람이라면 누구나 알것이다. 이것은 두개 이상의 스레드가 동시에 공유된 자원에 접근하여 데이터를 변경할때 발생하는 데이터의 부정확성과 불일치를 말한다. 이것을 방지하기 위한 여러방법중 하나가 바로 Mutex 다른말로 하면 Mutual Exclusion (상호 배타)이다. 이 뮤텍스는 오직 하나의 스레드만이 공유자원에 지정된 시간에 접근하도록 만든다. 고로, 스레드가 공유 자원에 접근하기 위해서는 우선 뮤텍스를 'lock' 해야 한다. 즉, 공유자원이라는 집안에 들어가서 문을 걸어 잠그는 것이다. (다른 놈 못들어오게) 

뮤텍스의 컨셉은 여러가지가 있는데 Boost.Threads가 지원하는 가장 큰 두개의 카테고리는 Simple Mutex와 Recursive Mutex다. Simple Mutex는 말그대로 단순한 뮤텍스로써 오직 한번만 잠글수 있다. 만약 자신이 잠근 뮤텍스를 또 다시 잠글려고 하면 바로 데드락이 걸리고 이것은 '무한 대기(데드락)' 상태를 유발한다. 반면 Recursive Mutex (한국어로 말하면 재귀 뮤텍스이군)의 경우는 하나의 스레드가 뮤텍스를 여러번 잠글수 있으나 대신 반드시 잠근 횟수만큼 풀어야 다른 스레드가 공유자원을 사용할 수 있다는 것이다. 집에 들어와서 자물쇠를 현관문에 100개 달았으면 100개 다 풀어야 남이 들어온다는 이야기.

이 두가지의 카테고리 내부에서 또 여러가지 형태로 나뉘는데 이것은 어떤 식으로 뮤텍스를 잠그느냐에 따라 나뉜다. 세가지 방법으로 뮤텍스를 잠글수 있는데,
  1. 다른 스레드가 뮤텍스를 잠그지 않을때까지 대기
  2. 만약 다른 스레드가 뮤텍스를 잠궈놓은 상태라면 바로 리턴하기
  3. 다른 스레드가 뮤텍스를 잠그지 않을때까지 대기 하거나 혹은 일정 시간만 대기 하다가 리턴
최고의 뮤텍스 타입은 아무래도 recursive 타입인데 이 것은 위의 세가지 잠그기 방식을 모두 지원하기 때문이라는데... 반면 좋은 대신 오버헤드가 크다는 단점이 있다. 아무튼, 총 여섯 가지의 뮤텍스를 사용자가 선택가능하며 다음과 같다. 

boost::mutex
boost::try_mutex
boost::timed_mutex
boost::recursive_mutex
boost::recursive_try_mutex
boost::recursive_timed_mutex.

데드락은 매번 뮤텍스를 잠글때마다 잠근 횟수만큼 풀지 않았을때 발생한다. 이것이 가장 흔한 데드락의 한 종류인데 Boost.Threads는 이 데드락을 최대한 최소화 시킨다. (발생 할 수는 있다는 이야기) 어떤 뮤텍스이건 간에 직접적인 뮤텍스 잠금 및 해제 함수는 없다. 즉, 간접적인 방식으로 잠그고 푸는데 이것이 안전성을 높인다는 이야기. 이걸 Scoped Lock 이라고 한다는데 Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. Pattern-Oriented Software Architecture Volume 2 Patterns for Concurrent and Networked Objects (Wiley, 2000) 를 참조하라고 해놨다. 헤헤, 거의 논문 수준이다. :)

아무튼, C++이 기본적으로 예외 발생시나 객체 파괴시 항상 파괴자를 호출하므로 파괴자에 뮤텍스를 풀어주는 장치를 둠으로써 이런 데드락을 줄인다는 이야기 란다. 다만 주의 할 것은 이 Scoped Lock 패턴이 비록 풀어주는 건 확실히 풀어주지만 예외가 발생해서 풀어졌을 경우 공유자원이 변경되었을 가능성이 있단다. 
 
아래의 코드는 간단한 뮤텍스 사용법을 보여준다.
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <iostream>

boost::mutex io_mutex;

struct count { count(int id) : id(id) { }

void operator()() { for (int i = 0; i < 10; ++i) { boost::mutex::scoped_lock lock(io_mutex); std::cout << id << ": " << i << std::endl; } }

int id; }; int main(int argc, char* argv[]) { boost::thread thrd1(count(1)); boost::thread thrd2(count(2)); thrd1.join(); thrd2.join(); return 0; }

위의 코드를 보면 thrd1과 thrd2라는 스레드를 생성하여 메인 스레드는 이 두 스레드가 끝날때까지 대기한다. 이 두 스레드는 count라는 구조체를 호출하는데 이 구조체 내부에 std::cout 함수가 호출되어 0에서 9까지의 숫자를 출력한다. 재미있는 것은 이 std::cout은 이른바 공유 자원이다. 화면에 글자를 출력해내는 함수는 한순간에 오직 하나의 스레드에 의해서만 점유되어야 함이 마땅하다. 고로 이 프로그램을 돌려보면 다음과 같이 각각의 스레드에 대해 0에서 9까지의 출력이 차례대로 나온다. 


헌데 만약 위 코드에서 뮤텍스를 잠그는 명령을 쏙 빼버리면 다음과 같은 결과가 나온다. 


잘 보면 thrd1의 "1"을 출력한후 스레드가 변경되어 thrd2의 "2: "를 출력한 후 다시 thrd1로 변경되어 ": 0"를 출력한 후 또 다시 thrd2로 변경되어 "0"을 출력한다. 이렇게 규칙성있게 출력되는 이유는 분명히 CPU가 공정하게 스레드에게 실행 시간을 나눠주기 때문일 것이다. 두 스레드가 같은 우선순위를 가지므로 둘이 똑같이 CPU 시간을 나눠 받는 것이다. 

그리고 위 코드를 다시 보면 함수 객체를 작성하는데 이거 매번 하려면 굉장히 불편하다. 이럴때 사용할 수 있는 것이 Boost.Bind란다. 다음 코드를 보면 새 함수 객체를 바인딩을 통해 값을 전달하여 생성하는 예를 보이고 있다. 

Listing 3: Using the Boost.Bind library to simplify the code in Listing 2

// This program is identical to
// listing2.cpp except that it
// uses Boost.Bind to simplify
// the creation of a thread that
// takes data.

#include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <iostream>

boost::mutex io_mutex;

void count(int id) { for (int i = 0; i < 10; ++i) { boost::mutex::scoped_lock lock(io_mutex); std::cout << id << ": " << i << std::endl; } } int main(int argc, char* argv[]) { boost::thread thrd1(boost::bind(&count, 1)); boost::thread thrd2(boost::bind(&count, 2)); thrd1.join(); thrd2.join(); return 0; }


Condition Variables

종종 걸어 잠그기 만으로는 충분하지 않은 경우가 있다. 즉 뮤텍스만으로는 해결 안되는 상황을 말한다. 어떤 자원이 있는데 그 자원을 사용하려면 반드시 특정 상태가 되어야 한다고 치자. 예를 들어 임의의 데이터가 네트워크를 통해서 들어오기를 기다려야 하는 상황이 있다면 뮤텍스는 이런 형태의 점검을 지원하기에는 적합하지 않다는 말이다. (아래를 보면 이해가 될것, 왜 뮤텍스로는 부족한지) 그래서 다른 형태의 동기화가 필요한데 이것이 바로 '조건 변수 (Condition Variable)'를 이용하는 것이란다.

하나의 조건 변수는 항상 뮤텍스와 공유 자원 사이에 접합 지점에서 사용이 된다. 하나의 스레드가 먼저 뮤텍스를 잠그고 난 다음 공유자원이 적합한 상태인지를 체크하게 된다. 만약 해당 상태가 아직 원하는 상태가 아니라면 스레드는 대기한다. 이 대기 상태에서 스레드는 뮤텍스를 풀어줌으로써 다른 스레드가 공유자원에 대해 남은 일을 처리하여 적합한 상태 (Ready 상태)로 변경할 수 있게 된다. 이것이 바로 조건 변수가 필요한 이유. 무한 대기가 아닌 조건 대기. 또한 이것은 스레드가 대기 상태에서 복귀할때 바로 뮤텍스를 걸어 잠그는 것까지 한다. 다른 스레드가 공유자원에 대한 작업을 마쳐서 조건 변수의 상태를 변경하게 되면 이것을 즉각적으로 대기하던 스레드에게 알려준다. 그로써 대기중인 스레드는 바로 복귀함과 동시에 완료된 공유자원에 뮤텍스를 이용해 잠근다. 

생각보다 현명한데? :) 조건 변수라고 하길레 그냥 정적 변수 하나 선언해 놓고 true / false 값 판단인줄 알았는데 제법 인공지능을 가지고 있다. 
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition.hpp>
#include <iostream>

const int BUF_SIZE = 10; const int ITERS = 100;

boost::mutex io_mutex;

class buffer { public: typedef boost::mutex::scoped_lock scoped_lock; buffer() : p(0), c(0), full(0) { } void put(int m) { scoped_lock lock(mutex); if (full == BUF_SIZE) { { boost::mutex::scoped_lock lock(io_mutex); std::cout << "Buffer is full. Waiting..." << std::endl; } while (full == BUF_SIZE) cond.wait(lock); } buf[p] = m; p = (p+1) % BUF_SIZE; ++full; cond.notify_one(); }

int get() { scoped_lock lk(mutex); if (full == 0) { { boost::mutex::scoped_lock lock(io_mutex); std::cout << "Buffer is empty. Waiting..." << std::endl; } while (full == 0) cond.wait(lk); } int i = buf[c]; c = (c+1) % BUF_SIZE; --full; cond.notify_one(); return i; } private: boost::mutex mutex; boost::condition cond; unsigned int p, c, full; int buf[BUF_SIZE]; };

buffer buf;

void writer() { for (int n = 0; n < ITERS; ++n) { { boost::mutex::scoped_lock lock(io_mutex); std::cout << "sending: " << n << std::endl; } buf.put(n); } } void reader() { for (int x = 0; x < ITERS; ++x) { int n = buf.get(); { boost::mutex::scoped_lock lock(io_mutex); std::cout << "received: " << n << std::endl; } } } int main(int argc, char* argv[]) { boost::thread thrd1(&reader); boost::thread thrd2(&writer); thrd1.join(); thrd2.join(); return 0; 

}위 코드의 클래스는 FIFO 버퍼를 추상화했는데 내부 private 멤버 변수인 mutex를 사용해서 스레드에 안전하게 설계되었다. put과 get 함수는 condition variable을 사용하여 스레드가 적합한 상태로 공유자원이 변경되도록 기다리게 했다. 두 스레드가 만들어지면 하나는 100개의 정수를 이 버퍼에 넣고 다른 하나는 하나씩 빼낸다. 허나 이 버퍼는 최대 10개까지만 대기할 수 있으므로 두 스레드스 서로 기다려 준다. 잘보면 전역변수로 io_mutex를 선언하여 std::out에 대해서 뮤텍스를 사용함을 알수 있다. 

Thread Local Storage

 이 놈은 예전에 내가 다른 글에서 언급한 놈이다. http://diehard98.tistory.com/entry/프로그램-프로세스-스레드 를 보면 왜 TLS가 필요한지 설명하고 있다. 기본적으로 함수들은 재진입을 염두하지 않는다. 고로 하나의 스레드가 호출중인 함수를 다른 스레드가 또 호출하면 '불안정한' 상태가 될 수 있다는 의미. 재진입을 고려하지 않은 함수는 정적 데이터를 유지하는데 대표적인 예로 std::strtok가 있다. 이 놈은 재진입이 불가한데 왜냐면 함수가 호출되면 실행 동안에 정적 변수에 값을 저장해 놓기 때문이다. (고로 다른 스레드가 실행 와중에 다시 그 함수를 호출하여 사용하면 같은 정적 변수에 또 다른 값을 덮어 씌워 버릴것이다.)

이런 재진입이 불가한 함수들은 두가지 방법으로 재진입이 가능한 함수로 바꿀수 있다. 우선 첫번째는 포인터나 레퍼런스를 받아서 정적 변수를 사용하던 방식을 바꾸는 것이다. 예를 들어 POSIX의 strtok_r 함수는 std::strtok의 재진입을 가능하게 만든 함수로 이 함수는 입력 변수로 정적 변수를 사용하는 대신 char** 을 받는다. 이 해결법은 쉽고 좋다. 그러나 이렇게 하면 모든 공개된 인터페이스 (호출 방식)을 바꿔야 한다. 즉, 많은 코드의 변화를 가져온다는 이야기. 이 방법 말고 다른 방법인 두번째 방법이 바로 스레드에 독립적인 저장 공간을 주는 방식이다. 스레드의 독립적인 저장공간을 영어로 Thread Local Storage 혹은 Thread-Specific Storage라고 한다.

TLS는 각 스레드 별로 할당되는 고유 공간이다. 멀티스레드 라이브러리는 이 독립공간을 임의의 스레드가 접근할수 있도록 인터페이스를 제공한다. 고로 각각의 스레드는 스레드 객체의 고유 데이터를 소유하게 된다. 이 말은 다른 스레드가 접근 할 수 없다는 말이고, 즉, 자원 경쟁으로부터 자유롭다는 말. 문제는, 이 TLS가 일반 데이터 엑세스보다 느리다는 점. 하지만 첫번째 방법보다는 편한데 왜냐면 인터페이스를 안바꿔도 되니까 코드 변경이 필요없기 때문이다.

Boost.Threads는 boost::thread_specific_ptr이라는 스마트 포인터를 이용해서 TLS에 각 스레드가 접근 할 수 있도록 도와준다. 스마트 포인터란 참조된 횟수를 스스로 계산하여 자폭하는 영리한 포인터를 말한다. 각 스레드는 우선 이 스마트 포인터의 객체에 접근하는데 이때 이 값이 NULL인지 먼저 확인해야 한다. NULL이면 초기화가 필요하다는 말. 그리고 Boost.Threads 라이브러리는 스레드 종료시 이 TLS를 알아서 청소해준다. 왜냐면 스마트 포인터니까~
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/tss.hpp>
#include <iostream>

boost::mutex io_mutex; boost::thread_specific_ptr<int> ptr;

struct count { count(int id) : id(id) { }

void operator()() { if (ptr.get() == 0) ptr.reset(new int(0));

for (int i = 0; i < 10; ++i) { (*ptr)++; boost::mutex::scoped_lock lock(io_mutex); std::cout << id << ": " << *ptr << std::endl; } }

int id; }; int main(int argc, char* argv[]) { boost::thread thrd1(count(1)); boost::thread thrd2(count(2)); thrd1.join(); thrd2.join(); return 0; }

위 코드를 실행해 보면 각 스레드 별로 1에서 10까지 출력한다. 그리고 당근 std::out은 뮤텍스로 보호!

Once Routines

이제 남은 것은 딱 하나. 어떻게 생성자를 멀티스레드에 안전하게 만드는가다. 예를 들어 전역으로 사용되는 객체가 있다면 멀티스레드 환경에서 주의해야 할 것은 이 객체가 오직 한번만 생성자를 호출해야 하며 스레드들이 동시에 생성자를 호출하는 것을 막아야 한다.

이 것을 해결하는 방법은 이른바 "Once routine" 이라는 방식의 사용이다. 이 것을 이용하면 해당 함수나 변수는 프로그램에 의해 오직 한번만 호출된다. 만약 다수의 스레드가 이 함수를 동시에 호출한다면 그들중 오직 하나만이 이 함수에 접근할 수 있다. 이것을 가능하게 해주는 방법은 바로 랩핑함수를 이용해서 한번 더 점검을 하는 거란다. 고로 멀티 스레드 환경에서 '오직 한번' 초기화하기 문제는 해결되었다. boost::call_once를 이용하면 되고 플레그 타입인 boost::once_flag를 BOOST_ONCE_INIT 매크로를 이용해 초기화 하면 된다네.

Listing 6: A very simple use of boost::call_once

#include <boost/thread/thread.hpp>
#include <boost/thread/once.hpp>
#include <iostream>

int i = 0; boost::once_flag flag = BOOST_ONCE_INIT;

void init() { ++i; }

void thread() { boost::call_once(&init, flag); } int main(int argc, char* argv[]) { boost::thread thrd1(&thread); boost::thread thrd2(&thread); thrd1.join(); thrd2.join(); std::cout << i << std::endl; return 0; }

뭐 위 코드를 보면 flag를 선언할때 BOOST_ONCE_INIT 매크로 사용했고 전역 변수 i를 두개의 스레드가 동시에 접근하는데 둘 다 call_once로 호출하므로 두 스레드중 오직 하나만 접근 하여 초기화 한후 값을 하나 증가 시킨다. 고로 다른 스레드는 해당 함수를 더 이상 호출 할 수 없으므로 출력 값으로는 1이 출력된다. 만약 두 스레드가 모두 변수에 호출가능 했다면 i 값은 2가 되어야 한다.

The Future of Boost.Threads

Boost.Threads를 위한 몇가지 계획이 있는데 추가될 놈으로 boost::read_write_mutex가 있단다. 이 것은 멀티 스레드들이 공유자원을 동시에 읽기 가능하게 하고 단, 쓸때는 한놈만 쓰게 한다. 그리고 추가로 boost::thread_barrier 라는 놈을 만들건데 이 놈은 특정 스레드들이 모두 특정한 위치까지 들어오도록 기다린단다. 흠... 용이하겠는데? 그리고 또 boost::thread_pool을 계획중인데 이 녀석은 스레드를 매번 생성 파괴하지 않고 짧은 실행을 비동기로 할 수 있게 해주는 놈이란다. 찾아보니 이 놈들 벌써 구현됬다... ㅋㅋㅋ

그리고 이 Boost.Threads는 차기 C++ 표준에 들어갈 수도 있다는 말과 함께 이 긴 글을 마무리한다...

추가로 참조된 책 및 웹사이트, 논문등

Notes

[1] The POSIX standard defines multithreaded support in what’s commonly known as the pthread library. This provides multithreaded support for a wide range of operating systems, including Win32 through the pthreads-win32 port. However, this is a C library that fails to address some C++ concepts and is not available on all platforms.

[2] Visit the Boost website at <http://www.boost.org>.

[3] See Bjorn Karlsson’s article, “Smart Pointers in Boost,” in C/C++ Users Journal, April 2002.

[4] Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. Pattern-Oriented Software Architecture Volume 2 Patterns for Concurrent and Networked Objects (Wiley, 2000).


이제 내가 이야기를 할 차례다. 일단 이 글쓴이에게 감사하는 바이다. 2002년에 작성된 글이라 오래된 느낌이 있지만 매우 영리하고 정확한 표현으로 이해를 돕는다. 그리고 중간중간 효과적인 소스코드로 더더욱 이해가 쉽게 해주었다.

Boost 라는 그 자체에 대해서 경이로움을 느낀다. C++이 멀티스레드에 약하다는 것은 잘 알고 있었지만 그것을 이렇게 잘 커버해주는 이런 대형 라이브러리가 있는지는 정확히는 몰랐다. 대단하다...

스레드의 생성과 선언 및 관리가 운영체제마다 다르기 때문에 윈도우에서 작성한 코드는 유닉스에서 안돌아 가지만 이 Boost 라이브러리를 이용하면 코드 변경 없이 가능하겠다. 그리고 스레드마저 객체화하여 클래스로 표현하므로 객체 지향에도 걸맞는다. 

오버헤드가 좀 있겠지만 객체로 표현한다는 장점에 비하면 적지 않나 싶다. 이 글이 너무 길어지면 곤란하므로 여기까지만 쓰겠다. 

posted by 대갈장군
2010. 3. 11. 03:47 OpenGL
FBO는 OpenGL에서 사용하는 '외부에 그리기' 기술중 하나로써 나도 종종 사용한다. FBO를 사용함으로써 사용자는 다양한 작업이 가능해 진다. 

대표적인 FBO 사용예로 그려질 scene 내부에 또 다른 scene을 그려야 할 때다. 집안에 있는 TV를 표현할 때 종종 이 방법이 사용된다. FBO의 장점으로는 간단한 셋업과 사용 그리고 context switching이 필요없다는 점 (오버헤드 적음) 각종 버퍼 (depth buffer, stencil buffer, accumulation buffer) 등을 사용할 수 있어 유용하다는 점 등이다. 


1. 셋업

우선 다른 OpenGL 객체와 마찬가지로 FBO 핸들을 받을 변수를 선언해야 하고 그 변수에 핸들을 생성해서 대입해야 한다. glGenFramebuffersEXT() 함수의 첫번째 인자는 glGenTextures() 함수의 첫번째 인자처럼 몇개나 만들건지 지정해주는 인자다.
GLuint fbo;
glGenFramebuffersEXT(1, &fbo);
명령을 수행하려면 바인딩 부터 해야 한다. 바인딩을 함으로써 다음에 이어지는 명령들이 바인딩한 객체에 대해 수행되도록 한다.
glBindFramebufferEXT
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
첫번째 인자가 Target 인자 인데 GL_FRAMEBUFFER_EXT는 고정된 것이라고 보면 된다. 물론 나중에 확장이 되면 다른 형태가 추가 될수 있지만 현재로서는 저 인자가 고정이라고 보면 된다. 두번째 인자로 앞서 정의한 핸들을 넘겨주면 오케이.

2. 깊이 버퍼 (Depth buffer) 추가

FBO 객체 자체로는 할 수 있는게 없다. 왜냐면 걍 객체(식별표)이니까... 이제 이 식별표에 실제적인 저장 공간(버퍼)들을 추가해 줘야 한다. 알다시피 OpenGL이 기본적으로 제공하는 Frame buffer도 깊이 버퍼, 스텐실 버퍼 등등으로 구성되어 있다. 고로 FBO 객체에도 Renderable (렌더링 가능한) 버퍼를 추가 시켜 주어야 한다. 이 버퍼로 사용가능한 것이 텍스쳐 또는 렌더버퍼 중 하나다. 

렌더버퍼는 FBO의 offscreen rendering을 지원하기 위한 객체이다. 적절한 텍스쳐 포멧을 지원하지 않는 스텐실 버퍼나 깊이 버퍼를 표현하기 위해서 사용하는 것이 바로 렌더버퍼 객체다. 이 예제에서는 렌더버퍼를 FBO의 깊이 버퍼로 사용할 것이다. 

그러니까 요약하자면, FBO는 OpenGL이 기본적으로 가지고 있는 깊이 버퍼, 스텐실 버퍼, 색상 버퍼등을 '연결'할 수 있는 객체인데 이때 이 연결 가능한 놈들은 두 종류로써 하나는 일반 텍스쳐이고 다른 하나는 '렌더버퍼(Renderbuffer)'이다. 일반 텍스쳐의 경우 색상 버퍼로 사용할 수 있으나 깊이 버퍼나 스텐실 버퍼와 같이 텍스쳐로 표현할 수 없는 버퍼들은 렌더버퍼를 이용해서 FBO에 연결한다는 말인듯 하다. 

아무튼, 일단 렌더버퍼를 생성하는 방법은 다음과 같다.
GLuint depthbuffer;
glGenRenderbuffersEXT(1, &depthbuffer);
depthbuffer라는 변수 (핸들을 받기위한)를 선언하고 generation 함수를 통해 렌더버퍼를 생성해 낸다. (그래서 함수 이름도 glGenRenderbuffersEXT() 이다. 

이제 이렇게 만든 렌더버퍼를 바인딩 시킴으로써 다음에 이어지는 일련의 명령이 depthbuffer 렌더버퍼에 대해 실행되도록 한다.
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
앞서 본 것과 마찬가지로 GL_RENDERBUFFER_EXT는 고정이라고 보면 된다. 그리고 두번째 인자로 앞서 만든 렌더버퍼의 핸들을 넘겨준다. 

자, 이제 해야 할 일은 이 깊이 버퍼의 크기를 지정해 주는 일이다. (폭과 높이 지정하기)
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, 
                         width, height);
이 과정은 일종의 메모리 할당이라고 보면 되겠네. 한가지 알아둘 것은 이 렌더버퍼는 기본 RGB/RGBA 저장용으로 사용가능하며 스텐실 버퍼로써 연결도 가능하단다. RGB/RGBA 저장 공간으로 사용될 수 있다는 점은 조금 신선하긴 하다만 텍스쳐를 사용하는 것이 더 유연할 것이라 생각된다.

다음은 이렇게 실제적으로 메모리를 할당한 깊이 렌더버퍼를 우리가 앞서 만든 fbo 객체에 가져다 붙이는 것이다. 
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, 
                             GL_RENDERBUFFER_EXT, depthbuffer);
위 명령이 좀 복잡해 보여도 실은 단순하다. 현재 바인딩 되어 있는 FBO 객체 (fbo)에 렌더버퍼 (depthbuffer)를 바인딩 하라.. 라는 말이다.

3. 렌더링 텍스쳐 추가하기

앞서 두 단계를 수행했지만 아직까지 FBO에 색상 버퍼를 추가하지 않았다. 이제 색상 버퍼를 추가 해야 하는데 이 색상 버퍼가 사실상 '내 눈에 보여질' 놈이다. 

이 색상 버퍼를 추가하는 방법은 두가지가 있다.
1. 색상 렌더버퍼를 FBO의 색상버퍼로 연결
2. 일반 텍스쳐를 FBO의 색상버퍼로 연결

첫번째 방법도 사용하기는 하지만 우리는 두번째 방법을 사용할 것이다. (앞서 2번에서 설명했듯이 렌더버퍼는 기본 RGB/RGBA를 저장하기 위한 버퍼로도 사용가능하다고 했다. 하지만 분명 일반 텍스쳐 보다는 범용성이 떨어질 듯하다.)

텍스쳐를 FBO에 연결하기 위해서는 당연히 텍스쳐 생성부터 해야 한다.
GLuint img;
glGenTextures(1, &img);
glBindTexture(GL_TEXTURE_2D, img);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8,  width, height, 0, GL_RGBA, 
             GL_UNSIGNED_BYTE, NULL);
이 과정은 일반적인 텍스쳐 생성 과정이다. 이때 주의 해야 할 한 가지 포인트는 폭과 넓이가 앞서 만든 깊이 렌더버퍼의 크기와 같아야 한다는 매우 상식적인 것이다. 

자, 이제 색상 버퍼로 사용될 텍스쳐를 만들었으므로 우리가 앞서 만든 FBO 객체에 연결하자.
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, 
                          GL_TEXTURE_2D, img, 0);
이 명령이 어렵게 보여도 실제로는 그닥 어렵지 않다. 우선 굵은 글자로 표시된 GL_COLOR_ATTACHMENT0_EXT가 좀 어렵게 보일지 모르나 이것은 OpenGL에게 어떤 color attachment point에 연결할 지를 명시해주는 인자일 뿐이다. FBO는 동시에 여러개의 색상 버퍼를 가질 수 있기 때문에 어떤 포인트에 연결할 지를 명시해야 한다. 하나의 색상 버퍼만 사용한다면 저 숫자 0은 당신에게 아무런 중요성이 없는 단순한 표식일 뿐이다. 그리고 GL_TEXTURE_2D는 우리가 2D 텍스쳐를 사용한다는 말이고 img는 사용할 텍스쳐의 핸들, 그리고 마지막 0은 mipmap level 이다. 

이제 FBO 완성을 위해 마지막으로 해야 할 일은 FBO가 잘 만들어 졌는지 체크하는 일이다. 다음 함수로 한방에 체크하자.
GLenum status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
모든 셋팅이 제대로 통과하였다면 GL_FRAMEBUFFER_COMPLETE_EXT를 리턴할 것이고 만약 에러가 있다면 다른 값을 리턴한다. 

4. 텍스쳐로 렌더링하기

이제 색상버퍼로 연결시켜 놓은 텍스쳐 (img)로 렌더링을 수행하는 방법을 알아볼 차례. 이건 상당히 쉬운데 걍 glBindFramebufferEXT() 함수만 호출하면 땡이다. 셋업이 조금 어려워서 그렇지 사용 자체는 굉장히 쉽다.

FBO로 렌더링 하기 위해서는 glBindFrameBufferEXT()를 호출하면 되고 렌더링을 멈추기 위해서는 같은 함수를 호출하되 인자값을 0으로 주면 된다.
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo); // FBO 바인딩
glPushAttrib(GL_VIEWPORT_BIT);                      
glViewport(0,0,width, height);                 // 여기서 부터는 텍스쳐에 렌더링한다.
// Render as normal here // output goes to the FBO and it’s attached buffers glPopAttrib(); glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // 언바인딩. FBO에 렌더링하기 중지
자, FBO를 바인딩함으로써 차후 수행되는 모든 그리기 명령은 우리가 설정한 FBO의 색상 버퍼, 깊이 버퍼, 스텐실 버퍼에 적용된다. 그리고 glPushAttrib() 와 glPopAttrib() 함수를 이용해 이전의 3차원 매트릭스 값들을 신속히 복구 및 적용할 수 있게 했다. 

중요한 것은, 다시한번 강조하지만, glBindFramebufferEXT() 함수 하나로 간단하게 FBO로 렌더링을 할 수 있다는 점이다. 앞서 셋업에서 수행했던 몇몇 버퍼 바인딩 및 연결과정은 더이상 필요없다. 

5. 렌더링 된 FBO의 색상 버퍼를 텍스쳐로 사용하기

이제 우리의 궁극적인 목표에 가까워 졌다. 왜 우리는 FBO에 렌더링을 수행했던가? 바로 이 단계를 위해서다. FBO 색상 버퍼에 그려진 그림은 곧바로 텍스쳐로 사용 가능하다. 즉, 집안에 있는 TV 속의 화면을 우리는 방금 FBO를 이용해서 그려낸 것이다. 이제 TV 안의 화면은 그렸으니 집을 그릴때 만들어 놓은 TV 속의 화면을 텍스쳐로 입히자.

알다시피 img 핸들에 FBO의 색상 버퍼가 연결되어 있으므로 이 텍스쳐를 사용하기 위해서는 우선 바인딩 부터 한다.
glBindTexture(GL_TEXTURE_2D, img);
그리고 FBO 밉맵 자동 생성 함수인 glGenerateMipmapEXT() 함수를 호출하자.
glGenerateMipmapEXT(GL_TEXTURE_2D);
한가지 주의할 것은 만약 내가 임의의 밉맵 필터 (GL_LINEAR_MIPMAP_LINEAR와 같은)를 사용할 것이라면 FBO에 연결될 색상 버퍼 생성시 반드시 glGenerateMipmapEXT() 함수를 호출해서 가능한지 여부를 체크해야 한다. 

이 경우, 아래의 명령대로 FBO의 색상버퍼를 생성하면 된다.
glGenTextures(1, &img);
glBindTexture(GL_TEXTURE_2D, img);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8,  width, height, 0, GL_RGBA, 
             GL_UNSIGNED_BYTE, NULL);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glGenerateMipmapEXT(GL_TEXTURE_2D);
img를 바인딩 했다면 이제 할 일은 바인딩한 텍스쳐를 원하는 곳에 그려넣기인데 소스 코드를 보면서 설명해 보면...

void display(void)   
{
// FBO 바인딩 - FBO에 렌더링 하겠다고 알려줌
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
// 각종 화면 관련 속성 저장해 놓기 - FBO에 렌더링 끝나면 이전값으로 복귀하기 위해서
glPushAttrib(GL_VIEWPORT_BIT);
glViewport(0,0,width,height);

// 이제 부터 회전하는 작은 큐브를 FBO에 그린다.
glClearColor(0.0f, 0.0f, 0.0f, 0.5f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();

glTranslatef(0.0f,0.0f,-2.0f);
glRotatef(xrot,1.0f,0.0f,0.0f);
glRotatef(yrot,0.0f,1.0f,0.0f);

glBegin(GL_QUADS);
// Front Face
glColor4f(0.0f,1.0f,0.0f,1.0f);
glVertex3f(-0.5f, -0.5,  0.5);
glVertex3f( 0.5, -0.5,  0.5);
glVertex3f( 0.5,  0.5,  0.5);
glVertex3f(-0.5,  0.5,  0.5);
// Back Face
glColor4f(1.0f,0.0f,0.0f,1.0f);
glVertex3f(-0.5, -0.5, -0.5);
glVertex3f(-0.5,  0.5, -0.5);
glVertex3f( 0.5,  0.5, -0.5);
glVertex3f( 0.5, -0.5, -0.5);
// Top Face
glColor4f(0.0f,0.0f,1.0f,1.0f);
glVertex3f(-0.5,  0.5, -0.5);
glVertex3f(-0.5,  0.5,  0.5);
glVertex3f( 0.5,  0.5,  0.5);
glVertex3f( 0.5,  0.5, -0.5);
// Bottom Face
glColor4f(0.0f,1.0f,1.0f,1.0f);
glVertex3f(-0.5, -0.5, -0.5);
glVertex3f( 0.5, -0.5, -0.5);
glVertex3f( 0.5, -0.5,  0.5);
glVertex3f(-0.5, -0.5,  0.5);
// Right face
glColor4f(1.0f,1.0f,0.0f,1.0f);
glVertex3f( 0.5, -0.5, -0.5);
glVertex3f( 0.5,  0.5, -0.5);
glVertex3f( 0.5,  0.5,  0.5);
glVertex3f( 0.5, -0.5,  0.5);
// Left Face
glColor4f(1.0f,1.0f,1.0f,1.0f);
glVertex3f(-0.5, -0.5, -0.5);
glVertex3f(-0.5, -0.5,  0.5);
glVertex3f(-0.5,  0.5,  0.5);
glVertex3f(-0.5,  0.5, -0.5);
glEnd();

// 앞서 저장했던 화면 관련 값을 복구하고 FBO 사용 해제
glPopAttrib();
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

        // 이제부터 그리는 것들은 스크린에 보여질 직접적인 것들
glClearColor(0.0f, 0.0f, 0.2f, 0.5f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
// 여기서 FBO에 그려진 회전하는 규브 (색상 버퍼)를 바인딩한다
glBindTexture(GL_TEXTURE_2D, img);
// 여기서는 밉맵 옵션이 사용되지 않지만 만약 당신이 밉맵을 사용한다면 아래의 주석을 제거하고 텍스쳐 생성시에 
// glGenerateMipmapEXT() 함수를 호출하라.
// glGenerateMipmapEXT(GL_TEXTURE_2D);
glEnable(GL_TEXTURE_2D);

glTranslatef(0.0f,0.0f,-2.0f);
glRotatef(-xrot,1.0f,0.0f,0.0f);
glRotatef(-yrot,0.0f,1.0f,0.0f);

glColor4f(1.0f,1.0f,1.0f,1.0f);

// 이제 FBO의 색상 버퍼를 텍스쳐로 사용하는 또다른 규브 그리기
glBegin(GL_QUADS);
// Front Face
glNormal3f( 0.0f, 0.0f, 1.0);
glTexCoord2f(0.0f, 1.0f); glVertex3f(-0.5f, -0.5,  0.5);
glTexCoord2f(1.0f, 1.0f); glVertex3f( 0.5, -0.5,  0.5);
glTexCoord2f(1.0f, 0.0f); glVertex3f( 0.5,  0.5,  0.5);
glTexCoord2f(0.0f, 0.0f); glVertex3f(-0.5,  0.5,  0.5);
// Back Face
glNormal3f( 0.0f, 0.0f,-1.0);
glTexCoord2f(1.0f, 0.0f); glVertex3f(-0.5, -0.5, -0.5);
glTexCoord2f(1.0f, 1.0f); glVertex3f(-0.5,  0.5, -0.5);
glTexCoord2f(0.0f, 1.0f); glVertex3f( 0.5,  0.5, -0.5);
glTexCoord2f(0.0f, 0.0f); glVertex3f( 0.5, -0.5, -0.5);
// Top Face
glNormal3f( 0.0f, 1.0, 0.0f);
glTexCoord2f(0.0f, 1.0f); glVertex3f(-0.5,  0.5, -0.5);
glTexCoord2f(0.0f, 0.0f); glVertex3f(-0.5,  0.5,  0.5);
glTexCoord2f(1.0f, 0.0f); glVertex3f( 0.5,  0.5,  0.5);
glTexCoord2f(1.0f, 1.0f); glVertex3f( 0.5,  0.5, -0.5);
// Bottom Face
glNormal3f( 0.0f,-1.0, 0.0f);
glTexCoord2f(1.0f, 1.0f); glVertex3f(-0.5, -0.5, -0.5);
glTexCoord2f(0.0f, 1.0f); glVertex3f( 0.5, -0.5, -0.5);
glTexCoord2f(0.0f, 0.0f); glVertex3f( 0.5, -0.5,  0.5);
glTexCoord2f(1.0f, 0.0f); glVertex3f(-0.5, -0.5,  0.5);
// Right face
glNormal3f( 1.0, 0.0f, 0.0f);
glTexCoord2f(1.0f, 0.0f); glVertex3f( 0.5, -0.5, -0.5);
glTexCoord2f(1.0f, 1.0f); glVertex3f( 0.5,  0.5, -0.5);
glTexCoord2f(0.0f, 1.0f); glVertex3f( 0.5,  0.5,  0.5);
glTexCoord2f(0.0f, 0.0f); glVertex3f( 0.5, -0.5,  0.5);
// Left Face
glNormal3f(-1.0, 0.0f, 0.0f);
glTexCoord2f(0.0f, 0.0f); glVertex3f(-0.5, -0.5, -0.5);
glTexCoord2f(1.0f, 0.0f); glVertex3f(-0.5, -0.5,  0.5);
glTexCoord2f(1.0f, 1.0f); glVertex3f(-0.5,  0.5,  0.5);
glTexCoord2f(0.0f, 1.0f); glVertex3f(-0.5,  0.5, -0.5);
glEnd();

glDisable(GL_TEXTURE_2D);
xrot+=xspeed;
yrot+=yspeed;

glutSwapBuffers ( );
// 버퍼 스왑 (출력하기)
}

위 프로그램을 돌려보면 일단 두개의 큐브가 나오는데 바깥쪽의 큰 큐브의 각 면은 FBO에 그려진 또 다른 회전하는 작은 큐브를 끊임없이 보여준다. (아래 그림 처럼)


6. 치우기

다 사용했다면 프로그램 종료전에 치우기를 수행해야 한다. (메모리 해제) 뭐 이것도 간단하다.
glDeleteFramebuffersEXT(1, &fbo);
위 명령은 fbo 를 삭제하라는 명령이고 앞서 만든 렌더버퍼를 날려보내기 위해서는 다음 명령을 수행한다.
glDeleteRenderbuffersEXT(1, &depthbuffer);
뭐 가운데 한 단어만 다를뿐 같은 명령이다.

마지막으로 글쓴이는 몇가지 당부를 하고 있는데, FBO를 생성했다 지웠다를 프로그램 실행중 반복하지 말라는 부탁과 렌더링된 FBO의 색상 버퍼를 glTexImage 함수를 이용해서 변경하거나 추가하는 행위를 피하는 것이 좋다고 한다. 이는 당연한 이야기로 이렇게 하면 Performance가 나빠질 것은 불을 보듯 뻔하다.

그리고 ATI를 사용하는 사람들에게는 위 예제가 제대로 동작하지 않을 수도 있단다. ATI 드라이버를 사용할때  FBO의 깊이 버퍼를 렌더버퍼로 연결하는 과정에 버그가 있다고 하는데 아마도 지금이 다 고쳐 졌겠지? 

소스 파일을 글에 첨부하였는데 Visual Studio 솔루션 파일이고 추가로 필요한 프로그램은 FreeGLUT이다. 이 FreeGLUT는 http://freeglut.sourceforge.net/에 가면 다운 받을수 있고 압축을 푼후 VisualStudio2008 폴더에 있는 프로젝트 파일을 열어서 컴파일 하게 되면 freeglut.lib와 freeglut.dll 파일이 생성된다. freeglut.dll은 윈도우즈 폴더에 System32 폴더안에 던져 넣어 버리고 lib 파일은 FBO_Example 프로젝트 폴더 안에 넣거나 FBO_Example/Release 폴더 및 FBO_Example/Debug 폴더에 던져 넣어버리면 문제 없이 컴파일 될것이다. 



posted by 대갈장군
2010. 3. 11. 00:56 프로그래밍
사용자 삽입 이미지
프로그램의 작성과 동작 원리는 위 그림처럼 간단한 편이다.

우선 소스 코드들 (.cpp, .c) 이 컴파일러에 의해서 컴파일 되면 바이너리 (기계어) 코드로 변경되어 .obj (오브젝트 코드)들로 저장이 된다.

그 후에 링커 (Linker)에 의해서 링크를 하게 되는데 이때 두가지 라이브러리를 사용할 수 있다. Static Library는 정적 라이브러리로써 실행 파일 (.exe)에 아예 포함되어 버리는 라이브러리다.

고로 .exe 자체가 소유하게 되므로 실행시에는 이 파일이 필요가 없다.

반대로 Import Library는 프로그램이 사용하는 특정 함수를 동적으로 가져다 쓰는 것으로써 실행을 위한 코드를 .exe 파일이 소유하는 것이 아니라 '어느 파일(DLL 파일들)에 니가 필요한 함수 뭐뭐가 있다더라' 라고 알려만 준다.

고로, .exe 파일을 실행할 때, 만약 내가 특정 함수를 DLL에서 불러와 사용했다면 반드시 해당 DLL과 .exe 파일을 연결 시켜 주어야 한다. 그렇지 않으면 .exe 는 실행 할 수가 없다는 에러 메세지를 띄운다.

.NET Framework는 이와는 조금 다르게 동작하기는 하지만 기본적으로 프로그램이 동작하는 원리는 비슷하다.

참조할 만한 관련글들
posted by 대갈장군
2010. 3. 11. 00:29 프로그래밍/C
예전에 다른 글에서 Visual Studio의 Code Generation 옵션에 대해서 이야기 한 적이 있다. 

위 글에서는 간단하게 옵션에 대한 설명만 했지만 왜 싱글 스레드에서 멀티 스레드로 바뀌었는지에 대해서는 충분히 설명하지 못했다. 그래서 이 글을 추가로 작성한다.

C 언어는 멀티 스레드 개념이 생기기 이전의 언어이므로 멀티 스레드 환경에서 발생하는 자원 경쟁 상태 (Race Condition)을 염두해 두지 않았다. 즉, 여러개의 스레드가 하나의 전역 변수를 공유하여 서로 바꾸려고 할때 발생하는 경쟁 상태를 말하는데 이것의 대표적인 예로 C 언어의 errno 전역 변수이다.

이 전역 변수는 호출한 함수의 결과를 저장하는 전역 변수인데 싱글 스레드의 경우에는 아무런 문제가 없으나 멀티 스레드의 경우 임의의 함수 호출 후 다른 스레드가 또 다른 함수를 호출하여 그 결과를 errno에 저장해 버릴 수 있기 때문에 100% 신뢰할 수 있는 결과를 가지지 않는다. 

그래서 Microsoft사에서 내놓은 해결책이 멀티 스레드를 위한 새로운 런타임 라이브러리 사용이었다. 멀티 스레드를 위한 런타임 라이브러리는 멀티 스레드에서도 안정적인 C 함수들을 호출하므로 100% 신뢰할 수 있다. 


내가 늘 불만인 것은 Visual Studio는 이렇게 중요한 옵션에 대한 설명이 너무나 부족하다는 것이다. 초보 프로그래머는 절대로 "왜 이걸 써야 하지?" 라는 궁극적인 질문에 대답을 할 수 없다.

MSDN에 설명이 되어 있다고 하지만 그 마저도 C 언어를 안다는 가정하에 설명하고 있어서 읽다가 짜증만 난다. 쉽게 쉽게 풀어서 설명해 주면 안되겠니? 응?

아무튼, 배포를 위한 프로그램을 개발한다면 거의 /MD를 사용하면 된다. D가 의미하는 것이 다이나믹 링크이므로 프로그램을 설치할 컴퓨터에 Visual Studio C++ 런타임 라이브러리만 잘 설치되어 있으면 프로그램은 무리 없이 돌아갈 것이다.

하지만 한가지 더 중요한 것은 이렇게 /MD 설정으로만 모든 것이 해결되는 것은 아니며 스레드 생성시 반드시 _beginthreadex() 함수를 사용해라는 것인데, 이 함수는 스레드 생성 전에 스레드를 위한 독립 저장 공간을 생성하여 자원 경쟁을 예방한다. 이런 독립 공간을 스레드 지역 저장소라하며 원어로를 Thread Local Storage 라 부른다. 

그리고 생성을 저 함수로 했다면 스레드를 죽일때에는 _endthreadex()를 사용해야 한다. 

결론적으로,
  • C 언어는 싱글 스레드를 근간으로 작성되었으므로 멀티 스레드의 자원 경쟁 문제를 유발할 수 있다.
  • 그런 발생 가능한 문제 제거를 위해서는 멀티 스레드 런타임 라이브러리 옵션 (/MD)를 사용하면 된다.
  • 완벽한 문제 발생 제거를 위해서는 _beginthreadex()_endthreadex() 함수로 스레드를 생성하고 해제하라.


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

C Language Constructors and Destructors with GCC  (0) 2015.02.12
C Standard Library  (0) 2010.09.25
호출 규약  (0) 2009.07.28
posted by 대갈장군
2010. 3. 6. 03:53 프로그래밍
왜 언어코드 체계가 이렇게 짜증이 나는지 원... 에휴...

1. SBCS (Single Byte Character Set) : ASCII 문자셋과 ANSI 문자셋 처럼 한바이트로 문자를 표현하는 코드. 고로 최대 256개 까지 가능

문제는 꼴랑 256개 밖에 지원이 안되는 문제점. => 우리나라나 중국은 어쩌라고?
그래서 나온것이 DBCS

2. DBCS (Double Byte Character Set) : 원래 이 DBCS의 의미는 2바이트로 문자를 표현한다는 의미. 하지만 영문과 기호는 8비트로 표현하고 한글은 16비트로 표현하기 때문에 2바이트의 한글과 1바이트의 영문자가 공존 (지 맘대로 섞여 있음). 그래서 다른 말로 MBCS (Multi Byte Character Set) 이라고도 한다.

MBCS의 문제는 글자가 몇개인지 셀때 혹은 바로 앞문자가 뭔지 찾을때 일일이 앞에서 부터 차례대로 검색해야만 알수 있다는 문제점 있음. 왜냐고? 같은 길이를 가지는 문자열이라도 1바이트 영문, 기호랑 2바이트 한글이 몇개씩 들어가 있는지 알수 없으니까.

그래서 등장 한 것이 바로
유니코드다....

3. 유니코드 : 전세계 문자를 표현하는 코드 체계. 16비트로 표현하여 최대 65536개 문자 표현.

이 유니코드는 각 문자가 2바이트씩 딱딱 차지하므로 MBCS에서와 같은 문제는 없다. 하지만 영문자의 경우 공간 낭비가 발생한다.


유니코드의 장점
모든 글자가 같은 크기를 가지므로 글자 수나 검색이 한결 용이함

유니코드의 단점
알파벳은 1바이트만 있어도 충분히 표현가능한데 2바이트를 사용하여 공간 낭비
한글의 고어나 중국의 고어를 넣을 만한 충분한 여유 공간이 없다

고로 위의 유니코드의 문제점 해결이 필요해 졌으니, 그 대안으로 등장한 것이 UTF 다.

4. UTF (UCS Transformation format) : UTF-1, UTF-7, UTF-8, UTF-16, UTF-32등 유니코드 바이트 스트림에 따른 서로 다른 인코딩 방식을 총칭.

UTF는 유니코드를 확장하기 위한 인코딩 방식인데
UTF-16의 경우는, 우선 일반적으로 유니코드 2바이트 형식으로 표현가능한 글자는 그냥 2바이트로 표기하고 만약 한자 고어, 한국 고어 같은 것이 필요하면 4바이트로 확장하여 사용하는 것인데 한마디로 가변 코드 체계다.

이것도 MBCS처럼 2바이트 유니코드와 4바이트 코드가 공존하므로 약간 다루기 까다롭다는 문제가 있구만..

UTF-8의 경우는 또 조금 다른데 이것은 미국이나 유럽등 알파벳을 사용하는 나라를 위해서 사용하는 인코딩 기법이다.

알다시피 알파벳은 1바이트면 충분하다. 그래서 UTF-8의 경우 가변 길이를 가지는 코드체계로써 만약 알파벳이면 1바이트 한글, 중국어면 3, 4바이트를 이용하는 효율적인 방법이다.

고로 만약
문서에 한글(고어 말고)이 많으면 UTF-16이 유리할 것이고 만약 알파벳이 많으면 UTF-8이 유리하다.


헌데 UTF-8이 훨씬도 똑똑한데 왜 그러냐면,
1. 문자 코드 길이 계산이 쉽다. 상위 첫 비트가 중복되는 경우가 없으므로 (고유 태그) 길이 계산이 용이하다. (길이 계산 용이)
2. 가변 길이의 코드도 앞과 뒤가 고유 태그를 가지므로 현재 바이트의 헤더 부분만 보고도 이 바이트가 문자의 앞인지 아니면 중간인지 알수 있다. (글자 검색 용이)
3. 문자열 검색이 용이하다. 왜? 마찬가지로 중복 코드가 없으므로.

추가로 중요한 것 한가지는 윈도우 95랑 98에서는 유니코드 지원하지 않는다 (기본적으로) 물론 업뎃하면 된다고는 하지만 완벽 지원은 안된단다. (지금도 그런지는 모름)

프로그램짜면서 사용해야 하는 실제 상황을 보자꾸나...


#define UNICODE
#include <windows.h>

UNICODE를 windows.h 전에 선언해주면 그 프로젝트는 유니코드로 컴파일 된다.

wchar_t *lpszClass = L"UniTest1";

유니코드로 문자열을 선언하기 위해서는 위 명령처럼 wchar_t 타입을 사용해야 하고 L을 " " 문자열 앞에 붙여야 한다. 

여기서 wchar_t는 사실 unsigned short (16 비트)이고 L은 뒤에 있는 문자열을 2바이트 유니코드로 변환하여 저장하라는 매크로다. 이 L이 없으면 컴파일러는 기본적으로 ANSI (1바이트 문자열 형식)로 저장하려 한다. (에러 뜰거임)

그러면 프로그램짤때 유니코드 쓰냐 안쓰냐에 따라서 선언문이 바뀌어야 하느냐? 만약 YES라면 얼마나 불편하겠는가. 그래서 등장한 놈이 TCHAR인데...

typedef wchar_t WCHAR;
typedef char CHAR;

#ifdef UNICODE
typedef WCHAR TCHAR;
#else
typedef char TCHAR;
#endif

위의 전처리를 통해서 ANSI든 유니코드든간에 TCHAR을 사용하면 UNICODE의 선언 여부에 따라 자동으로 컴파일러가 골라쓰게 된다. 즉, UNICODE가 선언되어 있으면 TCHAR이 WCHAR이고 결국 이건 wchar_t이며 이건 결국 unsigned short이다. 만약 UNICODE 선언이 없다면 TCHAR은 걍 char이다. 

마찬가지로 문자열에 대해서는

typedef WCHAR *PWCHAR, *LPWSTR, *PWSTR;                   // 유니코드 사용시 문자열 포인터 타입
typedef CONST WCHAR *LPCWCH, *LPCWSTR, *PCWSTR;   // 유니코드 사용시 상수형 문자열 포인터 타입
typedef CHAR *PCHAR, *LPSTR, *PSTR;                             // 유니코드 사용 안할때 문자열 포인터 타입
typedef CONST CHAR *LPCCH, *LPCSTR, *PCSTR;             // 유니코드 사용 안할때 상수형 문자열 포인터 타입

#ifdef UNICODE                                                 // 유니코드 사용시는 PTSTR = LPWSTR, LPCTSTR = LPCWSTR
typedef LPWSTR 
PTSTR, LPTSTR;
typedef LPCWSTR 
LPCTSTR;
#else                                                               // 유니코드 사용안할때는 PTSTR = LPSTR, LPCTSTR = LPCSTR
typedef LPSTR 
PTSTR, LPTSTR;
typedef LPCSTR 
LPCTSTR;
#endif

인데 졸라 복잡해 보이지만 간단하다. 문자열 포인터나 상수형 문자열 포인터를 써야 한다면 간단하게 걍 PTSTR, LPTSTR, LPCTSTR등을 쓰면 된다. 만약 내가 #define UNICODE를 시작전에 선언했다면 프로그램은 알아서 WCHAR 을 사용할 것이고 만약 유니코드 매크로를 선언하지 않았다면 알아서 CHAR을 사용한다. 위의 선언에서 잘 보면 W가 있고 없고의 차이인데 이것이로 WCHAR이냐 아니면 CHAR이냐의 차이다.

고로 결론적으로 유니코드도 되고 ANSI도 되는 코드를 짜려면 문자 선언시는 TCHAR, 문자열 선언시는 LPTSTR을 써라는 말이다.

문자열 상수에 대한 매크로가 존재하는데 바로 TEXT("     ") 이다. 이놈을 사용하면 마찬가지로 매크로에서 정의된 방법대로 유니코드냐 아니냐에 따라서 알아서 저장해 준다. 만약 UNICODE 매크로가 선언되어 있다면 TEXT()는 알아서 문자열 앞에 L을 붙여주고 (이 L이 유니코드로 문자열을 변경하라는 매크로) 만약 UNICODE 매크로가 선언 되지 않았다면 걍 ANSI 문자열로 문자열을 생성한다. 고로 사용자는 단순하게 #define UNICODE를 프로그램 시작부분에 쓰느냐 안쓰느냐에 따라서 간단하게 유니코드와 ANSI 코드 사이를 왔다 갔다리 할 수 있는 거다

사실 알고보면 윈도우가 제공하는 각종 API 함수들중 문자열을 받거나 리턴하는 대부분 UNICODE 타입과 ANSI 타입을 지원하는 두 종류를 가진다. 예를 들어 TextOut 함수를 보면 실제로는 TextOutW와 TextOutA라는 두 함수로 구성되어 있고 UNICODE의 선언 여부에 따라 적절한 함수를 호출한다. 여기서 W는 Wide라는 의미로 Unicode를  의미하고 A는 ANSI를 의미한다.


프로그램을 작성할 때는 윈도우가 제공하는 API 뿐만 아니라 오래된 C 함수 및 C++함수들을 사용해야 하는데 대표적인 것이 문자열의 길이를 구하는 함수인 strlen()이다. 대략 10년 전쯤 처음 컴퓨터 프로그래밍 수업시간에 들었던 기억이 난다.. ㅡ.ㅡ;

아무튼, 이 strlen() 함수는 ANSI 코드를 위한 함수이지 유니코드를 위한 함수가 아니다. 유니코드를 위한 문자열 길이 구하는 함수는 wcslen() 이라는 놈이다. 하지만 걱정할 필요가 없는것이 위에서 해왔던 것 처럼 이 둘 사이를 쉽게 왔다 갔다 할 수 있는 일반형 함수가 존재한다. 

tchar.h에 보면 UNICODE의 사용여부에 따라 알아서 strlen() 또는 wcslen() 함수를 사용하도록 해주는 일반형 함수가 정의되어 있는데 대표적인 예로 _tcslen, _tcscpy, _tcscmp, _tcsicmp 등이다.

#ifdef _UNICODE
typedef _tcslen wcslen;
#else
typedef _tcslen strlen;
#endif

위 매크로 선언에 의해서 알아서 wcslen과 strlen 함수를 _UNICODE 매크로 선언 여부에 따라 적절히 선택한다.

참고로 코드를 보면 _UNICODE와 UNICODE 두가지가 공존하는데 이것은 같은 의미의 매크로로써 하나는 컴파일러가 언어차원에서 정의한 것이고 나머지 하나는 운영체제가 정의하는 거란다. 젠장할...

아무튼 결론적으로보면 사용자는 프로그램 내부에 TCHAR, _tcslen, TEXT(" ") 와 같은 UNICODE 선언 여부에 따라 적절한 함수를 선택하는 매크로 함수들을 사용하면 손쉽게 UNICODE 용으로 컴파일 할수도 있고 혹은 ANSI 용으로 컴파일 할 수도 있다는 점이다. 


Visual Studio 의 프로젝터 Properties 를 클릭해 보면 General 속성에서 Character Set에 유니코드와 MBCS 둘 중 하나를 선택할 수 있다. 여기서 유니코드를 선택하면 Visual Studio가 알아서 #define UNICODE를 코드에 삽입한다. (얼마나 편한가..)


만약 프로그램을 짤 때 일반화 함수들을 안쓰고 char을 써놓고 UNICODE로 컴파일 하라는 명령을 주게 되면 위 그림처럼 무수히 많은 에러들을 보게 될 것이다. 이것이 일반적으로 가장 빈번히 발생하는 유니코드 관련 에러이다. 문제는 다음과 같은 경우다. 

내가 프로그램을 만드는데 어느 유명 사이트에서 대단한 프로그래머가 만든 아주 유용한 소스 코드를 받았다. 헌데 그 프로그래머는 너무나도 유니코드를 사랑하셔서 모든 함수를 일반화 함수가 아닌 유니코드 함수로 직접 불러다 사용했다. 그런데 내가 만든 프로그램에서는 죄다 MBCS를 사용한다. (char, char * 같은 형태) 

둘을 하나의 프로젝트에 묶어서 컴파일 하려했다... 에러가 200개 뜬다..... ㅡ.ㅡ; 헐... 

이런 경험을 해본 사람이 많으리라 믿는다. 아무튼, 말하고자 하는 바는 프로젝트를 만들때 유니코드와 MBCS가 동시에 존재할 수 없다는 것이다. 그래서 일반화 함수를 사용하는 것이 현명한 방법이다.

TCHAR
TCHAR과 PTSTR 그리고 TEXT() 매크로 함수를 범용성을 위해서 꼭 사용해라... 이말이다.

posted by 대갈장군
2010. 3. 6. 01:34 카테고리 없음

요즘 유일하게 보는 드라마 추노... 모두들 대단하지만 그중에서도 성동일, 아니지 아니지... '천지호'.

나는 성동일을 본것이 아니라 수백년전 살다 죽은 '천지호'를 보았다. 

진짜 배우라면 주어진 배역을 '연기'하지 않는다. 나는 천지호의 어디에서도 성동일을 찾아 낼 수 없었다.

자아를 비우고 새로운 인생을 살아가는 진정한 연기자... 

다음 작품에서 어떤 역활을 하게 되더라도 마찬가지로 나는 '성동일'을 볼 수 없으리라 생각한다.

아마도 나는 영원히 진짜 성동일을 보지 못할 것이다... 하하.. 이것이 진짜 연기자가 아닌가?

언니가 최고입니다요.. 





posted by 대갈장군
2010. 3. 5. 05:25 프로그래밍

Managed, Unmanaged, Native: What Kind of Code Is This?

http://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm

With the release of Visual Studio .NET 2003 (formerly known as Everett) on April 24th, many developers are now willing to consider using the new technology known as managed code. But especially for C++ developers, it can be a bit confusing. That's because C++, as I pointed out in my first column here, is special.

1. What Is Managed Code? – Managed code?

Managed Code is what Visual Basic .NET and C# compilers create. It compiles to Intermediate Language (IL), not to machine code that could run directly on your computer. The IL is kept in a file called an assembly, along with metadata that describes the classes, methods, and attributes (such as security requirements) of the code you've created. This assembly is the one-stop-shopping unit of deployment in the .NET world. You copy it to another server to deploy the assembly there—and often that copying is the only step required in the deployment.

Manage code 무엇인가? Managed code Visual Basic .NET C# 컴파일러가 만들어내는 것을 말한다. 컴파일러들은 우선 IL(Intermediate Language – 중간 언어) 라고 불리는 코드를 만들어 낸다. IL 컴파일을 수행한 당신의 컴퓨터에서 바로 실행되기 위한 machine code (기계 언어) 아니라는 알아야 한다. 이렇게 생성된 IL 어셈블리라고 불리는 파일에 저장되고 이때 메타 데이터도 함께 저장하는데 메타 데이터들은 내가 컴파일한 코드의 클래스, 함수 그리고 변수 속성 (보안 관련 속성도 포함)등을 가진다. 이제 어셈블리 파일은 .NET 세계에서 배달 완료된 모든 내용이 포장된 일종의 상품이다. 당신은 이것을 다른 서버에 복사하여 deploy (배포)하기만 하면 된다.

Managed code runs in the Common Language Runtime. The runtime offers a wide variety of services to your running code. In the usual course of events, it first loads and verifies the assembly to make sure the IL is okay. Then, just in time, as methods are called, the runtime arranges for them to be compiled to machine code suitable for the machine the assembly is running on, and caches this machine code to be used the next time the method is called. (This is called Just In Time, or JIT compiling, or often just Jitting.)

Managed code 이른바 Common Language Runtime (줄여서 CLR) 환경에서 동작한다. CLR 내가 작성한 코드가 실행될 다양한 형태의 서비스를 지원한다. 여기서 주의 깊게 봐야 하는 단어는 실행될 이다. 일반적인 경우, CLR 우선 어셈블리 파일을 읽은 다음 IL 괜찮은지부터 확인한다. 그리고 함수가 호출되는 순간 CLR 현재 프로그램이 돌아가는 컴퓨터의 환경에 적합한 기계 언어를 만들어 낸다. 그리고 함수가 다음 번에 호출되면 바로 사용될 있게 하기 위해서 만들어진 기계언어 코드를 cache (캐시) 저장해 둔다. 이것이 바로 Just In Time 혹은 줄여서 JIT 컴파일링 이라 불리는 기법이다. 여기서 중요한 것은 현재 프로그램이 돌아가는 컴퓨터 환경에 적합한 기계 언어 생성이다. 이것이 바로 CLR 강점이다.

As the assembly runs, the runtime continues to provide services such as security, memory management, threading, and the like. The application is managed by the runtime.

어셈블리가 실행되는 동안 CLR 보안, 메모리 관리, 스레딩에 관련된 서비스 일체를 제공하고 이런 프로그램을 우리는 ‘Runtime 의해 Managed (관리되는) 프로그램이다 라고 한다.

Visual Basic .NET and C# can produce only managed code. If you're working with those applications, you are making managed code. Visual C++ .NET can produce managed code if you like: When you create a project, select one of the application types whose name starts with .Managed., such as .Managed C++ application..

Visual Basic .NET C# 오직 managed 코드만 생성가능 하다. 만약 당신이 프로그램들을 사용한다면 당신은 managed code 생성해 내고 있는 것이다. 반면 Visual C++ .NET 내가 원하면 managed code 생성할 수도 있고 아니면 unmanaged code 생성할 수도 있다. 이것은 Visual Studio 프로젝트 속성에서 변경 가능하다.

2. What Is Unmanaged Code? – Unmanaged code ?

Unmanaged code is what you use to make before Visual Studio .NET 2002 was released. Visual Basic 6, Visual C++ 6, heck, even that 15-year old C compiler you may still have kicking around on your hard drive all produced unmanaged code. It compiled directly to machine code that ran on the machine where you compiled it—and on other machines as long as they had the same chip, or nearly the same. It didn't get services such as security or memory management from an invisible runtime; it got them from the operating system. And importantly, it got them from the operating system explicitly, by asking for them, usually by calling an API provided in the Windows SDK. More recent unmanaged applications got operating system services through COM calls.

Unmanaged code Visual Studio .NET 2002 나오기 전에 만든 코드를 말한다. , Visual Basic 6, Visual C++ 6 그리고 15 이상된 C 컴파일러 또한 Unmanaged code 생성해 낸다. 이것들은 내가 컴파일을 수행하는 바로 컴퓨터 적합한 기계 코드를 생성 낸다. (Managed code 처럼 IL 생성 과정이 없다.) 고로 이렇게 생성해낸 기계 언어는 같은 하드웨어 구성을 가지지 다른 컴퓨터에서는 돌아갈지 모르나 다른 구성을 가지는 컴퓨터에서는 당연히 실행 불가다. 또한 이렇게 생성된 unmanaged code 보안 메모리 관리 서비스를 실행시에 Runtime으로부터 받을 수가 없다. 대신 OS(Windows)로부터 받는다. 여기서 중요한 점은 OS로부터 서비스를 받기는 하지만 이것은 Windows SDK 제공하는 특정 함수 (API) 호출함으로써 가능하다. 근래의 Unmanaged code 운영체제의 서비스를 COM call 의해 제공받는다라고 했다. 글이 2004 글이므로 COM 근래의 언어라고 표현한 것이 이해가 간다. 아무튼, 요약하자면 managed code 경우 runtime 알아서 메모리 관리를 해주는데 반해 (Garbage collection) unmanaged code 경우, 사용자에게 책임이 있다는 점이다. 다만 COM 같이 발전된 형태의 라이브러리들은 스스로 객체의 파괴를 관리하는 능동성을 가지고는 있다.

Unlike the other Microsoft languages in Visual Studio, Visual C++ can create unmanaged applications. When you create a project and select an application type whose name starts with MFC, ATL, or Win32, you're creating an unmanaged application.

다른 Microsoft 언어들과는 다르게 Visual C++ unmanaged 프로그램을 만들 있다. MFC, ATL 혹은 Win32 생성되는 프로젝트들은 모두 unmanaged application이다.

This can lead to some confusion: When you create a .Managed C++ application., the build product is an assembly of IL with an .exe extension. When you create an MFC application, the build product is a Windows executable file of native code, also with an .exe extension. The internal layout of the two files is utterly different. You can use the Intermediate Language Disassembler, ildasm, to look inside an assembly and see the metadata and IL. Try pointing ildasm at an unmanaged exe and you'll be told it has no valid CLR (Common Language Runtime) header and can't be disassembled—Same extension, completely different files.

당연히 Visual C++ Managed application 만들 수도 있다. 이때 .exe 확장자를 가지는 IL 어셈블리가 만들어진다. 만약 당신이 MFC 프로그램(unmanaged code) 만든다면 이것은 똑같은 확장자인 .exe 가지는 native code 생성해 것이다. 여기서 혼란이 수도 있다. 같은 .exe 확장자를 가지니까 뭐가 뭔지 모를 있다. 둘을 구분하기 위해서는 Intermediate Language Disassembler, 줄여서 ildasm이라 불리는 놈으로 어셈블리와 메타 데이터를 들여다 보면 된다. Unmanaged code ildasm으로 보려고 하면 유효한 CLR 헤더가 없다고 에러 메시지를 출력할 것이란다. , 개의 .exe 파일은 완전히 다른 형태의 파일이다.

3. What about Native Code? – Native code?

The phrase native code is used in two contexts. Many people use it as a synonym for unmanaged code: code built with an older tool, or deliberately chosen in Visual C++, that does not run in the runtime, but instead runs natively on the machine. This might be a complete application, or it might be a COM component or DLL that is being called from managed code using COM Interop or PInvoke, two powerful tools that make sure you can use your old code when you move to the new world. I prefer to say .unmanaged code. for this meaning, because it emphasizes that the code does not get the services of the runtime. For example, Code Access Security in managed code prevents code loaded from another server from performing certain destructive actions. If your application calls out to unmanaged code loaded from another server, you won't get that protection.

Native code 가지의 의미를 가지고 있다. 우선 Native code 함은 Unmanaged code 동의어로 사용된다. 옛날 버전의 컴파일러로 컴파일 되었거나 Visual C++에서 일부러 선택한 컴파일러에 의해 해당 컴퓨터에 적합한 기계언어의 생성을 말하며 이는 런타임시 (실행되는 순간) CLR 의해 아무런 서비스를 받을 없다는 것을 의미한다. 이런 Native code(Unmanaged code) 하나의 완전한 프로그램 수도 있고, COM 컴포넌트 수도 있고, 혹은 Managed code내부에서 호출된 DLL 수도 있다. 하지만 이런 경우 ‘Unmanaged code’라고 하는 것이 합당한데 왜냐면 Unmanaged code라는 것이 실행시에 Runtime으로부터 서비스를 받을수 없다는 것을 분명히 강조하기 때문이란다. 예를 들어 설명한 것이 서로 다른 컴퓨터에서 실행되는 프로그램이 Managed code 경우 보안 관련 서비스를 실행시 (Runtime) 받을수 있으나 Unmanaged code 경우 그럴 없다는 .

The other use of the phrase native code is to describe the output of the JIT compiler, the machine code that actually runs in the runtime. It's managed, but it's not IL, it's machine code. As a result, don't just assume that native = unmanaged.

다른 의미의 Native code JIT 컴파일로부터 생성된 코드를 말한단다. JIT Managed code에만 사용되므로 이것은 분명 Managed code이지만 IL 코드가 아니고 해당 컴퓨터에 적합한 기계언어이다. 고로 Native라는 단어를 무조건적으로 Unmanaged라고 생각하지 말라.

Does Managed Code Mean Managed Data? – Managed code Managed Data 의미하나?

Again with Visual Basic and C#, life is simple because you get no choice. When you declare a class in those languages, instances of it are created on the managed heap, and the garbage collector takes care of lifetime issues. But in Visual C++, you get a choice. Even when you're creating a managed application, you decide class by class whether it's a managed type or an unmanaged type. This is an unmanaged type:

Visual Basic이나 C# 사용한다면 모든 것이 Managed code이므로 오히려 간단하다. 고로 내가 만약 언어들을 사용해서 프로그램을 작성한다면, 클래스를 하나 선언하고 객체화를 했을 객체는 Managed Heap 생성되고 Garbage Collector 알아서 메모리를 수거해 간다. 하지만 내가 만약 Visual C++ 사용한다면 나는 각각의 클래스를 선언할 마다 선택을 수가 있게 된다. 이른바 클래스가 Managed type인가 아니면 Unmanaged type인가를 다음과 같이 결정한다. 우선 Unmanaged type 경우 다음과 같이 선언한다.

class Foo

{

private:

   int x;

public:

    Foo(): x(0){}

    Foo(int xx): x(xx) {}

};

 

This is a managed type:

그리고 Managed type 경우 다음과 같다.

__gc class Bar

{

private:

   int x;

public:

    Bar(): x(0){}

    Bar(int xx): x(xx) {}

};

The only difference is the __gc keyword on the definition of Bar. But it makes a huge difference.

차이점이라고는 클래스 선언 앞부분에 __gc 붙냐 안붙냐 차이 밖에 없다. 하지만 차이는 엄청나다.

Managed types are garbage collected. They must be created with new, never on the stack. So this line is fine:

Foo f;

Managed type garbage collector 의해 자동으로 메모리가 수거 된다. 고로 놈들은 반드시 new 이용해서 생성해야 하며 절대로 stack 생성될 없다. 고로 위에 Unmanaged type으로 생성한 Foo 클래스의 경우 명령처럼 스택에 선언할 있지만,

But this line is not allowed:

Bar b;

Managed type으로 선언한 Bar 클래스의 경우 Foo 클래스와 같은 방식으로 스택에 선언 수가 없다.

If I do create an instance of Foo on the heap, I must remember to clean it up:

Foo* pf = new Foo(2);

// . . .

delete pf;

The C++ compiler actually uses two heaps, a managed an unmanaged one, and uses operator overloading on new to decide where to allocate memory when you create an instance with new.

만약 내가 Foo 클래스를 힙에 선언한다면 (다른 말로 포인터 생성하여 new 객체화 경우), 반드시 메모리 삭제를 delete 통해서 파괴해야 한다. C++ 컴파일러는 실제로 두개의 힙을 사용하는데 각각은 managed unmanaged 위한 것이다. new 라는 키워드는 오버로딩을 통해서 managed unmanaged 중에 하나를 선택하여 메모리 할당한다.

If I create an instance of Bar on the heap, I can ignore it. The garbage collector will clean it up some after it becomes clear that no one is using it (no more pointers to it are in scope).

There are restrictions on managed types: They can't use multiple inheritance or inherit from unmanaged types, they can't allow private access with the friend keyword, and they can't implement a copy constructor, to name a few. So, you might not want your classes to be managed classes. But that doesn't mean you don't want your code to be managed code. In Visual C++, you get the choice.

반대로 만약 내가 Bar 클래스를 힙에 생성하면 나는 간단히 신경 끄면 그만이다. ? Garbage collector 알아서 메모리를 수거할 테니

, managed type에는 몇가지 제약이 있으니 바로 다중 상속이 안되며 unmanaged type으로 부터의 상속이 안된다는 제약이다. 또한 private 속성에 대한 접근이 friend 키워드를 통해서도 안되고, 복사 생성자를 구현 수가 없단다. 요런 저런 제약을 보아하니 아마도 당신은 managed class 만들고 싶지 않을 수도 있다. 하지만 그것이 당신의 프로그램 전체가 managed code 아니길 바란다는 것은 아닐 것이다 (managed unmanaged 섞어 써도 된다는 ). 암튼, C++에서는 프로그래머가 선택할 있다.

결론만 말하자면,

1. Managed code는 CLR에 의해 제공되는 실행시의 각종 서비스 (보안 및 메모리 관련)를 받을 수 있는 것을 말한다.
2. Managed code는 CLR에 의해 해당 컴퓨터에 적합한 기계 언어를 능동적으로 생성하여 범용성을 높였다.
3. Unmanaged code는 실행시의 CLR이 제공하는 서비스를 제공받을 수 없다.
4. Unmanaged code는 컴파일할때 컴퓨터의 환경에 적합한 기계어만 생성하므로 범용성이 매우 낮다.
5. Native code는 '기계 언어'라고 보는 것이 적합하며 Native code를 Unmanaged code라고 생각하면 안된다.
6. Visual C++는 Managed Type과 Unmanaged Type의 클래스를 생성할 수 있다.
7. Managed Type 클래스는 힙에 생성되면 자동으로 메모리 수거가 이루어 지는 반면 Unmanaged Type 클래스는 사용자가 수거해야 한다. 
8. __gc를 클래스 선언시 사용하면 Managed Type 클래스를 선언 할 수 있다.

About the Author

Kate Gregory is a founding partner of Gregory Consulting Limited (www.gregcons.com). In January 2002, she was appointed MSDN Regional Director for Toronto, Canada. Her experience with C++ stretches back to before Visual C++ existed. She is a well-known speaker and lecturer at colleges and Microsoft events on subjects such as .NET, Visual Studio, XML, UML, C++, Java, and the Internet. Kate and her colleagues at Gregory Consulting specialize in combining software develoment with Web site development to create active sites. They build quality custom and off-the-shelf software components for Web pages and other applications. Kate is the author of numerous books for Que, including Special Edition Using Visual C++ .NET.

 

posted by 대갈장군
2010. 2. 26. 01:23 World Of Warcraft




'World Of Warcraft' 카테고리의 다른 글

Paladin  (0) 2009.03.13
posted by 대갈장군
2010. 2. 24. 06:01 OpenGL
Convex Hull은 볼록 껍데기로써 임의의 점으로 구성된 다각형에서 두 점을 연결했을때 이 두 점이 이루는 직선이 다각형의 외곽선을 교차하지 않는 것을 의미한다. 바로 다음 그림처럼..


반대로 임의의 두점이 외곽선을 관통하게 되면 (아래 그림처럼) 이것을 오목 껍데기 혹은 Concave Hull 이라고 한다. 중요한 것은 OpenGL에서는 오직 Convex Hull 로만 폴리곤을 그릴수 있다는 것... :) 


posted by 대갈장군
2010. 2. 24. 03:30 OpenGL
OpenGL에서 블렌딩은 예상외로 조금 복잡하다. 일단 함수의 인자부터 헷갈린다. glBlendFunc() 함수가 입력으로 들어오는 화소와 프레임 버퍼에 이미 그려져 있는 화소의 블렌딩 비율을 지정하는 놈인데 이 놈의 인자들을 살펴보면, 첫번째 인자가 source이고 두번째가 destination 이다. 

이거 마치 source가 원래 그려져 있던 화소 같이 들리지만 그 반대다. source인 첫번째 인자가 들어오는 화소고 두번째 인자인 destination이 목적지인 그려질 위치에 있던 화소를 말한다.

아래에 두 가지 대표적인 블렌딩의 예를 그림으로 표현했는데 우선 첫번째 인자가 GL_SRC_ALPHA이고 두번째 인자가 GL_ONE_MINUS_SRC_ALPHA 이면 입력으로 들어오는 화소의 알파값이 입력 화소의 블렌딩 비율이되고 1에서 입력으로 들어오는 화소의 알파값을 뺀 나머지 값이 원래 버퍼에 들어있던 화소의 블렌딩 비율이 되게 하라는 말이다.

고로 소스로 들어온 사각형의 알파값이 아래 그림 첫번째 처럼 50% 였다면, 1 - 0.5를 뺀 값인 0.5가 원래 있던 화소들인 빨강색 삼각형에 적용되어 둘이 합쳐져 오른쪽의 그림처럼 스크린에 나타난다.

만약 입력으로 들어오는 사각형의 알파값이 20%라면 삼각형은 80% (100 - 20)로 블렌딩 되어 그림 내부의 아래 그림 처럼 블렌딩 된다.


것을 코드로 표현하자면 아래와 같다. 우선 블렌딩을 활성화하고 사각형을 그리는데 블렌딩 옵션을 입력으로 들어오는 화소만 그려지라는 의미의 GL_ONE, GL_ZERO 로 주고 삼각형을 그린다. 그리고나서 블렌딩 옵션을 바꿔서 사각형을 그리면 된다.


  glEnable(GL_BLEND);  // 블렌딩활성화

  glBlendFunc(GL_ONE, GL_ZERO);  // 소스(Incoming) 만그리기

 

  glBegin(GL_TRIANGLES);  // Drawing Using Triangles

  glColor4f(1.0f, 0.0f, 0.0f, 1.0f);

  glVertex4f( 0.0f, 1.2f, 0.0f, 1.0f); 

  glVertex4f(-1.2f,-1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.2f,-1.0f, 0.0f, 1.0f); 

  glEnd(); 


  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);  

 

  glBegin(GL_QUADS);  // Draw A Quad

  glColor4f(0.0f, 0.0f, 1.0f, 0.5f);

  glVertex4f(-1.0f, 1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.0f, 1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.0f,-1.0f, 0.0f, 1.0f); 

  glVertex4f(-1.0f,-1.0f, 0.0f, 1.0f); 

  glEnd(); 

 

또 다른 예로는 3개의 물체를 균일한 값으로 블렌딩 하는 것인데 여기서는 3개의 물체 (원, 사각형, 삼각형)가 나온다. 이것도 위와 유사한 방법이지만 glBlendFunc() 함수의 인자를 GL_SRC_ALPHA와 GL_ONE으로 준다. 소스로 들어오는 화소의 블렌딩은 들어오는 알파값을 그대로 사용하되 먼저 그려져 있던 화소는 GL_ONE을 줌으로써 가지고 있던 알파값을 그대로 유지하게 한다. 결국 이 의미는 '중첩'시키라는 의미다. 고로 33%씩 세번 중첩 하면 100% 하얀 부분이 3개의 물체가 겹치는 부분에 나타나야 한다. 근데 아래 그림은 좀 약하다... 파워 포인트로 작업한지라 제대로 중첩이 안되고 있다.. -_-  

그래서 프로그램을 돌려 나온 결과를 스크린 캡쳐하여 첨부하였다. 아래 그림을 보면 아... 세개의 도형이 겹치는 부분은 100% 흰색이구나 하는 느낌이 올 것이다. 


소스 코드는 다음과 같다.

  glEnable(GL_BLEND);  // 블렌딩활성화

  glBlendFunc(GL_SRC_ALPHA,GL_ONE); 

 

  glBegin(GL_TRIANGLES);  // Drawing Using Triangles

  glColor4f(1.0f, 1.0f, 1.0f, 0.33333f);

  glVertex4f( 0.0f, 1.2f, 0.0f, 1.0f); 

  glVertex4f(-1.2f,-1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.2f,-1.0f, 0.0f, 1.0f); 

  glEnd(); 

 

  glBegin(GL_QUADS);  // Draw A Quad

  glColor4f(1.0f, 1.0f, 1.0f, 0.33333f);

  glVertex4f(-1.0f, 1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.0f, 1.0f, 0.0f, 1.0f); 

  glVertex4f( 1.0f,-1.0f, 0.0f, 1.0f); 

  glVertex4f(-1.0f,-1.0f, 0.0f, 1.0f); 

  glEnd(); 


  glColor4f(1.0f, 1.0f, 1.0f, 0.33333f);

  glutSolidSphere(1.0f, 36, 36);

posted by 대갈장군
2010. 2. 24. 03:03 카테고리 없음

Nathan Myhrvold라는 친구가 레이져로 모기 잡는 시스템을 개발했습니다. E-bay에서 산 재료들로 만든 시스템이라는 군요.. 헐... 

참 흥미로운 점은 레이져 빔을 쏴서 모기의 날개 주파수를 측정하여 암컷인지 수컷인지를 알아낸 다음 (암컷의 날개짓 주파수가 수컷에 비해 훨씬 높다는 군요) 암컷만 레이져 빔을 쏴서 태워 죽이는 방식이네요. 

위쪽 동영상은 개발자 인터뷰 인데 뒷부분에 가서 보면 녹색 레이져 빔이 실제로 날아다니는 모기를 정조준 하는 것을 볼 수 있네요.. 후덜덜.. 

그리고 아래쪽 동영상은 초고속 카메라로 실제 레이져 빔을 이용해 모기를 죽일때를 촬영한 것입니다.




posted by 대갈장군
2010. 2. 23. 23:53 풉...
미국의 어떤 재미있는 친구가 크레용 미사일 만들기에 도전한지 6년 만에 발사 성공을 했다는 아주 기쁜 (?) 소식이다. 

John Coker 라는 미국 사람이 자신이 만든 미사일을 보고 어떤 친구가 크레용이랑 비슷하게 생겼다고 한게 화근이 되어 이런 도전을 했다고 한다. 

그 이후로 6년을 걸쳐 완성한 크레용 미사일! 발사... 3. 2. 1...


그런데 8개가 들어가 있는 크레용 세트인데 8개중 4개만 발사가 되고 4개는 실패했단다... 이유는 뭔지 몰겠으나 뭐라뭐라 해놓기는 했다... 점화기 어쩌고 저쩌고...

위 그림처럼 발사된 4개의 미사일들은 무려 2928 feet나 날아갔다는데 이걸 미터로 환산하면 대략 8만 7천 미터. 고로 87 키로미터를 날아갔다는 이야기.. 오... 제법 멀리간다.


크레용이라는 이름이 어디서 왔나 했더니 원래 프랑스 말로 크레용은 연필이라는 의미란다. 미국에서 만든 상표 이름이 크레욜라였다. 위쪽이 1903년에 처음 만든 크레용 팩이고 아래쪽은 1998년에 나왔던 크레용 팩이다. 크레욜라의 크레용... 뭐랄까 많이 꼬는 듯한 이 느낌... 있어보인다... -_-

자세한 내용은 http://www.jcrocket.com/crayons.shtml 를 보시면 다 나옵니다. 어케 만들었는지랑 제작 과정에서의 사진이 더 있네요. 

재미있는건 위 소식이 전해진 또 다른 사이트에 댓글 중에 아래 그림이 올라왔네요.


이란 대통령 같은데 '뽀샵질로 구라치지 마!' 라는 군요. ㅋㅋㅋ
posted by 대갈장군
2010. 2. 23. 04:41 나의 이야기
진실은 정의 내리려 하는 순간 이미 진실이 아니다라는 말이 있다. 

이것은 끝이 없이 흐르는 시간에 변하지 않는 것은 없다는 것을 말한다.

그렇다면 원래부터 유한한 생명인 인간에게 결국 진실은 없다. 

하지만, 누군가가 어떤 원칙이나 마음을 죽을때까지 흔들림 없이 지켜낸다면 그것은 그 사람의 '진실'임에 틀림 없다.

그 원칙이나 마음은 죽은 후에는 변할수가 없기 때문이다.

결국, 인간에게 진실이라 함은 그 사람의 일생동안 변하지 않는 마음 또는 원칙. 


평생을 하나의 원칙을 지켜나가는 사람, 죽음에 굴하지 않고 자신의 의지를 지켜내는 사람, 평생 변하지 않는 엄마의 사랑.

이런 사람들에게 내 마음이 움직이는 이유는, 

그들의 '진실'에서 나오는 '진심'이 나에게 전달되기 때문이다.


죽어 없어지는 것보다 잊혀지는 것이 더 두려운 인간에게 '진실'은 남은 모든 사람의 마음에 영원히 살아남기 위한 최고의 방법이 아닐까.

지금까지 쉽게 써온 단어들인 '진실'과 '진심'은 어떻게 보면 내 인생을 건 스스로와의 약속이다.

'나는 당신을 사랑합니다' 가 '진실'이 되기 위해서는 나는 평생을 변함없이 당신을 사랑해야만 진실이 되는 것이다. 사랑이라는 것은 말하기는 쉽지만 평생동안 변하지 않고 사랑하는 것은 정말로 어렵다. 사랑한다고 말하기 전에 한번더 생각해 보라.

별볼것 없는 사람이라도 평생을 바쳐 무엇인가를 변하지 않고 지켜온 사람이라면 나를 감동시키기에 충분하다.

 


'나의 이야기' 카테고리의 다른 글

범죄와의 전쟁  (0) 2013.01.24
영화 인셉션에 나오는 명대사  (2) 2011.03.09
Alaska  (0) 2010.02.18
기도  (2) 2010.02.03
'무한도전' 논란에 대한 내 생각  (1) 2009.11.24
posted by 대갈장군
2010. 2. 23. 01:37 OpenGL
OpenGL에서 어쩌면 가장 중요한 부분이 바로 Viewing 이 아닌가 싶다. 이 파트는 어떻게 보여지는 가를 설정하는 모든 명령에 관련되어 있는데 이걸 못하면 아무리 멎진 그림을 그려놔도 볼수가 없으니 말이다.

Red Book을 보면 참 설명이 잘 되어 있는데 문제는 영어로 되어 있다. -_-; 암튼, Red Book을 근거로 하여 설명하자면 OpenGL에서 Viewing을 설정하는 것은 카메라로 사진을 찍는 것과 유사하다고 말한다.

옆의 그림이 그것을 설명하는데 우선 차례 차례 보자. 제일 먼저 해야 하는 것이 카메라 설치이다. 이것은 첫번째 그림이 의미하는 바인데 OpenGL에서는 이것을 Viewing Transformation 이라고 한다. 

두번째로 해야 할 일은 사진찍을 물체를 적당한 위치에 놓는 것이다. (두번째 그림) 이것을 OpenGL에서는 Modeling Transformation 이라고 한다. 

세번째는 적당한 렌즈로 초점을 맞추는 일이다. OpenGL에서는 이 과정을 Projection Transformation 이라고 한다. 사실 이 파트의 설명은 조금 어색하긴 하다. OpenGL에서 이 과정은 사실 '잘라내기'에 가깝다. 왜냐면 이 과정에서 보여질 깊이를 설정하여 필요없는 부분은 잘라내 버리기 때문이다. 물론 카메라의 초점 조절이 어떤 깊이에 있는 물체를 '깨끗하게' 잡을 것인가를 정의한다는 면에서 비슷하기는 하지만 '잘라내기'를 하지 않는다는 점에서 조금 다르다. 

마지막으로 네번째가 '현상하기'인데 OpenGL에서의 사진 현상은 모니터에 그려내기와 같다. 이 과정을 Viewport Transformation 이라고 한다. 

이 일련의 과정들에서 주의해야 할 것들이 몇가지 있다. 

1. Viewing Transformation은 반드시 Modeling Transformation 보다 우선적으로 선언되어야 한다. 이 말은 카메라를 먼저 놓고 물체를 그리라는 말인데 정확한 이유는 설명되어 있지 않지만 내 생각에는 물체를 옮기고 변형하는 과정에서 계산된 매트릭스가 카메라를 놓는 Viewing Transformation에 영향을 미치면 예상치 못한 결과가 나올수 있기 때문이 아닐까 싶다. 상식적으로 생각해도 카메라를 먼저 놓고 물체를 놓는게 OpenGL의 세계에서는 합당한듯 하다. 

2. 뭔가를 그리기 전에는 항상 glLoadIdentity() 함수로 현재의 매트릭스를 초기화 한다. 이것은 매우 중요한 부분인데 먼저 이해해야 할 것이 OpenGL은 똑똑하지 않다. 렌더링 과정에서 사용되는 매트릭스가 있는데 이 매트릭스는 C의 static 과 같은 속성을 가진다. 즉, 한번 초기화된 후 사용자가 다른 값을 넣으면 계속 그 값을 유지하게 된다는 것이다. 렌더링을 할때 마다 그 값이 초기화 되지 않고 이전의 값을 유지하므로 적절한 시기에 초기화 하지 않으면 앞에서 계산된 값이 계속 적용되어 완전 예상 밖의 결과가 나온다. 고로 매번의 렌더링 마다 적절한 곳에서 초기화가 필요하다.

3. glMatrixMode() 함수를 이용하여 매트릭스 선택하기. 앞서 2번에서 말한 렌더링 과정에 사용되는 매트릭스는 두 가지가 존재한다. 하나는 GL_MODELVIEW고 다른 하나는 GL_PROJECTION 이다. GL_MODELVIEW는 Modeling Transformation과 Viewing Transformation에 관련된 매트릭스라는 의미고 GL_PROJECTION은 Projection Transformation에 관련된 매트릭스라는 의미다. glMatrixMode() 함수에 GL_MODELVIEW 인자를 넣게 되면 Modeling Transformation과 Viewing Transformation에 관련된 연산을 하는 매트릭스를 현재의 매트릭스로 선택하라는 의미고 마찬가지로 GL_PROJECTION 은 Projection Transformation에 관한 매트릭스를 현재의 매트릭스로 선택하라는 의미다. 

참 답답하게도 OpenGL은 현재의 매트릭스를 하나만 정해 사용할 수 있는 고집쟁이다. (아마도 최고의 스피드를 내기 위해 그런듯) 그래서 위의 명령을 이용해 다음 명령들에 의해 영향을 받을 매트릭스를 지정해 준다. 고로, glMatrixMode(GL_MODELVIEW)를 호출한 다음 glLoadIdentity()를 호출하면 물체를 놓고 움직이는 것에 관련된 매트릭스를 초기화하게 되는 것이다.

이제 Red Book에 나오는 예제를 이용해서 설명을 해보겠다.

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(1.0, 1.0, 1.0);
glLoadIdentity();         // 6. 매트릭스 초기화

/* Modeling Transformation & Viewing Transformation */
gluLookat(0.0, 0.0, 5.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);  // 7. Viewing Transformation
glScalef(1.0, 2.0, 1.0);                                        // 8. Modeling Transformation
glutWireCube(1.0);                                            // 9. 렌더링
glFlush();
}

void reshape(int w, int h)
{
glViewport(0, 0, (GLsizei)w, (GLsizei)h);             // 1. Viewport Transformation
glMatrixMode(GL_PROJECTION);                        // 2. GL_PROJECTION 매트릭스 선택
glLoadIdentity();                                                // 3. 매트릭스 초기화
glFrustum(-1.0, 1.0, -1.0, 1.0, 1.5, 20.0);               // 4. Projection Transformation 
glMatrixMode(GL_MODELVIEW);                         // 5. GL_MODELVIEW 매트릭스 선택
}

위의 코드는 일부만 나타낸 것이지만 렌더링에 관련된 모든 부분이다. 번호가 매겨진 순서대로 렌더링이 일어난다고 생각하면 된다. reshape 함수는 최초 윈도우 생성시 및 윈도우 크기 변경등이 발생할때 호출되는 함수로 우선적으로 호출된다고 보면 된다.

제일 먼제 Viewport Transformation을 통해 보여질 화면을 스크린의 좌표계에서 어디서 어디까지인지 정의하였다. 이 함수는 매우 간단하다. 현재 나의 스크린이 1024 x 768이라고 하고 이 모든 영역에 OpenGL 렌더링을 하고 싶다면 걍 glViewport(0, 0, 1024, 768) 하면 그만이다. 입력으로 들어오는 w와 h값을 이용하는데 이것은 일반적인 프로그래밍의 경우 새로 변경된 윈도우의 크기가 될 가능성이 매우 높다. 

2번에서 GL_PROJECTION 매트릭스를 선택했다. 그리고 바로 3번에서 초기화 했고 (이전의 값 삭제) 4번에서 glFrustum() 함수를 이용해서 렌즈조절 (보여질 영역설정)을 했다. 이 함수는 perspective transformation을 하는데 원근법에 따라 멀리 있는 물체를 작게 보여준다는 의미다. 이와 반대로 직교법 (Orthographic transformation)을 이용하는 함수는 glOrtho() 함수가 있다. 

그리고 탈출하기 전에 선택된 매트릭스를 GL_MODELVIEW로 변경시켰다. 이제 다음은 직접적인 렌더링을 하는 함수인 display 함수이다. 우선 6번을 통해 선택된 GL_MODELVIEW 매트릭스를 초기화 시키고 7번을 통해 카메라를 위치시키는 Viewing Transformation을 수행한다. gluLookAt( 눈의 위치 (x,y,z), 쳐다볼 위치(x,y,z), 카메라 위쪽 방향 (x,y,z))를 이용해 아주 간단하게 카메라를 위치시킨다. 그리고 8번은 물체를 그릴때 적용될 Transformation을 정의한 것인데 y 축방향의 좌표는 2배로 적용될 것이라는 의미다. 그리고 나서 렌더링에 들어간다...

쓰다보니 좀 부족한 설명이 있는데 각 함수들에 대한 설명은 OpenGL 매뉴얼이나 검색을 하면 쉽게 얻을 수 있어서 생략했다. 이런 과정을 통해서 렌더링이 일어난다는 것만 설명했다. 아무래도 가장 중요한건 OpenGL의 상태 변수는 Static 속성을 가진다는 것이 아닐까 싶다... 디버깅 프로그램을 이용해 현재 무슨 값을 가지는지 쉽게 볼 수 있다면 이것이 그리 중요하지 않을지 모르나 OpenGL에서는 현재의 상태를 확인하기 위해서는 별도의 함수를 매번 호출해야 하므로 쉽게 확인이 불가능하다. 고로 보여지지 않으므로 무슨 일이 벌어지는지 알기 어렵다. 그래서 새까만 화면이 나오더라도 뭐가 잘못된건지 알수가 없는 경우가 허다하다.

'OpenGL' 카테고리의 다른 글

Convex Hull, Concave Hull  (0) 2010.02.24
OpenGL 블렌딩  (3) 2010.02.24
glPolygonMode()와 glCullFace()  (0) 2010.02.19
OpenGL Rendering Pipeline  (0) 2010.02.18
OpenGL Shader를 이용해 YUV 420 포맷 색상을 RGB로 변경하기  (4) 2009.07.25
posted by 대갈장군
2010. 2. 19. 06:09 OpenGL
OpenGL에서 폴리곤 (다각형)은 앞면과 뒷면이 존재한다. glPolygonMode() 함수를 이용하면 앞면과 뒷면을 어떻게 그릴 것인지 설정할 수 있다.

glPolygonMode(GLenum face, GLenum mode); 
- face 인자로 올수 있는 것은 GL_FRONT_AND_BACK, GL_FRONT, GL_BACK 등이 있고 mode 인자로 올수 있는 것은 GL_POINT, GL_LINE, GL_FILL 등이 있다.

첫번째 인자로 앞면과 뒷면 혹은 앞뒤 둘 다에게 두번째 인자로 오는 mode를 적용하게 된다. 뭐, mode 인자로 올 수 있는 것들은 상식적으로 이해 가능한 놈들이다. 포인트로 그릴거냐 선으로 그릴거냐, 아니면 채워넣을 거냐...


 


첫번째 그림은 원뿔인데 정상적으로 보인다. 이 경우 glPolygonMode의 두번째 인자를 GL_FILL로 주었기 때문에 밑을 구성하는 원이 제대로 그려졌다. 헌데 만약 GL_LINE을 주게 되면 아래를 구성하는 원이 선으로 그려지게 되고 아래 그림처럼 뻥 뚫린것 처럼 보이게 된다.

또 다른 함수인 glCullFace는 앞면과 뒷면을 '파낼것' 인가 말것인가를 지정한다. '파낸다'라는 말이 우습게 들릴수도 있다... 나는 처음에 들었을때 코파냐... 라고 생각했었따. -_-

예를 들어 벽돌을 그린다고 해보자. 벽돌 안은 절대 보일 일이 없다. 고로 벽돌을 구성하는 6개의 폴리곤 (사각형) 들은 보여질 면만 그리면 된다. 안보여질 부분은 안그리는게 속도 향상에 도움이 된다. 고로 glCullFace 함수로 그걸 지정해준다 이말이다. 

다만 주의 할 것은 이 함수를 불러내서 사용하기 전에 반드시 glEnable(GL_CULL_FACE) 함수를 먼저 호출하여 '파내기' 상태를 YES로 변경해야 한다.

고로 예를 들어 보여지지 않을 후면을 모두 파내버리고 싶다면,
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
이라 하면 오케 바리 바리 발바리..

한가지 짚고 넘어갈 점은 시계방향 (CW)와 반시계방향(CCW)에 대한 것인데 일반적으로 모든 폴리곤 삼각형은 반 시계 방향이 정면이다. 즉, CCW (Counterclock wise)가 Front Facing Polygon 이라는 말이다. 그래서 Vertex (점)을 공간상에 찍어서 사각형을 그려낼때 항상 반시계 방향으로 그려주게 된다.

하지만 '나는 시계 방향 주의자야!' 라고 하는 분들은 이것을 glFrontFace() 함수를 이용해 변경할 수 있으나, 필요하다면 사용하겠지만 최대한 피할 수 있다면 피하는게... 
posted by 대갈장군
2010. 2. 19. 00:25 풉...


posted by 대갈장군
2010. 2. 18. 07:33 프로그래밍
Convex Hull 을 한국어로 정확하게 해석하자면 '볼록 껍데기' 정도라 하겠다. 2차원 공간에서 임의의 점들이 x와 y 축에 퍼져 있을때 이 점들의 외곽선을 연결하는 꼭지점들 (Vertex) 만 찾아내는 알고리즘이 바로 Graham's Scan이다. 

일단 몇가지 정의 해야 할 것들이 있다. Q는 2차원 공간상의 임의의 점들의 집합이고 각각의 점들을 P0, P1, P2 ... 와 같이 표현한다.

스택 S는 점들을 저장하는 스택인데 이 스택에 모든 점들을 최소한 한번씩은 집어 넣은 다음, 만약 어떤 점이 외곽선을 구성하는 점이 아닐 경우 스택에서 뽑아낸다. 결국 모든 과정을 끝낸후에 스택에 남은 점들은 외곽선을 구성하는 점들이 될것이다. 

그리고 CH(Q)는 Convex Hull(Q)의 약자로 점의 집합 Q에서 외곽선을 구성하는 점들만의 집합을 말한다. 이 CH(Q)가 우리가 최종적으로 원하는 점들이 될것이다.

자, 이제 단계별로 Graham's Scan을 살펴보자.

1. P0 정하기 - 제일 먼저 해야 하는 것은 시작점을 정하는 일이다. P0는 가장 작은 y 값을 가지는 점이다. 만약 가장 작은 y 값을 가지는 점이 한개 이상 있다면 그들중 가장 작은 x 값을 가지는 점을 찾아서 그 놈을 P0로 정한다. 이렇게 정하는 이유는 Graham's Scan 이 기본적으로 cross product를 사용하기 때문이다.

간단하게 말해서 P0, P1, P2 라는 3개의 점이 있을때, (이 세점은 직선상에 놓인 점이 아니어야 한다는 가정아래) 이 세개의 점의 외적 (cross product)의 부호를 구하면 P2 점이 P0와 P1이 만드는 직선을 기준으로 왼쪽에 놓이는지 혹은 오른쪽에 놓이는지 알수 있다. 이것을 Pseudocode로 표현하면, 다음과 같다.
# Three points are a counter-clockwise turn if ccw > 0, clockwise if
# ccw < 0, and collinear if ccw = 0 because ccw is a determinant that
# gives the signed area of the triangle formed by p1, p2, and p3.
function ccw(p1, p2, p3):
    return (p2.x - p1.x)*(p3.y - p1.y) - (p2.y - p1.y)*(p3.x - p1.x)
만약 마지막 세번째 점이 앞의 두점이 이루는 직선의 왼쪽에 있으면 Counter-clockwise가 되어 ccw 함수는 양의 값을 리턴하고 반대로 세번째 점이 앞의 두점이 이루는 직선보다 오른쪽에 있다면 Clockwise가 되어 ccw 함수는 음의 값을 리턴한다. 만약 세점이 직선상에 위치하게 되면 0을 리턴한다.

2. 점 P0를 기준으로 각 점마다 각도 구하여 작은 순서에서 큰 순서로 정렬하기 - 이 과정이 내가 조금 헷갈렸던 부분인데, 나는 원점을 기준으로 각도를 구했다가 낭패를 봤다. 


구해야 하는 각도는 위 그림처럼 원점을 기준으로 한 각도가 아닌 P0 점을 기준으로 한 각 점들의 각도를 구해야 한다. 이것을 구하기 위해서는 atan2 함수를 사용하면 된다. 원래 tans는 x의 증가량 분의 y의 증가량인데 이 구해진 기울기 값을 tan의 역함수인 atan2 함수에 대입하면 각도가 나온다. 다만, +, - 기호에 주의해야 하는데 이건 웹 서핑하다보면 각 언어별로 적절한 코드가 존재하니 찾아보면 된다. Google 에서는 Angle between two points 라고 하면 여러개가 뜬다.

옆의 그림은 Graham scan을 간단하게 설명한 그림이다. (위키에서 퍼왔음) 일단 P, A, B, C, D의 점들이 있는데 가장 y값이 적으면서도 가장 x 값이 적은 P 점을 시작점으로 잡는다. 그리고 P 점을 기준으로 각도를 구하는데 각도가 적은 순으로 나열하면 A, B, C, D가 된다. 이제 알고리즘을 돌리기 위한 준비가 끝났다.

3. 스택 S에 첫 세점 (시작점 포함) 을 집어 넣는다. 왼쪽 그림에서는 P, A, B가 첫 세점이다. 그러면 스택 S는 |P|A|B| <- 요런 모습을 하고 있을 것이다. (B가 가장 상위 스택)

4. 이제는 For문을 이용하여 i = 3 부터 남아 있는 점들 모두에 대해 스캔을 시작한다. 각각의 i에 대해서 3개의 점이 이루는 cross vector의 방향성을 체크하여 그 값이 음이면, 즉 앞 두점이 이루는 선보다 오른쪽에 위치하면 그 점은 외곽선 내부에 위치하므로 과감하게 스택 S에서 빼버리고 그 다음 점을 스캔한다. 이것을 수도 코드로 표현 하자면,

for i = 3 to m (여기서 m은 전체 포인트의 갯수)
   
   do while (스택 S의 최상위 바로 밑의 점과 최상위 점, 그리고 포인트 Pi 가 시                     계방향인지 반 시계 방향인지 검사하여 만약 시계 방향이라면, 즉                       앞 두점이 만드는 직선보다 세번째 점이 오른쪽에 있다면)
           do Pop(S) // 스택 S에서 최상위 점 제거

   Push(Pi, S)    

이걸 걍 보면 잘 이해가 안되니 하나하나 그림을 보면서 해보자.
우선 앞서 말한것 처럼 스텝 1,2를 끝내고 나면 스택 S에는 |P|A|B| 가 들어가 있는 상태다. 여기서 for 문을 들어가게 되면 최상위 스택의 바로 아래 점 (A)와 최상위 스택의 점 (B) 그리고 Pi 점인데 i가 3에서 시작하므로 P3인 점은 바로 C이다. (P0 = P, P1 = A, P2 = B, P3 = C, P4 = D)

이 세점을 이어보면 AB가 만드는 직선의 왼쪽편에 점 C가 존재하므로 조건이 만족하지 않는다. 따라서 while 문을 탈출하여 Push(Pi, S)를 하게 되는데, 그러면 스택에는 |P|A|B|C| 처럼 C가 들어가게 되고 제일 위에 위치한다.

이때 while 문 내부의 조건을 함수로 표현하면 간단하게 ccw(스택 최상위 바로 아래 점, 스택 최상위 점, Pi) <= 0 로 표현 가능하다. 0보다 적거나 같다는 의미는 '일직선 상에 놓이거나 아니면 오른쪽 편 (시계 방향으로 돌거나)에 위치하거나' 라는 의미다.

자 그런데, 스택에 C를 넣었다는 의미는 즉, C가 외곽선을 구성하는 점들중 하나라는 의미인데 그림을 보면 그렇지 않다. 이는 바로 다음 for 루프에서 찾아진다.

i 값이 하나 증가하여 4가 되었고 마찬가지로 while 문에 들어가게 되면 최상위 아래점 (B)와 최상위점 (C) 그리고 P4 (i=4) 점에 대해 방향성 검사를 한다. 이때 점 B와 C가 이루는 직선의 '오른쪽' 편에 점 D가 존재하게 된다. 고로 음의 값을 리턴하며 마침내 Pop(S) 문을 수행한다.

고로 최상위 스택값이던 C점이 스택에서 제거가 된다. 고로 스택 S는 |P|A|B| 가 되어 원상 복구된다. 즉, C점을 제거한 셈이다. 이 과정은 아주 간단한 논리다. 가장 외곽에 존재하는 점들은 절대로 앞 두점을 기준으로 한 직선의 오른쪽 편에 존재하지 않는다는 원리를 사용한 것이다. 만약 오른편에 존재한다면 그 점은 외곽선에 포함되지 않는다는 간단한 논리인 셈이다.

그리고 이것이 while 문인 이유는 두 개 이상의 점이 실제로는 외곽선 상의 점이 아님에도 불구하고 외곽선으로 판정되는 경우가 종종 있기 때문에 이런 경우 이런 모든 점들을 제대로 스택에서 제거하기 위해서 while문을 이용하여 스택에서 차례 차례 제거한다. while 문에서 i 값은 늘 고정되어 있는데 비해 스택의 최상위 점만 계속 제거해 나가는 구조를 보면 쉽게 이해할 수 있다.

마지막으로 while문을 벗어난 후 현재 i = 4의 점인 D를 스택 S에 집어 넣는다. |P|A|B|D| 요렇게. 결국 남은 4개의 점은 위의 그림에서 정확한 외곽선을 이루는 점들이다. 

이런 알고리즘이 그닥 무슨 효용이 있을까 생각하시는 분들 많을 텐데 생각외로 매우 유용할 수 있다. 내가 이 알고리즘을 사용하려고 했던 목적은 사실 임의의 모양을 가지는 사각형이 있고 임의의 점 x가 있을때 이 x 점이 사각형 내부에 존재하는지 아니면 외부에 존재하는지 체크하는데 이 알고리즘을 적용했다.

만약 사각형의 네개의 점을 위의 그림에서의 P, A, B, D라고 한다면 임의의 점 x가 사각형 내부에 존재한다면 사각형의 각 직선 (PA, AB, BD, DP) 에 대해 점 x는 반드시 왼쪽에 위치해야 한다. 만약 점 x가 사각형 외부에 존재하거나 직선위에 놓이게 되면 방향성 검사에서 음의 값이나 0을 리턴하게 되어 있다. 

네이버에서 임의의 사각형 내부에 존재하는 점 찾기를 검색해 보면 각 직선의 방정식을 이용하기 등 좀 까다로운 방법들이 많은데 내가 볼때는 이 방법이 가장 '컴퓨터 프로그램'적이지 않나 싶다. 물론 주의해야 할 점은 numerical error가 존재하므로 좌표계를 적절히 조절할 필요가 있다는 점이지 싶다.

posted by 대갈장군
2010. 2. 18. 05:41 나의 이야기

내가 가장 좋아하는 사진. 알라스카에서 마구 마구 찍다가 얻어걸린 보물...
s

'나의 이야기' 카테고리의 다른 글

영화 인셉션에 나오는 명대사  (2) 2011.03.09
진실 = 변하지 않는 마음  (0) 2010.02.23
기도  (2) 2010.02.03
'무한도전' 논란에 대한 내 생각  (1) 2009.11.24
노무현 대통령 타살 의혹  (0) 2009.05.27
posted by 대갈장군
2010. 2. 18. 05:21 OpenGL


OpenGL 렌더링 파이프 라인에 대해서...

1. Pixel Data / Vertex Data
3차원 공간의 임의의 점 X는 위치 정보 (x,y,z)를 가지고 색상 정보 (RGB)도 가질 것이다. 이것이 바로 Vertex Data와 Pixel Data다. 이 두 놈이 입력으로 들어간다.

2. Display Lists
Display Lists는 미리 그려 놓은 그림들의 목록이다. 자주 사용되는 물체 (그림)을 미리 그려놓고 필요할때 신속히 꺼내서 그려낼수 있는데 이것이 바로 Display List 다. 프로그래밍에서 가장 흔한 '저장시켜놨다가 빨리 불러오기' 기법인 셈이다. 

3. Evaluators
모든 도형들 (2차원 도형이건 3차원 도형이건) 은 점(vertex)으로 표현된다. 예를 들자면, 사각형이 점 4개로 표현되고 오각형은 6개 정육면체 (3차원 도형)도 점 8개로 표현된다. 곡선이나 평면들도 처음에는 몇 개의 점으로 표현되거나 함수로 표현되지만 Evaluator를 거치면서 이런 함수적인 표현을 '점의 표현'으로 바꿔준다. 뭐 결국 따지고 보면 두 개의 점 사이에 놓인 점들을 인터폴레이션을 이용해 생성해낸다는 의미 아닌가? 이때 적용하는 방법이 이른바 'Polynomial mapping' 인데 이것을 사용하면 표면의 Normal vector와 texture coordinates 그리고 색상등을 알수 있다.

4. Per-Vertex Operations
Vertex data 에 대한 다음 Step은 Per-Vertex Operation 인데 이놈은 Vertices를 Primitives로 바꿔주는 놈이다. 여기서 잘 보면 Vertices (여러개의 점들을) Primitives (직선 또는 삼각형 또는 사각형, 혹은 다각형) 으로 바꾼다는 의미다. 이때 일부 Vertex Data는  4 x 4 floating-point matrices를 이용해서 transformed 된다. 이 말이 어렵게 들릴지 모르나 사실은 쉬운 이야기다. 3차원 공간의 물체를 2차원 평면 (모니터 스크린)을 통해서 보려면 3차원 -> 2차원 변형이 필요한데 이때 사용되는 특별한 함수가 있다. 이 함수를 행렬로 표현하면 4 x 4 형태의 매트릭스가 된다. 고로 3차원 공간을 2차원 평면에 투영시키기 위한 일종의 함수 대입 과정일 뿐이다. 

이 단계에서 추가로 가능한 작업들이 몇가지 있는데 만약 텍스쳐가 사용되었다면 텍스쳐 좌표가 생성되고 투영되며 조명이 있다면 그것도 계산해야하고 물질 표면 속성이 설정되어 있다면 이것 역시 여기서 다 계산한다. 좀 많네...

5. Primitive Assembly
Clipping 은 Primitive Assembly의 주요 파트인데 이것은 안보이는 부분 잘라내기다. 이 과정이 끝나면 나오는 결과물은 완전한 Geometric Primitives 들인데 (3차원 도형들) 이 놈들은 2차원 평면에 표현되기 위해 적절하게 Transformed 된 상태이며 적절히 Clipped 된 상태이다. 게다가 각 포인트의 색상과 깊이 그리고 텍스쳐 좌표까지 가지고 있다. 고로 이놈들은 다음 단계인 Rasterization 과정에서 가이드 라인으로 사용된다.

6. Pixel Operation
자 Vertex Data 들이 3,4,5의 과정을 거치는 동안 Pixel Data 는 이른바 Pixel Operation 과정을 거치는데 시스템 메모리 상에 존재하는 Pixel들은 우선 Unpacking ( 풀어내는 과정)을 거치는데 이때 수많은 포맷들 중 하나의 형태로 풀어진다. 그런 다음 각종 처리 (Scaling, Biasing, Pixel mapping) 를 거치게 된다. 이 과정을 사용자가 모두 세부 설정을 할 수 있는 것들이다. 그런다음 그 결과물은 Texture Memory에 저장이 되거나 혹은 Rasterization Step 으로 보내지게 된다. 

7. Texture Assembly
이 과정은 말 그대로 텍스쳐 입히기이다. 뭐 별다른 설명은 지금으로서는 필요 없을 듯하다.

8. Rasterization
이 단어를 사전에서 찾아보면 '인쇄하기' 인데 대략 그 말이 맞다. OpenGL 적으로 표현하자면 지금까지 모은 도형 정보와 픽셀 정보를 Fragment로 인쇄한다. 이 Fragment는 하나의 픽셀 (화면상에 보여질 픽셀)에 대응되는 놈으로 각 Fragment는 색상과 깊이 값을 가진다. 

9. Fragment Operations
화면에 보여지기 위한 최종 단계로서 스크린과 같은 화면을 저장하는 Frame buffer에 저장하기에 앞서 여러 가지 계산 과정을 거쳐야 한다. 예를 들자면 Alpha 테스트 (투명도 테스트), Stencil 테스트 (스텐실 테스트), 깊이 테스트등등. 이런 일련의 테스트들을 사용자가 모두 정의하고 어떤 방식으로 계산할 것인지를 지정할 수 있다. 즉, 사용자 맘대로 출력 할 수 있다는 것이다.





posted by 대갈장군
2010. 2. 3. 03:59 나의 이야기
교회를 가서 기도를 할 때 눈을 뜨고 기도를 들어보았는가?

눈을 감고 듣는 것과 눈을 뜨고 듣는 기도...
두 손을 모으고 기도하는 것과 그렇지 않고 기도하는 것...

이미 신자라면 둘의 차이가 크지 않을지 모르나, 믿음이 없는 나와 같은 사람에게 이 둘의 차이는 엄청나다. 눈을 뜨고 기도를 들어보면 아무런 감동도 없고 느낌도 없다.

문득 이런 생각이 들었다. 

왜 기도 할때는 눈을 감을까? 왜 기도 할때는 두 손을 모을까? 왜 기도를 끝 마칠때에는 아멘이라고 할까?
누가 정한 룰일까? 

잠자리에 누워 눈을 감으면 별별 생각이 난다. 눈을 감고 상상의 나래를 펼치기도 한다. 즉, 눈을 감는다는 것은 다른 세계로의 진입을 의미한다. 

이 다른 세계란 내가 원하는 이상 세계. 눈을 감는다는 단편적인 현상은 '죽음'과 일맥상통한다. 

즉, 눈을 감고 기도한다는 것은 내가 생각하는 이상 세계, 즉, 하느님을 믿는 사람의 경우 하느님의 세상으로의 진입을 말하며 그는 곧 죽음을 의미한다.

태어나면서부터 죽음에 대한 두려움을 가지고 태어나는 인간에게 영생을 보장하는 하느님의 세계는 나약한 우리 모두가 바라는 이상 세계...

누가 기도할때 눈을 감으라고 시켰는지 아니면 사람이 스스로 기도할 때에는 눈을 감았는지는 몰라도 기도와 '눈을 감는 것'은 절묘하게 맞아 떨어진다.

결국 이 절묘함은 나에게 다시금 '종교'에 대한 진실을 묻게 한다.

과연 종교라는 것이 진실로 존재하는 것에 대한 믿음인지 아니면 사람의 두려움이 만든 이상 세계에 대한 간절함이 가짜 믿음을 만들어 낸 것인지..

두 손을 모으고 기도하는 그것 역시 '간절함'의 표현이 아닌가? 

나는 종교 자체를 비난하지는 않는다. 올바른 말과 아름다운 세상을 위한 좋은 말들이 종교에는 많이 있다. 하지만 종교의 부작용도 만만치 않다.

이것은 종교 자체가 잘못된 것이 아니라 종교를 해석하고 받아들이며 따르는 사람들의 잘못된 해석과 근본적인 인간의 욕심과 두려움 때문이다. 






'나의 이야기' 카테고리의 다른 글

진실 = 변하지 않는 마음  (0) 2010.02.23
Alaska  (0) 2010.02.18
'무한도전' 논란에 대한 내 생각  (1) 2009.11.24
노무현 대통령 타살 의혹  (0) 2009.05.27
공간 이동  (0) 2009.03.12
posted by 대갈장군
2009. 12. 19. 05:50 프로그래밍
C++이나 C#은 매우 크고 방대한 언어다. 문법도 많고 외워야 할 것도 많으며 규칙도 정말 많다. 책을 사서 1장 부터 읽다보면 3장쯤 가면 복잡해지기 시작하면서 뭐가 뭔 말인지 모르겠다... @.@ 한숨을 푹쉬고 책을 덮는다... 그리고 속으로 '더 쉬운책이 없을까?' 라고 생각한다.

내가 많이 겪은 경험이다. 이것은 책이 자습서로서의 역활을 못하고 있다는 말과 같다. 거대한 개념이 있다면 그것의 핵심에 접근하기 위해서는 부분 부분이 아닌 전체의 맥과 흐름을 집어주는 역활을 자습서는 반드시 해야 한다.

내가 읽어본 많은 책들은 그렇지 못했지만 유일하게 김상형님이 쓰신 모든 저서는 이 흐름을 잡아준다. C++, C#이라는 거대한 것을 하나하나 분리해 서로를 유연하게 연결한 다음 독자가 충분히 어떤것을 이해할 단계에 도착하면 거기서 거대한 전체 지도를 보여주면서 내가 왜 여기에 왔는지 그리고 앞으로 어떤 길을 가야 하는지 정확하게 알려준다.

김상형님의 책을 보면서 깨우친 것을 나름대로 정리하고자 하는데 그 첫째가 바로 객체 지향의 기본인 '클래스'이다.

가장 단순하게 클래스를 정의하면 C 구조체의 확장형태라고 생각할 수 있다. 그냥 뭐 이런 저런 변수를 담는 통으로 생각하기 쉽다.

하지만 C#에 들어오면서 완전 객체 지향성을 강조하게 되면서 구조체와 클래스는 '상속'이라는 결정적 차이를 가지게 된다. 바로 이 상속이 가능해 지면서 클래스는 '계층'이라는 말에 더 가까워 졌다.

상속인터페이스를 이용한 뚜렷하고 명확한 계층 구조의 클래스 설계로 한눈에 들어오는 구조적 설계가 가능해 졌다. 바로 이것이 객체 지향 프로그래밍의 핵심이다. (인터페이스는 차후 설명하겠다.)

예전에도 언급했듯이 이제는 프로그램 개발자가 두 부류로 분류가 된다. 첫째는 라이브러리 개발자다. 대형 회사, 즉, microsoft와 같은 회사에서 최종 사용자가 사용할 수많은 라이브러리 함수와 클래스를 만들어내는 사람을 말한다. 둘째는 최종 개발자다. 이 사람은 나와 같은 사람으로 대형 회사 개발자가 만들어 놓은 수많은 라이브러리 함수를 불러와 사용하기만 한다. 

고로 나와 같은 최종 개발자들은 내가 쓸 함수를 처음부터 일일이 만들어 쓰는게 아니라 '잘 불러다가' 쓰면 그만이다.

바로 이 '잘 불러다가'가 '구조 설계'이며 이 '구조 설계'를 위해 가장 사람에게 직관적이고 적합한 분류 방식이 계단식 방식, 이른바 'Class (계급 혹은 계층) 구조' 이다. 

내가 판단하기로는 클래스의 의미가 바로 여기서 나왔다고 생각하지만 물론 아닐 수도 있다. ㅋㅋㅋ (아님 말고)

상속은 부모 클래스의 모든 것을 재사용하며 동시에 추가적인 것을 곁들여 새로운 자식 클래스를 만들어내는데,  이것은 계층적 구조 설계에 딱 맞아 떨어지는 방식이다. 

클래스를 문법적으로 설명하자면, 생성자, 파괴자, 가상함수, 추상함수, 멤버 변수, 정적변수, 정적클래스, 봉인클래스, 순수 가상함수, 추상클래스 등등등등 수많은 것들이 존재하지만, 내가 이 글에서 말하고자 하는 것은 클래스라는 단어가 객체 지향 언어에서 선택 되었는가이다. 

거대한 객체 지향 언어를 한 두발 떨어져서 그 의미와 구조, 근원을 볼 수 있게 되면 세세한 문법과 규칙들이 너무나도 당연하게 받아들여지는 순간이 있다. 내가 원하는 것은 바로 그것이다.





posted by 대갈장군
2009. 11. 24. 00:20 나의 이야기
무한도전에 대해 말이 많다. 우선 정준하에 대한 논란인데 이건 그의 설정이건 아니건 간에 정준하가 잘못했다. 무한도전을 웃고 즐기기위해 보는 것이지 아이리스처럼 스릴감을 느끼기 위해서 보는게 아니다. 보는 내내 내 마음이 불편하고 불안했다. 아무튼 김태호 PD의 말처럼 시청자가 불편을 느겼다면 그것은 분명 편집을 완벽하게 하지 못한 무한도전의 잘못이다.

이 논란외에 타블로 형의 무한도전 '비난' 논란이 일어났는데 이 부분에 대해서는 좀 할말이 많다. 우선 내가 그 사람의 생각을 '비난'이라고 정의한다는 점이 중요하다. 

자신의 생각, 즉 의견을 전달하기 위해서는 첫째로 욕을 해서는 안된다. 욕이 들어가게 되면 설득력이 떨어진다. 내가 이성적이고 논리적인 의견을 펼치게 되면 비록 나의 의견에 동의하지 않는 사람이라고 할지라도 일단 '이해'는 하게 되지만 감정적으로 욕을 쓰게 되면 나의 의견에 대해서도 '감정적'인 리플이 돌아오게 마련이다.

결국 타블로의 형은 감정적인 자신의 생각을 썼으므로 그것은 '비판'이라기 보다 '비난'에 가깝다. 결국 그 글에 달리는 리플들도 감정적일수 밖에 없으며 그것은 '악플'이라기보다 감정적인 리플, 억지로 줄여 말하면 '감플'정도라고 할 수 있겠다. 

둘째로 그의 글에서 욕을 정화시키고 그의 논리만을 본다고 하더라도 별로 설득력이 없다. 우선 미국은 지역적으로 매우 큰 나라다. 한국처럼 지역적으로 작은 나라도 각 지역마다 특색이 있듯이 미국도 각 주와 도시별로 특색이 매우 다르다.

내가 살고 있는 도시는 매우 시골스럽다. 시골스럽다는 의미는 일단 도시가 작고 사람들이 여유로우며 눈만 마주쳐도 웃으며 인사한다는 의미다. 차를 타고 나가보면 길위에서는 양보의 미덕이 펼쳐진다. 빌딩에 들어가는 입구에서는 앞선 사람이 뒷 사람을 위해 문은 열어주고 서로 'Thank you'와 'You're welcome'이 남발한다.

하지만 점점 큰 도시로 나갈 수록 서울과 같은 느낌이 들기 시작한다. 길위에서는 경적을 울리는 소리가 여기저기서나고 지나가는 사람들은 서로 눈을 안마주치며 쌩쌩 지나다닌다. 여유로움이 없으며 자신의 할 일에만 몰두한다.

뉴욕은 어떠한가? 그곳은 말그대로 세계에서 가장 바쁘고 가장 큰 도시중 하나다. 그런 곳에서 얼마만큼의 여유로움을 뉴욕커에게서 바라는가? 피자집 종업원이 박명수와 길이 영어를 못하는 동양인이라서 무시했다고 생각했다면 큰 오산이다. 단지 그 이유만으로 무시했다고 보는 것 보다는 여러가지 다른 이유가 있다고 본다. 우선 무턱대고 카메라를 들이댔다는 점이 프라이버시를 중요시하는 미국정서에 반하고 점심시간처럼 바쁜 타임에 어물정거리며 주문은 안하고 웃기만 하는 그들이 점원 입장에서는 '영양가는 없고 시간만 낭비하는 손님'으로 보였을 것이다. 이것을 보고 타블로의 형은 아마도 자신이 받은 '피해의식'과 결합을 했던 것 같은데 이것은 섣부른 판단이다.

나 역시 미국에 와서 살고 있다. 나 또한 많은 경험을 해보았다. 하지만 중요한 것은 내가 영어를 못하는 아시아인이라서 부당한 대우를 받은 것이 아니라 내가 말을 하는 상대방의 기분과 성격 그리고 미국의 문화와 정서를 이해하지 못했기 때문에 무시를 받은적이 대부분이다. 하지만 나는 그것을 '영어못하는 아시아인'이라서라고 자기 합리화하지 않았으며 다음부터는 이런일이 없도록 해야 겠다는 생각을 했을 뿐이다. 

무한도전에도 나왔지만 뉴욕의 친절한 사람들도 많이 나오지 않았는가? 결국 '영어 못하는 아시아인'이라서 무시받았다라고 생각하는 것은 자기 스스로의 피해의식에 근거한 것이며 이것을 반복하여 자신에게 되새기게 되면 모든 상황이 '영어 못하는 아시아인이라서...'로 귀결되게 된다. 앞뒤 상황을 고려하지 않은채 오직 제한된 상황을 근거로 자신의 추측만 늘어놓은 그의 비난은 설득력이 없다. 

무한도전 역시 모든 부분에서 잘한 것은 아니다. 하지만 그들이 노력은 늘 높게 평가한다. 미국에 와서 일본식 식당을 가면 늘 한국 음식 생각을 하며 '한국음식 팔면 참 장사 잘된텐데...'라고 생각한 적이 한 두번이 아니다. 실천하는 무한도전의 용기는 언제나 아름답다.

기본적으로 나라를 사랑하고 타인을 배려할줄 아는 사람이라면 단점에 대한 '욕'보다는 장점에 대한 '칭찬'을 먼저 하는 것이 발전을 위한 보다나은 방향이라고 생각한다. 


'나의 이야기' 카테고리의 다른 글

Alaska  (0) 2010.02.18
기도  (2) 2010.02.03
노무현 대통령 타살 의혹  (0) 2009.05.27
공간 이동  (0) 2009.03.12
친구 이야기  (2) 2008.12.12
posted by 대갈장군
2009. 11. 21. 06:35 카테고리 없음
네필 대함방에서 15만 어택하고 터진 대박 경험치... 후아... 유료 계정도 아닌 무료 계정에서 터진 경험치로는 최대치인것 같음... 
posted by 대갈장군
2009. 11. 17. 05:01 프로그래밍/Windows API
차일드 윈도우는 자식 윈도우다. 차일드 윈도우를 생성할때는 CreatWindow() 함수에서 3번째 인수값으로 WS_CHILD 플래그를 넣고 8번째 인자에 부모 윈도우의 핸들을 주면 된다. 

고로 상식적으로 부모 윈도우에 딸린 것이 차일드 윈도우이므로 부모 윈도우 내부 영역에서만 차일드 윈도우는 유효하다. 차일드 윈도우도 윈도우 이므로 임의의 WndProc 함수를 가질수 있다. 고로 독립적인 행동이 가능하다. 

차일드 윈도우는 부모가 파괴될 때 자동으로 같이 파괴되므로 WM_DESTROY에 대한 처리가 필요없다. 행여나 처리를 해서도 안된다. 

팝업 윈도우는 차일드와는 달리 부모 윈도우의 작업 영역을 벗어날 수 있고 부모 윈도우 이동시에도 자신의 위치를 고수한다. (차일드의 경우는 부모 윈도우와 같이 움직인다.) 

'프로그래밍 > Windows API' 카테고리의 다른 글

윈도우 메모리 - 2 (malloc 함수)  (2) 2011.03.11
윈도우 메모리 - 1  (0) 2011.03.10
윈도우 - SetClassLongPtr(), SetWindowLongPtr()  (0) 2009.11.17
윈도우 - WNDCLASS 구조체  (0) 2009.11.17
윈도우 - CreateWindow()  (0) 2009.11.17
posted by 대갈장군
2009. 11. 17. 04:50 프로그래밍/Windows API
윈도우 클래스 와 윈도우는 실행 중에도 그 속성을 변경할 수 있다. 다시 말해서 윈도우 클래스에서 설정했던 각종 속성을 실행중 변경가능 하다는 말이다. 이것이 대단한 이유는 서브클래싱이라는 기법을 가능하게 해주기 때문이다.

서브 클래싱이란 윈도우마다 설정되어 있는 동작 함수인 WndProc를 실행중에 교체함으로써 전혀 다른 동작을 할수 있게 만들어주는 기법이다. 

아무튼, 총 8가지의 윈도우 클래스 / 윈도우 속성 설정 함수가 있으나 64비트 운영체제가 도입된 이후로는 기왕이면 Ptr이 붙은 64 비트용 함수를 사용하는 것이 범용성 면에서 유리하다.

윈도우 클래스 속성 설정 함수는 (WNDCLASS 변경) GetClassLongPtr()과 SetClassLongPtr() 이고, 윈도우 속성 설정 함수는 GetWindowLongPtr()과 SetWindowLongPtr() 함수다. 여기서 윈도우 프로시져 함수의 주소를 바꾸고 싶다면 GWLP_WNDPROC를 인수로 넣으면 된다. 

주의 할 것은 스타일이 플래그 형식으로 비트의 On/Off에 의해서 판단하므로 대입연산이 아니라 & 또는 | 연산으로 플래그를 설정해야 한다는 점이다.


'프로그래밍 > Windows API' 카테고리의 다른 글

윈도우 메모리 - 1  (0) 2011.03.10
윈도우 - 차일드, 팝업  (0) 2009.11.17
윈도우 - WNDCLASS 구조체  (0) 2009.11.17
윈도우 - CreateWindow()  (0) 2009.11.17
메모리, Win32 vs. Win16  (2) 2009.05.22
posted by 대갈장군
2009. 11. 17. 03:34 프로그래밍/Windows API
CreateWindow() 함수를 사용하여 응용 프로그램 로컬 윈도우 클래스를 생성하고자 한다면 WNDCLASS 구조체를 채워넣어야 한다.

typedef struct {
    UINT style;
    WNDPROC lpfnWndProc;
    int cbClsExtra;
    int cbWndExtra;
    HINSTANCE hInstance;
    HICON hIcon;
    HCURSOR hCursor;
    HBRUSH hbrBackground;
    LPCTSTR lpszMenuName;
    LPCTSTR lpszClassName;
} WNDCLASS, *PWNDCLASS;

이 구조체 중에서 중요한 3가지는 lpszClassName, lpfnWndProc, 그리고 hInstance 요소로서 이 세놈은 기본값이 없으므로 생략할 수 없다. 

lpszClassName이 바로 CreatWindow() 함수의 첫번째 인자가 될 것이므로 되도록이면 만들고자 하는 윈도우를 잘 나타내는 이름을 지어주자. 

hInstance는 이 윈도우 클래스를 등록한 응용 프로그램의 인스턴스 핸들이다. 여기서 지정된 응용프로그램이 종료되면 윈도우 클래스도 같이 파괴된다. 주로 WinMain 으로 전달된 hInstance 인수를 그대로 사용하면 된다.

마지막으로 lpfnWndProc는 메시지 처리 함수다. 뭐, 이놈이 사실 내가 만드는 윈도우의 모든 동작을 정의한다. 

이 외에 style 인자가 재미 있는 녀석인데 윈도우의 스타일을 지정하는 인수다. 지정할 수 있는 것들로는 
StyleAction
CS_BYTEALIGNCLIENT Aligns the window's client area on a byte boundary (in the x direction). This style affects the width of the window and its horizontal placement on the display.
CS_BYTEALIGNWINDOW Aligns the window on a byte boundary (in the x direction). This style affects the width of the window and its horizontal placement on the display.
CS_CLASSDC Allocates one device context to be shared by all windows in the class. Because window classes are process specific, it is possible for multiple threads of an application to create a window of the same class. It is also possible for the threads to attempt to use the device context simultaneously. When this happens, the system allows only one thread to successfully finish its drawing operation.
CS_DBLCLKS Sends a double-click message to the window procedure when the user double-clicks the mouse while the cursor is within a window belonging to the class.
CS_DROPSHADOW Windows XP: Enables the drop shadow effect on a window. The effect is turned on and off through SPI_SETDROPSHADOW. Typically, this is enabled for small, short-lived windows such as menus to emphasize their Z order relationship to other windows.
CS_GLOBALCLASS Specifies that the window class is an application global class. For more information, see Application Global Classes.
CS_HREDRAW Redraws the entire window if a movement or size adjustment changes the width of the client area.
CS_NOCLOSE Disables Close on the window menu.
CS_OWNDC Allocates a unique device context for each window in the class.
CS_PARENTDC Sets the clipping rectangle of the child window to that of the parent window so that the child can draw on the parent. A window with the CS_PARENTDC style bit receives a regular device context from the system's cache of device contexts. It does not give the child the parent's device context or device context settings. Specifying CS_PARENTDC enhances an application's performance.
CS_SAVEBITS Saves, as a bitmap, the portion of the screen image obscured by a window of this class. When the window is removed, the system uses the saved bitmap to restore the screen image, including other windows that were obscured. Therefore, the system does not send WM_PAINT messages to windows that were obscured if the memory used by the bitmap has not been discarded and if other screen actions have not invalidated the stored image.

This style is useful for small windows (for example, menus or dialog boxes) that are displayed briefly and then removed before other screen activity takes place. This style increases the time required to display the window, because the system must first allocate memory to store the bitmap.

CS_VREDRAW Redraws the entire window if a movement or size adjustment changes the height of the client area.

여기서 주의해서 볼 필요가 있는 속성 두가지는 CS_DBLCLKS와 CS_NOCLOSE인데 첫번째 놈을 설정하지 않으면 마우스 더블클릭은 무시된다. (WndProc 함수로 전달되지 않는다는 말) 그리고 두번째 놈은 종료 버튼이 없도록 만든다. 심지어 Alt+F4도 안된다. 이 플래그가 설정된 경우 윈도우를 닫기 위해서는 반드시 다른 형태의 종료 방법이 제공되야 한다.


posted by 대갈장군
2009. 11. 17. 02:44 프로그래밍/Windows API
윈도우는 CreateWindow() 함수에 의해 만들어진다. 
HWND CreateWindow(      
    LPCTSTR lpClassName,     LPCTSTR lpWindowName,     DWORD dwStyle,     int x,     int y,     int nWidth,     int nHeight,     HWND hWndParent,     HMENU hMenu,     HINSTANCE hInstance,     LPVOID lpParam );
윈도우 역시 클래스로 부터 만들어지는데 이른바 '윈도우 클래스' 중 하나로 부터 만들어진다. 첫번째 인자 lpClassName은 바로 그 '윈도우 클래스'를 지칭하는 인자이다.

재미 있는 것은 MSDN에도 나와 있듯이, 
lpClassName
[in] Pointer to a null-terminated string or a class atom created by a previous call to the RegisterClass or RegisterClassEx function. The atom must be in the low-order word of lpClassName; the high-order word must be zero. IflpClassName is a string, it specifies the window class name. The class name can be any name registered with RegisterClass or RegisterClassEx, provided that the module that registers the class is also the module that creates the window. The class name can also be any of the predefined system class names. For a list of system class names, see the Remarks section.
이 첫번째 인자에 올수 있는 놈은 Null-Terminated String 혹은 A Class Atom (클래스 부류) 라고 했는데 이 놈들은 RegisterClass 함수나 RegisterClassEx 함수에 의해서 미리 (이전에) 등록되어진 놈이라고 한다.

윈도우 클래스를 크게 두가지 종류로 나누자면 시스템 (운영체제)에서 제공하는 기본 윈도우 클래스와 사용자가 정의해서 사용하는 사용자 윈도우 클래스가 있다.

운영체제가 제공하는 윈도우는 우리가 자주 사용하는 "button" "edit" 과 같은 놈들이고 사용자가 정의하는 윈도우는 WNDCLASS 구조체를 사용자가 원하는 윈도우 형태로 채워넣은 다음 RegisterClass 함수를 이용해서 등록한 후 사용하는 것을 말한다. 

그래서 내가 원하는 형태의 윈도우를 그리고 싶다면,
1. 우선 WNDCLASS 구조체의 각 요소를 내가 원하는 옵션으로 설정한다.
2. RegisterClass 함수를 이용해서 생성한 WNDCLASS 구조체를 등록한다.
3. CreateWindow 함수의 첫번째 인자에 내가 작성한 WNDCLASS 의 이름을 넣어준다. 

조금 복잡하더라도 이렇게 함으로써 사용자는 같은 형태의 윈도우를 쉽게 재생성 할 수 있다. (그것이 WNDCLASS를 생성하고 등록하는 이유)

윈도우 클래스는 범위로 분류하자면 시스템 전역 클래스, 응용 프로그램 전역 클래스 그리고 응용 프로그램 로컬 클래스로 나뉜다.

시스템 전역 클래스는 운영체제가 제공하는 윈도우 클래스들로 부팅하면 자동으로 등록되는 놈이다. 이것들이 바로 기본으로 제공되는 놈들로 button, edit, scrollbar, listbox 등이다.

응용 프로그램 전역 클래스는 주로 DLL에 의해 등록되며 이 DLL을 불러들인 프로세스에서 자유롭게 사용된다. 이것들의 예로는 프로그래스, 트리뷰, 리스트뷰 등이 있다. 의외로 이런 것들이 운영체제에서 제공되는 시스템 전역 클래스가 아니라는 점이다. 고로 윈도우의 버전과 종류에 따라 저런 부분의 구현이나 기능, 색상등이 달라지는 것이다. (DLL의 버전이 다르니까)

마지막으로 응용 프로그램 로컬 클래스는 사용자가 WNDCLASS를 정의하고 RegisterClass 함수로 등록하여 사용하는 윈도우 클래스를 말한다. 중요한 점은 클래스 이름이 중복될 경우 가장 먼저 로컬 클래스 부터 선택하고 그다음이 응용 프로그램 전역 클래스 그리고 마지막이 시스템 전역 클래스이다. 뭐, DLL과 검색 순위가 동일하다만. :)


posted by 대갈장군
2009. 9. 10. 00:29 프로그래밍
제목이 자극적이다. ㅋㅋㅋ

저놈이 바로 요근래에 날 괴롭힌 놈이다. 2009년 7월 31일자로 내 컴퓨터에 업데이트 된 놈인데 이놈은 언뜻봐서는 그 버전이 과거에 설치된 8.0.50727.762 보다 떨어지는 놈 같지만 이 어셈블리 번호는 꼭 크다고 우위를 선점하는 건 아닌가 보다.

아무튼, 이 업데이트 설치 후 VS 2005에서 컴파일 하는 C++ 프로그램은 이 어셈블리가 없으면 실행되지 않는다. 뭐 이 시스템에서는 실행할 수 없네 어쩌네 하면서 배째라고 한다.

Manifest 파일을 열어 확인해 본 결과 4053 이놈이 첫번째 줄에 떠억 자리하고 있는 것을 확인했고 이 녀석이 꼭 필요하다는 것을 알아챘다. 문제는 이 녀석이 자동으로 업뎃이 안되는 것 같다는 문제였다.

VS 2005가 설치된 컴에서는 자동으로 필수 업뎃으로 포함되는 것 같았으나 설치가 안된 컴에서는 일반적인 윈도우 업뎃으로는 설치가 잘 되지 않아 모든 Redistribution Package를 설치해야 했다.

암튼, 구글에서 Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update 를 검색하면 바로 다운로드 페이지가 뜬다. 

아마도 이런 문제를 겪은 사람은 별로 없겠지만... -_- 재수 없다면... 

암튼, .NET Framework가 어셈블리를 통해 일관성과 통일성을 추구하고자 했지만 간과한 것이 바로 이런 점이 아닌가 싶다. 필수 업데이트와 그렇지 않은 업데이트 간에 차이에서 오는 이런 사소한 실수가 어마어마한 시간의 낭비를 초래한다.

그리고, 업데이트 안하면 안되라고 들이대는 형식의 마이크로 소프트의 행태 또한 옳지 못하다. 뭐, 안되면 너희가 바보라서 그렇단다라는 식 아냐? 젠장... 


posted by 대갈장군
2009. 7. 30. 00:53 프로그래밍
C에서 가장 많이 발생하는 오류가 아마도 메모리 관련 오류가 아닌가 싶은데 이는 여러가지 원인이 존재한다. 여러개의 클래스가 겹쳐지고 상속되고 난리를 치다보면 이중해제를 하는 실수는 누구나 할 수 있다. 

이 문서는 http://www.yolinux.com/TUTORIALS/C++MemoryCorruptionAndMemoryLeaks.html을 참조하여 작성되었다.

1. C/C++에서 메모리 오류의 종류

일단 메모리 공간에 따라 크게 Heap Memory 에러와 Stack (local variables) Memory 에러가 있다. Heap 메모리 영역에서 발생가능한 에러는,

  1. 이미 해제된 메모리 다시 해제 할때
  2. 할당된적도 없는 메모리 해제 할라고 할때
  3. 이미 해제된 메모리 영역에 뭔가 데이터를 쓰려고 할때
  4. 할당된 적이 없는 메모리에 뭔가 데이터를 쓰려고 할때
  5. 메모리 할당 에러
  6. 동적으로 할당된 메모리 배열에서 초과된 index의 위치를 읽거나 쓰려고 할때 

1,2 번과 3,4번을 묶어서 볼 수 있는데 해제시에 발생하는 문제 vs 데이터 입력시 발생하는 문제로 볼 수 있다.

스택 메모리 영역에서 발생가능한 에러들로는

  1. 정적 배열에서 초과된 index의 위치를 읽거나 쓰려고 할때
  2.  함수 포인터 오류인데 잘못된 함수 포인터의 전달로 인한 잘못된 함수 호출


2. 메모리 누수!

메모리 누수는 할당한 동적 메모리를 제대로 해제하지 않고 프로그램을 종료하면 발생하는 것으로써 이것이 지속되면 컴퓨터의 RAM (빠른 메모리 공간)을 모두 소모하여 버리고 Page 파일 (하드 디스크에 생성하는 가상 메모리)를 남발하게 되여 컴퓨터의 성능을 저하시키다 결국 넉다운 된다. 

우선 이 웹사이트에서는 strdup() 함수를 예를 들어 설명하는데 좋은 예인거 같지는 않다. 아무튼 말하고자 하는 점은 malloc() 함수 (C library)로 할당된 메모리는 반드시 free()로 해제하라는 점이다.

요약하자면, 
   1. new로 할당하면 delete로 해제, malloc으로 할당하면 free로 해제.
   2. 할당 실패하면 해제 하지 말것. (할당되지도 않은 놈 해제하면 당연히 에러)
   3. 상속될 가능성이 있는 클래스의 파괴자는 반드시 가상 함수로 선언하라
   4. 포인터 사이에 대입연산 (주소복사)는 항상 메모리 누수 및 이중 해제의 가능성을 가진다.
   5. 클래스의 대입 연산자 사용시 얕은 복사가 잃어난다면 (주소만 복사) 역시나 누수와 이중해제의 위험 존재.

3. 메모리 부패 (Memory Corruption)

참 단어 선택이 오묘한데 부패라고 하니 꼭 이상한 듯 들리지만 오염보다는 나은것 같아서 그렇게 표현했다. 한국어로 뭐라해야 할지 모르겠다.

Memory Corruption은 사용자가 부주의하여 명확한 할당 없이 주소에 접근하여 데이터를 변경하려 하거나 잘못된 주소 위치로 접근하려 하는 경우를 말한다. 즉, 컴퓨터 입장에서 보면 메모리가 '부패'한 셈이다 :)

우선 흔히 발생하는 Buffer Overflow의 경우는 할당된 메모리 양보다 더 많은 데이터를 집어 넣을때 발생하는 것이고 또 다른 흔한 Memory Corruption은 할당한 배열을 초과하는 위치에 접근하는 경우다. (인덱스 초과)

그리고 또 흔한 경우로 포인터 변수로 선언한 변수에 new로 메모리를 할당하지도 않았는데 포인터 주소가 가지는 멤버 변수나 함수로 접근하는 경우다. 당연히 에러다.

free() 함수로 날려버린 변수에 접근하는 것 역시 '부패한 메모리'로의 접근이다. 

생각보다 중요한 것이 나오는데 new []로 배열을 할당한 경우 반드시 delete []로 삭제해야 한다. 이거 의외로 실수하는 경우가 많다.

함수를 호출하여 함수 내에서 선언된 지역 변수의 주소를 넘겨와 사용할 경우 그 지역 변수는 함수 리턴 된 후에 언제든 사라질 수 있는 위험을 안고 있다. 그래서 절대로 이렇게 사용하면 안된다는 점.. 명심하자.











posted by 대갈장군
2009. 7. 28. 02:48 프로그래밍/C++
나는 늘 같은 경험을 한다. 모르는 어떤 것을 알기위해 이것 저것 읽어 보다보면 끊어진 이해의 연결 고리들이 어느순간 한번에 이어지면서 한순간에 전체적인 흐름을 파악한다.

그 흐름이 파악되면 세부적인 내용은 너무나도 쉽게 쉽게 이해가 된다. 아무리 어려운 문법이라도 '음, 이건 분명 이렇게 될 수 밖에 없지...'라는 마치 알고 있었다는 듯한 느낌마저 받는다.

STL도 처음 나에게는 '이거 뭐야?' 라는 놈이었지만 지금은 '음, 이놈 복잡한 놈...' 이라는 정도의 느낌만 줄뿐 아예 모르는 놈은 아니다.

STL을 알기위해서는 템플릿도 알아야 하고 포인터에 대한 이해 및 함수 포인터 그리고 배열 및 객체 지향에 대한 이해도 필요하다.

하지만 이것은 실제적인 사용을 위해 필요한 것이고 이보다 앞서 필요한 '이해'를 위해서는 아무것도 필요없다. 무엇인가 알려고 할때는 항상 전체적인 흐름을 파악하고 왜 이것을 알아야 하는가에 대해서 먼저 답을 해야 한다.

그것을 알지 못하고 무작정 세부적인 문법만 파고들면 금새 길을 잃어버린 아이처럼 이곳 저곳을 방황하다가 결국 지쳐 울고 만다.

그렇다면 왜 사람들이 STL, STL하는지 알아보자. 과연 무엇이 그리도 좋다는 말인가?

STL은 한마디로 라이브러리다. 라이브러리... 도서관... 즉, 필요한 모든 정보가 있는 곳이다. 사용자는 이 STL을 이용해 수많은 똑똑한 개발자들이 만들어 놓은 아주 편리한 함수들을 손쉽게 꺼내어 사용할 수 있다.

프로그램을 작성하기 위해 필요한 두가지 필수 요소는 바로 알고리즘자료구조이다. 프로그램은 항상 저장된 데이터를 불러와 어딘가에 저장해 놓고 (자료구조) 그 값들을 필요에 따라 정렬, 삭제하여 (알고리즘) 원하는 것을 하는 것이다.

바로 이 두 가지 필수 요소인 자료구조와 알고리즘을 모조리 묶어서 정리한 라이브러리가 바로 STL이다. 

하지만 여기서 그치지 않는다. STL은 이름에서 처럼 Standard (일반화) 특성을 가지고 있다. 즉, 어떠한 자료구조이던 간에 상관없이 동일한 형태의 알고리즘을 제공한다는 점이다. 

이로써 사용자가 각 자료구조에 대한 각각의 알고리즘 (정렬, 삭제, 추가, 대입등) 을 일일히 정의해 줄 필요가 없어진 것이다.

이 얼마나 고마운 일인가...

게다가 STL은 이름에 있듯이 Template를 이용해 사용자가 원하는 임의의 형태로 객체를 생성해 낸다. 즉, int를 원하면 int, float을 원하면 float, 클래스를 원하면 클래스... 말 그대로 지 맘대로 객체를 생성할 수 있다.

고마워서 눈물이 날 지경이다... 상상을 해보라. 프로그래머가 자신이 사용해야 할 자료구조 (스택, 리스트, 큐) 같은 것을 프로그램 짤때마다 만들어야 한다면? 게다가 알고리즘까지 다 만들어야 한다면??

이런 복잡한 일을 다 해주는 고마운 친구가 STL인것이다.

그럼 아마도 이런 생각이 들것이다. 그럼 왜 진작부터 이거 사용안하냐고... 

좋은 질문이다... STL은 이해하기는 쉽지만 사용하기 위해서는 C++과 C에 대한 전반적인 이해가 필수이며 몇몇 단점들이 존재하기 때문이다.

우선 실행파일이 거대해 진다. 원래 STL은 속도만을 중요시 하기때문에 컴파일 타임에 링크하는 방법을 쓰지 않는다. 고로 정적 링크를 항상 하게 되므로 생성하는 STL의 객체 수와 사용하는 STL 함수만큼 정적 링크의 갯수가 늘어간다.

하지만 크기의 이점을 잃어버리는 대신 '편리함'을 얻었으니 불평하기만 할 수는 없지.

다른 문제점은 '가독성'이 열라 떨어진다는 점이다. STL을 이중 삼중으로 사용하게 되면 작성한 놈조차 '이게 뭔 말이여?' 라는 소리를 하게 되어 있다.

즉, 템플릿의 문법 자체가 복잡한데다가 일반화 특성을 추가해버렸으니 더더욱 복잡해 보인다. 그래서 제대로 사용하기 위해서는 많은 연습이 필요하다는 점이다.

많은 사람이 STL을 꺼려하는 이유는 복잡하기 때문인데다가 이를 대체할 좋고 쉽게 이해할 수 있는 MFC가 존재하기 때문이다. 

하지만 내가 얻은 소스가 STL이라면 어쩌겠는가? 즉, 결국은 알아야 한다는 말이지... 에휴... 만약 템플릿이 무엇인지 모른다면 반드시 그것부터 이해해야 한다는 말은 꼭 하고 싶다...
posted by 대갈장군
prev 1 2 3 4 5 6 next