블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2738)
Unity3D (817)
Programming (475)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (228)
협업 (58)
3DS Max (3)
Game (12)
Utility (136)
Etc (96)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (53)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday
05-03 00:02
반응형

'Programming > Win32API' 카테고리의 다른 글

IME  (0) 2010.09.02
getClienteRect 와 getWindowRect  (0) 2010.08.31
mfc, api 의 HINSTANCE 구하기 GetModuleHandle(NULL)  (0) 2010.06.03
Virtual Keys, Standard Set  (0) 2010.04.21
윈도우 핸들 제어  (0) 2010.04.14
Posted by blueasa
, |
반응형

'Programming > C/C++' 카테고리의 다른 글

C/C++에서 assert  (0) 2010.05.03
TCHAR에 관한여...  (0) 2010.04.29
다른방식의 싱글톤  (0) 2010.04.15
조건문의 최적화 방법  (0) 2010.04.14
데이터 형의 크기 및 범위  (0) 2010.04.09
Posted by blueasa
, |
class Singleton{
public:
    static Singleton &getInstance();

private:
    Singleton();
    Singleton( const Singleton & ); // 복사생성자를 막는다.
};

Singleton &Singleton::getInstance()
{
    static Singleton selfInstance;
    return selfInstance;
}

출처 : http://digitz.tistory.com/247
반응형
Posted by blueasa
, |
if 문장 안에 쓴 조건문의 표현 방식에 따라서 속도차이가 발생한다는
것입니다.

요즘 진보된 프로세서에서는 이것마저도.. 아주 훌륭하게 잘 처리되고
있지만.. (실제.. 조건문을 두세단계정도는 미리 계산하는 것이 요즘
프로세서던가?? 테스트해보질 않아서.. 하하.. 나중에 기회가 되면 한번
속도 테스트해보아야지.. :)

예를 들어서 조건문 A의 확률이 80%, 조건문 B의 확률이 20%였다면..
다음의 두 프로그램은 같은 기능을 하지만 속도에서는 약간 차이가
발생한다.

if(A || B)
  return;

if(B || A)
  return;

이경우.. 첫번째 조건문은 80%확률로 A 조건을 검사하고, 20% 확률로
A 조건과 B 조건을 검사합니다.
두번째 조건문은 20% 확률로 B 조건을 검사하고 80% 확률로 A 조건과
B 조건을 검사합니다.

예를 들어서 이 조건문이 100번 불렸다면, 첫번째는 총 120번의 조건문
검사를 하고 두번째는 총 180번의 조건문 검사를 하게 되겠죠.

초당 수십만번 불리는 함수라면, 이 단순한 차이가 속도의 차이가 될 수
있습니다.  예를 들어서 3차원 게임에서 충돌검사루틴이라면.. 이것은
장난아니겠죠.

사실.. 이것은 아주 단순한 예였고, 솔직히, 이것으로 속도 차이를
느낄 수 없겠지만..

이러한 현상은 아주 큰 틀에서도 역시 벌어진다는 것입니다.  즉 설계때
이러한 고려가 필요할 때가 발생한다는 것이죠.

예를 들어서 어떤 일을 할때 속도의 개선을 위해서 캐슁 루틴을 추가한다면
캐슁 오버헤드와 캐슁에 의한 속도증가를 검사해야합니다.  예를 들어서
캐슁 오버헤드가 1ms였고, 캐슁이 동작할 경우 벌어들이는 이득이 2ms였다면..

이경우.. 캐슁에 의한 이득이 발생할 확률에 따라서 캐슁을 할 것인지
말것인지를 결정해주어야한다.  확률이 80%였다면..
1ms - 2ms * 0.8 = -0.6ms
즉 매번 0.6ms 정도의 이득이 발생한다.
그에 비해서 확률이 30%였다면.
1ms - 2ms * 0.3 = 0.4ms
즉 매번 0.4ms 정도의 손해가 발생한다.

캐슁 확률이 높다면 캐슁 오버헤드를 감안하더래도 캐슁 루틴을 짜 넣어
주는 것이 좋겠죠.

이 역시 확률에 의한 결정이 필요한 부분입니다.

프로그램을 짜다 보면.. 이런 확률에 대해서도 생각할 필요가 있으리라
생각됩니다.


출처 : http://cafe.naver.com/dxgameprogramming.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=980
반응형

'Programming > C/C++' 카테고리의 다른 글

[C]#pragma - once, pack, warning, comment, link  (0) 2010.04.16
다른방식의 싱글톤  (0) 2010.04.15
데이터 형의 크기 및 범위  (0) 2010.04.09
const 키워드 위치에 따른 메소드의 특징  (0) 2010.04.09
String  (0) 2010.03.22
Posted by blueasa
, |
반응형

'Programming > Algorithm' 카테고리의 다른 글

lock free 알고리즘들...  (0) 2012.05.11
유도탄  (0) 2011.05.04
Posted by blueasa
, |
반응형

'Programming > Win32API' 카테고리의 다른 글

