|
|
|
|
다들 업무로 인해서 머리가 잘 안돌아 가나 봅니다. 간단하게 prototype를 작성 해보았습니다. O(N^2) 수행 시간입니다. 최적화가 필요하심 ~
// Bloodshed Dev-C++ is a full-featured Integrated Development Environment (IDE) // for the C/C++ programming language. It uses Mingw port of GCC (GNU Compiler Collection) as // it's compiler. Dev-C++ can also be used in combination with Cygwin or any other GCC based compiler.
#include <cstdlib> #include <iostream>
using namespace std;
int Src[3][5] = { {1, 2, 3, 4, 5}, {6, 7, 8, 9, 10}, {11, 12, 13, 14, 15} }; int dest[5][3] = { 0 };
int main(int argc, char *argv[]) { int k = 0; cout << "ORG buffer\n"; for( int i = 0; i < 3; i ++ ) { for( int j = 0, k = 4 ; j < 5; j++,k--) { dest[k][i] = Src[i][j]; cout << dest[k][i] << " "; } cout << " " << "\n"; } cout << "\n" << "\n"; // roniekang ---- display cout << "Result \n"; for( int i = 0; i < 5; i ++ ) { for(int j = 0; j < 3; j++) { cout << dest[i][j] << " "; } cout << " " << "\n"; } system("PAUSE"); return EXIT_SUCCESS; } 이미지를 로테이트 시키기 위해서 잠시 작성..
|
|
|
|
|
|
출처 : http://www.davechapman.f2s.com/rockbox/rgb.c코드를 그대로 가져 왔습니다. ------------------------------------------------------ #include <stdio.h> #define swap16(x) (((x) >> 8) || ((x) << 8)) #define _RGBPACK(r, g, b) ( ((((r) * 31 + 127) / 255) << 11) \ |((((g) * 63 + 127) / 255) << 5) \ | (((b) * 31 + 127) / 255)) #define _RGB_UNPACK_RED(x) (((x) >> 8) & 0xf8) | ((x) >> 13); #define _RGB_UNPACK_GREEN(x) (((x) >> 3) & 0xfc) | (((x) >> 9) & 0x03); #define _RGB_UNPACK_BLUE(x) (((x) << 3) & 0xf8) | (((x) >> 2) & 0x07); #if 1 /* RGB565 */ #define RGBPACK(r,g,b) _RGBPACK(r,g,b) #define RGB_UNPACK_RED(x) _RGB_UNPACK_RED(x) #define RGB_UNPACK_GREEN(x) _RGB_UNPACK_GREEN(x) #define RGB_UNPACK_BLUE(x) _RGB_UNPACK_BLUE(x) #else /* RGB565 Byte-swapped */ #define RGBPACK(r,g,b) swap16(_RGBPACK(r,g,b)) #define RGB_UNPACK_RED(x) _RGB_UNPACK_RED(swap16(x)) #define RGB_UNPACK_GREEN(x) _RGB_UNPACK_GREEN(swap16(x)) #define RGB_UNPACK_BLUE(x) _RGB_UNPACK_BLUE(swap16(x)) #endif int main (int argc, char* argv[]) { int c; int r,g,b; unsigned short rgb565a; unsigned short rgb565b; unsigned int rgb888; for (c=0;c<256;c++) { /* Create RGB565 */ rgb565a=RGBPACK(c,c,c); /* Unpack RGB565 to RGB888 and then re-pack to RGB565 */ r = RGB_UNPACK_RED(rgb565a); g = RGB_UNPACK_GREEN(rgb565a); b = RGB_UNPACK_BLUE(rgb565a); /* Convert back to RGB565 */ rgb565b = RGBPACK(r,g,b); printf("%3d -> 0x%04x -> (%3d, %3d, %3d) -> 0x%04x %s\n", c,rgb565a,r,g,b,rgb565b,((rgb565a == rgb565b) ? "OK" : "BAD")); } }
|
|
|
|
|
|
Joseph는 Surface를 작업하면서 팀에서 공유했던 7가지 중요 포인트를 공개했습니다.
1. Vision을 만들어라. 2. Story를 인지하라. 3. 원칙을 만들어라. 4. 가이드라인을 제시하라. 5. 진정성이 있어야 한다. 6. 비평하라. 7. 믿어라.
우리는.......???????????
|
|
|
|
|
|
- 주제: "Process, Project, Product and People" - 일시: 2008년 6월 11일 (수요일) 오후 6시~10시 - 장소: 잠실 롯데호텔 3F 크리스탈 볼룸 - 참여비: 5000원 (현장납부)
- 주최: CMMI포럼, Sten, XPer, 스마트플레이스 - 후원: itSMF 코리아 (http://www.itsmf.or.kr/)
- 참가 대상: IT관련 직군 (개발자, 기획자, 마케터, 영업, 관리, 경영, 인사 등등 모~두~)
몇년이 되어도 끝없는 이야기가 반복 되고 생성 될만한 주제인 "Process, Project, Product and People" 그 마지막이 "사람"이기 때문에 항상 끌리는 P-Camp의 만남........
아쉽게도 올해는 참석 여부가 불투명 하다. 등록은 해뒀지만, 아쉽다.
|
|
|
|
|
|
일전에 비슷한 글을 읽은 적이 있습니다. 다중 포인터를 쉽게 읽는 방법이라는 글이었는데.. 도통 기억이 나지 않는군여. 여튼 각설하고 제가 종종 들려 이것 저것 훔쳐 오는 http://www.troot.co.kr/trbbs/zboard.php?id=newgal&no=1427에서 담아 옵니다. 트랙백을 찾다 못 찾았습니다. 최초 작성자는 http://blog.cnrocks.net/ 라는 분입니다. 고운하루 되세요.!
-------
뭐. 솔직히. 실제로 이렇게 난해한 걸 쓸 줄 안다고 해서 잘난 것도 아니고. 요즘 같이 덩치가 커지는 시절에 혼자 잘났다고 짜대는 것도 문제가 있고. 경력 수년에 이르도록 헷갈리는 건 이해할 수 있지만. 그렇다고 도무지 개념없이 버티는 양반들도 있고. 여튼. 예전 노트 발췌. 중간에 상수값을 보면. 출처를 알 수 있음. 흐. int *(*(*pa[4])[3][2])[4]; -> 몇 바이트 짜리냐? 16바이트다. 맨 안쪽을 주의. int u=fun("armina", 4)(10,5); int (*)(int, int) 를 리턴하는 함수로 위 함수가 가능하다. int (*)(int,int) fun(char *, int); -> 원리상 맞으나 에러난다. --> 아래처럼 최초 * 괄호 안에 실체를 다시 써줘야 한다. int (* fun(char *, int))(int, int); signal 함수 유형을 주목하라. int const *pa; 번지가 상수다 int *const pa; 버퍼가 상수다. int const * const pa ; 둘다 상수다. int * const *pa[4]; int const **pa[4]; int **constpa[4];
유형별 예제 int *pa, a[4], *pa[4], a[2][3], (*pa)[3]; int a[4][5], (*pa[3])[5], (**pa)[5]; int (*pa[4][3])[5], (*(*pa)[3][5]; int p[4][3][7], (*pa)[3][7]; int *pa[2][3], *(*pa)[3], *(*pa[2])[3]; -> 모두 다 같은 개념. int *(**pa)[3], *(*pa[4][5])[3]; int *(*(*pa)[5][3]; int fun(int,int); int *fun(int, int); int **fun(int, int); int (*fun)(int, int); int *(*fun)(int, int); int (*fun[4])(int, int); int (**fun)(int, int); int (*fun[3][2])(int, int); int (*(*fun)[2])(int, int); int (*fun(int(*)[3], int**); int (*funt(int, int))[3][2]); int const *pa, *const pa; int fun (int, ...); (...) 괄호안에 있는 것은. 실체를 의미한다. 밖에 있는 것은 속성을 의미한다. int (*pa)[3] -> 2차원 배열 = 3개짜리 포인터의 배열. int *pa[4] 를 찍을 수 있는 포인터는 int **pa int (*pa[3])[5] 를 찍을 수 있는 포인터는 (**pa)[5] |
|
|
|
|
Calling Conventions (콜링 컨벤션)에 대한 정리 |
|
|
-- Calling Conventions (콜링 컨벤션)에 대한 정리 콜링 컨벤션(Calling Conventions)란? Microsoft의 Calling Conventions은 모두 5가지 종류의 Calling Conventions가 존재 한다. 각각의 차이점은 스택을 어떤 식으로 관리하고 또한 어떤 방법을로 인자를 전달하느냐의 차이가 있다. 1) __cdecl. 인자 전달순서는 RIGHT -> LEFT 순서 . 스택관리를 호출한곳에서 관리한다. . 함수의 이름에 _ 가 붙는다. ex) _Test . 기본 호출 규약이므로 /Gz (stdcall) 또는 /Gr (fastcall) 옵션이 켜졌을 때, 필요한 변수나 함수 이름 앞에 __cdecl을 놓으면 된다. /Gd 옵션은 강제로 __cdecl 규약으로 호출한다.
ex) _CRTIMP int __cdecl system(const char *); 2) __stdcall. 인자 전달순서는 RIGHT -> LEFT 순서 . 스택관리를 호출 받은곳에서 관리한다. . 함수의 이름에 _ 가 붙으며 뒤에 @가 붙은후 인자목록의 바이트수(10진수)가 붙는다. ex) int Test(int a, double b)는 _Test@12 . /Gz 옵션은 호출규약이 명시적으로 선언되지 않은 모든 함수를 __stdcall로 만든다. __stdcall 형식으로 선언된 함수는 __cdecl 형식으로 값을 리턴한다
ex) #define WINAPI __stdcall 3) __fastcall. 처음 2개의 DWORD 또는 더 작은 인자들이 ECX와 EDX 레지스터로 전달. 나머지 인자들은 오른쪽 --> 왼쪽으로 스택에 저장. . 스택관리를 호출 받은곳에서 관리한다. . 함수의 이름에 @가 붙은후 인자목록의 바이트수(10진수)가 붙는다. ex) int Test(int a, double b)는 Test@12 . /Gr 옵션은 선언된 함수가 충돌하지 않고 이름이 main이 아니라면, 모듈 내 각 함수를 fastcall로 컴파일한다.
ex) void __fastcall Test(void); 4) t hiscall가변인자를 사용하지 않는 C++ 멤버함수의 기본 호출 규약. 호출한곳에서 스택을 관리하고 스택 끝에 this 포인터를 넣으며, 컴파일시 컴파일러에 의해 가변인자(vararg) 함수는 __cdecl로 변경된다. thiscall은 키워드가 아니므로 thiscall 호출 규약은 명시적으로 사용될 수 없다. 모든 함수인자들은 스택 상에 놓여지며, 이 호출규약은 C++에만 적용되므로, C 이름 장식 스키마는 없다. 5) naked. 인자 전달순서는 RIGHT -> LEFT 순서 . 스택관리를 호출한곳에서 관리한다. . VxDs에서만 사용한다. < SAMPLE CODE > http://www.cs.cornell.edu/courses/cs412/2001sp/resources/microsoft-calling-conventions.html
// The strings passed to each function. static char * g_szStdCall = "__stdcall" ; static char * g_szCdeclCall = "__cdecl" ; static char * g_szFastCall = "__fastcall" ; static char * g_szNakedCall = "__naked" ;
// The extern "C" turns off all C++ name decoration. extern "C" { // The __cdecl function. void CDeclFunction ( char * szString , unsigned long ulLong , char chChar ) ; // The __stdcall function. void __stdcall StdCallFunction ( char * szString , unsigned long ulLong , char chChar ) ; // The __fastcall function. void __fastcall FastCallFunction ( char * szString , unsigned long ulLong , char chChar ) ; // The naked function. The declspec goes on the definition, not the // declaration. int NakedCallFunction ( char * szString , unsigned long ulLong , char chChar ) ; } void main ( void ) { 00401000 55 push ebp 00401001 8B EC mov ebp,esp 00401003 53 push ebx 00401004 56 push esi 00401005 57 push edi // Call each function to generate the code. CDeclFunction ( g_szCdeclCall , 1 , 'a' ) ; 00401008 6A 61 push 61h 0040100A 6A 01 push 1 0040100C A1 14 30 40 00 mov eax,[00403014] 00401011 50 push eax 00401012 E8 45 00 00 00 call 0040105C 00401017 83 C4 0C add esp,0Ch StdCallFunction ( g_szStdCall , 2 , 'b' ) ; 0040101C 6A 62 push 62h 0040101E 6A 02 push 2 00401020 8B 0D 10 30 40 00 mov ecx,dword ptr ds:[00403010h] 00401026 51 push ecx 00401027 E8 3D 00 00 00 call 00401069 FastCallFunction ( g_szFastCall , 3 , 'c' ) ; 0040102E 6A 63 push 63h 00401030 BA 03 00 00 00 mov edx,3 00401035 8B 0D 18 30 40 00 mov ecx,dword ptr ds:[00403018h] 0040103B E8 38 00 00 00 call 00401078 NakedCallFunction ( g_szNakedCall , 4 , 'd' ) ; 00401042 6A 64 push 64h 00401044 6A 04 push 4 00401046 8B 15 1C 30 40 00 mov edx,dword ptr ds:[0040301Ch] 0040104C 52 push edx 0040104D E8 40 00 00 00 call 00401092 00401052 83 C4 0C add esp,0Ch } 00401057 5F pop edi 00401058 5E pop esi 00401059 5B pop ebx 0040105A 5D pop ebp 0040105B C3 ret void CDeclFunction ( char * szString , unsigned long ulLong , char chChar ) { 0040105C 55 push ebp 0040105D 8B EC mov ebp,esp 0040105F 53 push ebx 00401060 56 push esi 00401061 57 push edi __asm NOP __asm NOP // NOPs stand for the function body here 00401062 90 nop 00401063 90 nop } 00401064 5F pop edi 00401065 5E pop esi 00401066 5B pop ebx 00401067 5D pop ebp 00401068 C3 ret void __stdcall StdCallFunction ( char * szString , unsigned long ulLong , char chChar ) { 00401069 55 push ebp 0040106A 8B EC mov ebp,esp 0040106C 53 push ebx 0040106D 56 push esi 0040106E 57 push edi __asm NOP __asm NOP 0040106F 90 nop 00401070 90 nop } 00401071 5F pop edi 00401072 5E pop esi 00401073 5B pop ebx 00401074 5D pop ebp 00401075 C2 0C 00 ret 0Ch void __fastcall FastCallFunction ( char * szString , unsigned long ulLong , char chChar ) { 00401078 55 push ebp 00401079 8B EC mov ebp,esp 0040107B 83 EC 08 sub esp,8 0040107E 53 push ebx 0040107F 56 push esi 00401080 57 push edi 00401081 89 55 F8 mov dword ptr [ebp-8],edx 00401084 89 4D FC mov dword ptr [ebp-4],ecx __asm NOP __asm NOP 00401087 90 nop 00401088 90 nop } 00401089 5F pop edi 0040108A 5E pop esi 0040108B 5B pop ebx 0040108C 8B E5 mov esp,ebp 0040108E 5D pop ebp 0040108F C2 04 00 ret 4 78: __declspec(naked) int NakedCallFunction ( char * szString , unsigned long ulLong , char chChar ) { __asm NOP __asm NOP 00401092 90 nop 00401093 90 nop // Naked functions must EXPLICITLY do a return. __asm RET 00401094 C3 ret < 참고자료 > 꼭 한번 보시길. http://www.unixwiz.net/techtips/win32-callconv.html
|
|
|
|
|
|
아래 주소의 글을 마음대로 내키는 대로 마구잡이로 번역 / 추가 / 삭제한 글입니다. (비난은 금물. 틀린부분 지적은 대환영!) http://www.unixwiz.net/techtips/win32-callconv.html
----------------------------------------------------------
* Calling Conventions
전통적으로 C 함수의 호출은 호출부쪽에서 인자들은 Stack에 push한고 함수를 호출후에 push한 인자들을 정리한다.
/* __cdecl 예제 */
push arg1 push arg2 push arg3 call function add sp,12 // pop, pop, pop 한것 같은 효과. (다쓴 인자 정리.) (* sp -> stack pointer )
문론 MS 컴파일러는 이 방법만 지원하는것은 아니다. 이와 다른 두가지 방법을 더 지원한다. 자세한 내용은 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_calling_conventions_topics.asp)를 참고. 또한 위에서 말한 __cdecl 컨벤션이 MS VC/.net 컴파일러는 default로 사용된다. (문론 바꿀수도 있다.)
이와 다르게 또다른 컨벤션인 __stdcall에 대하여 알아보자. __stdcall은 위에서 말한 __cdecl과 같이 호출부에서 stack에 인자를 push한다. 그러나 __cdecl과 다르게 호출되는 함수내에서 stack을 정리한다. 이것이 Win32 API 함수의 standard convention 이다. (이것이 WINAPI 이며 windows.h에 선언되어 있다.) 그리고 때때로 "Pascal" 컬링 컨벤션이라고도 불린다.
/* __stdcall 예제 */ push arg1 push arg2 push arg3 call function // 스택을 정리하는 부분이 없다. (호출되어지는 함수에 정리 부분이 있다.)
지금까지 말한것들이 별로 중요하지 않은 내용처럼 보이지만, 만약에 스택을 호출부와 호출당한곳에서 어떻게 다루어지는지에 대한 정리가 되어 있지 않다면 스택은 꺠어질것이고 북구할수 없을것이다.
"A mismatch in calling convention is catastrophic for a running program."
또한 우리는 __fastcall에 대하여도 기억하여야 한다. __fastcall은 레지스터를 이용한다. 그러나 일반적인 경우에 유용할것이라고 생각되지 않는다. 그러나 저장하고 가져오는데에 레지스터를 사용하면 속도면에서 유리하다.
. __stdcall이 스택을 정리할때에 작은(매우)코드가 실행된다, 이 작업은 오직 한곳에만 위치하게 된다. 이에 반하여 __cdecl은 모든 호출부에 스택을 정리하는 코드가 존재한다.
. printf()와 같은 가변인자(Variadic)함수들은 __stdcall로 바르게 사용될수 없다. 왜냐하면 오직 호출부만이 얼마나 많은 인자들이 전달되고 정리되어야 하는지 알수 있기 때문이다. 피호출부는 추정은 할수 있다 그러나 스택을 정리하는데에 함수의 로직을 검사하여야 하는데 컬링 컨벤션에서는 스스로 할수 없기 때문이다. 따라서 오직 __cdecl만이 가변인자 함수를 지원한다.
. 여기에는 사용하는데에 어떤것이 맞다 틀리다를 말하는것이 아니다. 일반적으로 스택정리는 인자 저장에 맞추어야 한다 그리고 이것은 오직 호출부와 피호출부가 무엇을 하는지 알경우에 할수 있다. 잘못된 컨벤션으로 함수를 호출하면 스택은 파괴되어 진다.
----------------------------------------------------------
* Linker symbol name decorations
위에서 언급한 대로 잘못된 컨벤션으로 함수 호출은 재난을 초래할수 있다. 그래서 MS는 이러한것을 피할수 있는 메커니즘을 가지고 있다. 이것은 잘 작동함에도 불구 하고 어떤이유로 사용하는 지를 모른다면 돌아버리게 할수도 있다.
: __cdecl (cl /Gd ...) 모든 함수의 이름은 _(underscore) 접두어가 붙는다 그리고 인자의 갯수는 신경쓰지 않는다 왜냐하면 호출부가 스택을 설정하고 정리하기 때문이다. 이것은 많은 인자가 전달될때 호출부와 피호출부를 혼란스럽게 할수 있다. 그러나 적어도 스택을 정확하게 유지 한다.
: __stdcall (cl /Gz ...) 함수의 이름에 _(underscore) 접두어가 붙는다 그리고 전달되는 인자에 대한 바이트 수가 추가로 붙는다. 이것은 잘못된 타입이나 잘못된 인자수로 호출할수 없다.
: __fastcall (cl /Gr ...) 함수의 이름 처음에 @ 그리고 접미사에 @와 인자의 바이트 수가 붙는다. __stdcall과 비슷하다.
예제) void __cdecl foo(void); _foo void __cdecl foo(int a); _foo void __cdecl foo(int a, int b); _foo void __stdcall foo(void); _foo@0 void __stdcall foo(int a); _foo@4 void __stdcall foo(int a, int b); _foo@8 void __fastcall foo(void); @foo@0 void __fastcall foo(int a); @foo@4 void __fastcall foo(int a, int b); @foo@8
추가된 이름은 절대로 C프로그램에서는 보이지 않는다는 것을 기억하자. 링크타임시 사용되어지는 이름들이다.
C> type testfile.c extern void __stdcall func1(int a); extern void __stdcall func2(int a, int b, double d); extern void __cdecl func3(int b); extern void __cdecl func4(int a, int b, double d);
int __cdecl main(int argc, char **argv) { func1(1);
func2(2, 3, 4.);
func3(5);
func4(6, 7, 8.0);
return 0; }
C> cl /nologo testfile.c testfile.c testfile.obj : error LNK2001: unresolved external symbol _func1@4 ... __stdcall testfile.obj : error LNK2001: unresolved external symbol _func2@16 ... __stdcall testfile.obj : error LNK2001: unresolved external symbol _func3 ... __cdecl testfile.obj : error LNK2001: unresolved external symbol _func4 ... __cdecl testfile.exe : fatal error LNK1120: 4 unresolved externals
----------------------------------------------------------
* But doesn't the compiler catch this?
그렇다. C++는 항상 지원한다. 그리고 ANSI C "function prototype"을 지원한다. 선언된 함수의 인자를 기술하는것을 가능하게 한다. 함수가 호출될때 이것은 선언된것과 비교하며 경고한다.
/* somefile.c */ extern int foo(int a); // prototype ... n = foo(1, 2, 3); // mismatch! bad parameter count!
컴파일러는 foo()함수가 1개의 인자를 갖는것을 기대한다. MS 콜링컨벤션은 아무것도 추가 하지 않는다. 그러나 링커가 링크를 할때에 이러한 일이 일어난다. 아래 두개의 파일을 생각해 보자. 하나는 함수를 사용하고 하나는 정의를 사용한다.
------------------------
/* in file1.c */ extern int __cdecl foo(int); ... n = foo(1);
------------------------
/* in file2.c */ int __stdcall foo(int a) { .... } ------------------------
컴파일러는 두개의 소스파일을 같이 보지 않는다. 여기에서 컴파일러는 잘못되어진 콜링컨벤션이 사용됨을 찾지 못한다. 링크되었을때 코드의 결과로 스택이 파괴되게 된다.
프로그래머가 이와같은 바보같은 잘못을 저지른것을 비난하기 전에 default 콜링컨벤션이 __cdecl이라는것을 생각하자. 그래서 file1.c에서 foo()에 대한 선언을 빼먹었더라도 이것은 __cdecl로 간주된다. 작은 프로젝트에서는 이 예제는 괜찮다. 그러나 시스템이 커질경우에 이러한 시추에이션은 더욱자주 일어난다. 이것은 종종 third-party(써드파티)라이브러리(많은 함수들을 익스포트 한다)에서 일어난다. 그리고 그것들은 컴파일러의 어떤 설정을 라이브러리를 만들때에 사용했는지를 항상 말하지 않는다.
Calling-convention symbol decorations exist only to maintain stack discipline
----------------------------------------------------------
* When does it matter?
대부분의 경우에, 어떠한 콜링컨벤션을 어떤 특별한 함수 혹은 전체적으로 default로 사용했는지는 별로 다를바가 없다. 그러나 __cdecl을 default로 사용하지 않을 경우에 약간의 주의점이 있다.
. main()은 항상 __cdecl이여야 한다.
. WinmMain()은 항상 __stdcall이어야 한다. 이것은 Windows.h에 선언되어 있다.
. 가변인자(printf 같은)함수들은 다르게 선언하더라도 __cdecl로 처리된다. (콜링컨벤션은 무시된다.) 컴파일러는 잘못사용 하더라도 경고를 보여주지 않는다. int __stdcall myprintf(const char *fmt, ...); // it's really __cdecl
. 어떤 라이브러리 함수는 다른 함수의 주소를 인자로 갖는다, 그리고 이것은 정확해야 한다. 예로 qsort()는 마지막 인자로 비교함수의 주소를 갖는다. 이것은 항상 __cdecl 이어야 한다.
extern void __cdecl qsort( void *base, size_t num, size_t width, int (__cdecl *compare )(const void *, const void *) ); .... int __stdcall mycompare(const void *p1, const void *p2) { // compare here } .... qsort(base, n, width, mycompare); // ERROR - mismatch
----------------------------------------------------------
* Calling functions exported from DLLs
third party DLL을 사용하여(특히 다른언어로 작성된) 시스템을 빌드시 문제가 생길때 이것은 대부분 간단한 콜링컨벤션의 문제이다.(대부분 Makefile level) 만일 임포트 라이브러리와 헤더파일을 제외하고 오직 .DLL만 제공 받았을때에 콜링컨벤션에 관련하여 컴파일러는 어떠한 도움을 주지 못한다.
typedef BOOL (__stdcall *INITFUNCTION)(BOOL); typedef int (__stdcall *DRAWFUNCTION)(int x, int y, const char *label);
HINSTANCE hInst = LoadLibrary("barcode.dll");
INITFUNCTION pfInit = (INITFUNCTION)GetProcAddress(hInst, "Init"); DRAWFUNCTION pfDraw = (DRAWFUNCTION)GetProcAddress(hInst, "Draw");
(*pfInit)(TRUE);
(*pfDraw)(1, 1, "12345"); (*pfDraw)(1, 2, "67890");
typedef을 콜링컨벤션에 사용함에 있어서 주의깊게 기억하여야 한다. 코드를 사용하는데에 컨벤션을 반드시 맞주어야 하며 잘못되었을때 컴파일러는 검출해 내지 못하고 실행시 문제가 생긴다. 여기에서는 라이브러리제공자로 부터 제공받은 문서이외에 검사할수 있는 방법이 없다.
----------------------------------------------------------
* Building bigger systems
언급했다 시피 작은 프로그램은 그렇게 많이 주의할 필요는 없다. 그러나 시스템이 커지거나 third-party 라이브러리를 사용할때 콜링컨벤션에 대하여 주의할 필요가 생긴다. 만일 non-Windows 플렛폼과 다른 콜링컨벤션으로 포팅시에 문제가 더 복잡해 질수 있다.
|
|
|
|
[Debug] 디버깅시 Symbol Load하는 방법 |
|
|
VS tools을 사용하여 Debug시 작성한 Dll들 및 기타 system dll에 대한 Symbols를 로드 하는 방법은 아래와 같다.
디버깅중에서
Debug --> Windows --> Modules 템에서 해당 Dll에서 마우스 오른쪽 버튼을 누르고 심볼을 로드 하면 Symbol status가 loaded 상태가 된다.
|
|
|
|
|
|
오늘 제가 속한 팀의 팀장님이 블로그를 열심히 꾸미는 저에게 농담식으로 "우리 솔루션 소스 올리는거 아냐?" 라는 말을 던지더군요.
그 말을 쉽게 받아 넘길 수 있었지만, 회사에 몸담고 있는 저로써는 살짝 불쾌한 느낌을 받았습니다.
개발하며 똥오줌도 못 가릴 정도가 아닌데... 그런 말을 들어야 하는게 우습기도 하고....
여튼 프로그래밍 개발하며 참 거시기 합니다.
회사 일과 관련이 없이, 제 스스로 생산한 코드에 대해서는 GPL 라이센스를 따를 생각 입니다.
고운하루 되세요.
|
|
|
|
|
|
"창과 방패"라고 하면 공격자와 방어자간에 사활을 건 혈전을 생각 하게 된다. 또는 해킹에서 해킹하려는 사람들과 막으려는 사람, 바이러스 유포자와 백신 개발자!! 등등 여러가지 이미지들이 떠오른다.
얼마전 심심한 나머지 회사에서 사용하고 있는 보안 솔루션에 헛점은 없을까?하고 여러가지 실험을 해보았다.
GS 인증 획득을한 제품이라고 하고, 몇몇 대기업에서도 사용하고 있고, SW 부분에서 상을 받은 보안 솔루션이라고 하는데...
크리티컬한 문제들이 많이 많이 발견 되었다.
------ 기본적으로 보안 프로그램들의 단점은 멀티 부팅에 약하다는 것이다. -------
기본적으로 TCP/IP를 통해 보안솔루션 서버와 클라이언트로 구성되어 있기 때문에 클라이언트에서 수집된 정보들은 바로 서버로 전송되게 된다.
만약 통신이 연결되지 않은 상태라면 PC 어딘가에 로그들을 저장할터이고.......... 그 로그 파일들을 지우면 럭키!!! 아무런 기록도 남지 않는다. 여기서 통신이란 서버와(보안솔루션)내 PC상이 통신연결을 말한다.
자 서버와 TCP/IP 연결 상태를 강제로 닫아 버린 socket close and 해당 PID를 죽인다.
so log로 남을 만한 정보들을 찾아보았다.
- 개인정보 찾음 럭키!! - 암호회 되지 않은 상태로 클라이언트 PC에 저장되어 있음
- 다른 사용자들의 비밀 번호까지 획득 럭키 -0- ( 왜 다른 사람들의 아이디 패스워드까지 내 PC에 저장이 되는가????????? ) - 클라이언트에서 프린트한 내용물이 jpg로 저장 된것을 확인 럭키 -0- 야근 식대 청구서
- Web Log 및 이동장치로 복사한 파일 log 등등등등등....... 가지런하게 정리가 되어져 있었다.
모두 delete.........
참 좋은 제품을 만들기란 어려운 것 같다. 나부터 좋은 프로그래밍 습관을 길러야 할듯...............
아 해당 솔루션의 이름은 문제가 되어서 알려 드릴 수 없습니다.
|
|
|
|
[C++ STL] size()의 결과를 0과 비교할 생각이라면.... 차라리 empty를 호출하자 |
|
|
Effective STL을 찬찬히 다시 읽고 있는 중입니다. 저도 나이를 하나씩 먹어감에 따라서 기억이 가물 가물 해지는군요. 가까운곳에 글을 남겨, 오래 기억 해야겠어요. 결국 밥줄이 이것 밖에 없는데...ㅜㅜ;
if( c.size() == 0 ) dosomething();
보다는.....
if( c.empty() == 0 ) dosomething();
이라 쓰는게 좋다 합니다. 이유는 모든 표준 컨테이너에 대해 상수 시간에 실행 된다고 하는군요. 몇몇에서는 list 클래스에 size가 선형 시간에 수행 되는 경우가 많다고 합니다.
STL도 무조건 좋다고 사용하는 것 보다. 하나 하나 성능과 효율을 측정하며 사용하는 건 프로그래머의 몫이 아닐까 합니다. 그럼 오늘도 즐프~
|
|
|
|
|
|
« 2024/11 »
일 |
월 |
화 |
수 |
목 |
금 |
토 |
|
|
|
|
|
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 |
|
Total :
Today :
Yesterday : |
|
|
|
|
|
|