IME  (0) 2010.09.02
getClienteRect 와 getWindowRect  (0) 2010.08.31
mfc, api 의 HINSTANCE 구하기 GetModuleHandle(NULL)  (0) 2010.06.03
Virtual Keys, Standard Set  (0) 2010.04.21
Drag & Drop 예제 소스  (0) 2010.04.20
Posted by blueasa
, |
제 늦었습니다. 제게는 시간이 없습니다.”  “제가 공부하는 기계입니까? 취미 생활이나 독서를 할 여유도 없이 늘 쫓깁니다.” “전 TV볼 시간은 있어도 책을 읽으려고 한다거나 공부만 하려고 하면 시간이 없다는 생각이 먼저 들어요.” 라고 말하는 시간이 없어 고민하는 이들의 사연을 늘 접합니다.

어른은 어른대로 학생은 학생대로 시간에 쫓겨 친구들과 대화를 나눈다거나 책을 읽는다거나 음악을 듣는 여유가 사치스럽게 보이기까지 한 것이 우리의 현실이기에 하고 싶은 것도 못하고 하지 않아서 뒤떨어진 것도 시간 탓으로 돌려 버리고 맙니다.

그러나 우리에게 시간이라는 것은 있고 없고 하는 것이 아닙니다. 시간은 내가 만들어야 합니다. 모든 이들에게 똑 같은 24시간이 주어졌는데도 어떤 이는 주어진 일 외에 다른 취미생활까지 즐기나 어떤 이는 24시간을 주어진 일에만 매달려도 시간이 부족하다고 불평하는 이도 있지 않습니까. 그렇다면 왜 이런 결과가 나타날까요. 그것은 여러분이 주어진 시간을 잘 활용하지 못한 결과입니다. 돈을 잘 이용해야 살림을 잘 꾸려갈 수 있듯이 시간을 효과적으로 활용할 줄 알아야 우리의 생활을 잘 꾸려갈 수 있습니다.

돈 일 이천원을 길에 그냥 버리는 것은 미친 짓이라고 아까워하면서도 왜 길에다 한 두 시간을 버리는 것은 아까워하지 않습니까? 지금 의미 없이 보내는 그 시간은 여러분의 평생에 두 번 다시 올 수 없는 그런 시간인데도 말입니다. 이제 우리는 오늘 나에게 주어진 시간을 어떻게 활용할 수 있는가 생각해 봅시다. 우선 여러분에게 권하고 싶은 것은 매 시간에 대해서 철저한 계획을 세우라는 것입니다. 시간 계획은 저녁 시간에 내일 할 일을 메모하여 중요한 일부터 우선 순위를 정해서 시간을 분배한 후에 그 시간엔 그 일에만 온전히 정신을 집중해서 일을 처리하고 나서 다른 일로 넘어가는 훈련을 한다면 분명히 좋은 결과가 있을 것입니다.

세계적인 전도자 요한 웨슬러 목사는 5분 간격으로 계획을 세웠다고 합니다. 또 하나는 짧은 시간들을 소중히 여겨야 한다는 것입니다. “티끌 모아 태산”이라는 말을 아실 것입니다. 사람이나 차를 기다리는 시간, 차 안에서의 시간, 수업종이 울리고 선생님께서 오실 때까지의 3~4분, 아침, 저녁 자율학습시간, 그리고 매 수업시간마다 10분씩 주어지는 쉬는 시간 등, 하루 학교생활에서 우리에게 주어지는 3~4분의 자투리 시간들이 특별한 목적이나 의식도 없이 소비되고 있습니다.

아이슈타인 뿐만 아니라 놀라운 업적을 남긴 이들의 공통점 중의 하나가 모두 짧은 시간들을 잘 활용했다는 특징을 갖고 있습니다. 여러분은 지금 다시 시작하기에는 이미 늦었다고 말하면서 망설임과 초조함으로 시간을 보내고 있지는 않습니까? 이제는 미루고 걱정부터 하지 마시고 지금 늦었다고 생각할 때부터 시작하면 결코 늦지 않았음을 명심하세요.

“늦었다고 생각한 때가 가장 빠른 때이다”라고 했습니다. 오늘 여러분의 시간을 어떻게 활용하느냐에 따라 여러분의 미래는 달라집니다. 시간에 대한 긴박감을 가지고 시간을 잘 창조해 나감으로 해서 한 번 주어진 삶을 귀하고 밝게 살아가는 우리가 되어야 하지 않겠습니까?

언제까지 염려만하고 시간이 없다고만 할 것입니까? 여러분이 시작하지 못하고 있는 그 일을 지금 시작하고 싶지 않습니까?

<쪽지도서>, ‘사랑하는 이에게’ 에서 발췌


출처 : http://energybus.tistory.com/56

반응형
Posted by blueasa
, |
타입 이름 바이트 범위
char (/J 옵션에서 0 ~ 255)
signed char
__int8
1 -128 ~ 127
unsigned char
unsigned __int8
0 ~ 255
bool true or false
short
short int
signed short int
__int16
2 -32,768 ~ 32,767
unsigned short
unsigned short int
unsigned __int16
0 ~ 65,535
wchar_t
__wchar_t
0 ~ 65,535
int
signed
signed int
__int32
long
long int
signed long int
4 -2,147,483,648 ~ 2,147,483,647
unsigned int
unsigned
unsigned __int32
unsigned long
unsigned long int
0 ~ 4,294,967,295
float 3.4E +/- 38 (7 digits)
long long
signed long long
__int64
8 - 9,223,372,036,854,775,808 ~
9,223,372,036,854,775,807
unsigned long long
unsigned __int64
0 ~ 18,446,744,073,709,551,615
double
long double
1.7E +/- 308 (15 digits)

타입 이름 설명 비고
__m64 MMX & 3DNow! intrinsics MM[0-7] 레지스터
8바이트 경계 정렬
x64 미지원
__m128
__m128d (SSE2 only)
__m128i (SSE2 only, movdqa)
SSE & SSE2 intrinsics XMM[0-7] 레지스터
16바이트 경계 정렬
IPF 미지원
(movdqa : P3에서 fault 미발생)
__ptr32
__ptr64
32비트에서는 모두 32비트 포인터
64비트에서는 모두 64비트 포인터
/clr:pure 옵션에서 사용 불가
사용 예:
int * __ptr32 p32;


반응형

'Programming > C/C++' 카테고리의 다른 글

다른방식의 싱글톤  (0) 2010.04.15
조건문의 최적화 방법  (0) 2010.04.14
const 키워드 위치에 따른 메소드의 특징  (0) 2010.04.09
String  (0) 2010.03.22
enum 보다 나은 enum  (0) 2010.03.21
Posted by blueasa
, |

CDump& CDump::Func(const char* pt);
CDump& CDump::Func(char* const pt);
const CDump& CDump::Func(char* pt);
CDump& CDump::Func(char* const pt) const;

위치 상으로는 4가지이지만 이게 조합되면 더 많은 경우가 발생하게 된다.

1. CDump& CDump::Func(const char* pt);

이 경우는 Func 메소드에서 pt 포인터 변수에 문자열의 주소를 받고,이때 Func 메소드에서는 pt 포인터 변수가 가리키는 문자열의 공간의 데이터를 상수화 되어 데이터자체를 변경할 수 없다. 하지만 pt 변수는 다른 문자열 주소를 받을 수 있다. pt는 변수를 const한게 아니라 가리키는 곳을 const한 것이므로 데이터만 수정할 수 없다는 것이 특징.

2. CDump& CDump::Func(char* const pt);

이 경우는 Func메소드에서 pt 포인터변수에 문자열의 주소를 받는다.
이때 pt는 주소를 받으면서 변수가 아니라 상수라는 의미이다.달리 말하면 pt라는 변수에 다른 주소를 넣을 수 없지만 pt가 가리키고 있는 데이터공간은 const가 아니므로 데이터를 수정할 수 있다. CDump& CDump::Func(const char* pt); 메소드와의 큰 차이점.

3. const CDump& CDump::Func(char* pt);

이 메소드의 경우는 문자열을 주소를 받아서 처리하는데 Func메소드로 리턴되는 객체에 대해서 const 화 합니다. 이 메소드로 받는 객체는 const이므로 객체내의 변수나 데이터를 수정할 수 없습니다.

4. CDump& CDump::Func(char* const pt) const;

이 메소드는 Func 메소드를 처리하는 동안 자신의 객체를 const화 한다.이 메소드를 처리할 동안 객체의 모든 데이터를 수정할 수 없다는 의미이고.const CDump& CDump::Func(char* pt); 이 메소드와의 차이점은 시점차이이다.const CDump& CDump::Func(char* pt); 이 메소드는 메소드내에서는 자신의 모든 데이터를 수정하거나 가공할 수있지만 리턴 된 객체로 처리할때에는 const되는 것이특징.

하지만  CDump& CDump::Func(char* const pt) const; 이 메소드는 리턴 된 자신의 참조형 객체는 const 하지 않기 때문에 리턴된 객체로 데이터를 수정하거나 가공할 수 있고 즉, 메소드 뒤에 const는 메소드를 처리할 동안에 자신의 객체는 const화 한다는 의미이다.

 

출처 : C++ 프라이머 플러스


반응형

'Programming > C/C++' 카테고리의 다른 글

조건문의 최적화 방법  (0) 2010.04.14
데이터 형의 크기 및 범위  (0) 2010.04.09
String  (0) 2010.03.22
enum 보다 나은 enum  (0) 2010.03.21
클래스 단위로 컴파일러가 생성하는 가상함수 테이블  (0) 2010.03.17
Posted by blueasa
, |
반응형

'Programming > STL' 카테고리의 다른 글

C++ STL int -> string, string -> int 로 변환하기  (1) 2010.04.27
괜찮은 참고 사이트  (0) 2010.04.20
STL  (0) 2010.03.22
STL Container 조합하기  (0) 2010.03.21
About STL : C++ STL 프로그래밍  (0) 2010.03.21
Posted by blueasa
, |