Bjarne Stroustrup이 처음 C++를 개발하고, 만든 컴파일러는 C++ 코드를 C로 변환한 후, 이를 다시 C컴파일를 이용하여 기계어로 번역하는 방식이었다. 그리고 이러한 방식은 현재의 컴파일러에서도 변하지 않고 사용되고 있다.
C++의 method는 C의 function으로 다음과 같이 변환된다.
CClass::Method(TYPE parma1, TYPE parma2); // C++ method
Method(CClass *thisptr, TYPE param1, TYPE param2); // converted C function
February 18, 2008
Bjarne Stroustrup
Bjarne Stroustrup은 덴마크 사람으로 C++를 만든 사람이다.
발음은 찾아본 바로는 대략 "뷔야(른)ㅡㄴ 스트루스트럽 (r 발음은 빠른 발음 때문에 거의 묵음화)" 정도 인듯 하다 (발음 듣기).
가장 많이 사용하는 C++를 누가 만들었는지 정도는 알아두자.
발음은 찾아본 바로는 대략 "뷔야(른)ㅡㄴ 스트루스트럽 (r 발음은 빠른 발음 때문에 거의 묵음화)" 정도 인듯 하다 (발음 듣기).
가장 많이 사용하는 C++를 누가 만들었는지 정도는 알아두자.
Name Mangling
function, structure, class, variable의 이름이 같은 경우 생길 수 있는 문제점을 방지하기 위해서 이름과 추가적인 정보를 encoding하여 내부적으로 사용되는 이름을 생성하는 방법이다. Name Decoration이라고도 불리며, C에서는 이를 사용하지 않지만, C++에서는 이를 사용한다. 예를 들어, C++에서 polymorphism이 적용된 함수의 경우, 이름은 같지만 파라미터가 다르낟. C에서는 이러한 함수의 식별이 불가능하지만, C++에서는 Name Mangling을 이용하여, 서로다른 함수로 십결이 가능하다.
Name Mangling에는 표준이 없고, 컴파일러 나름대의 방법을 사용한다. 그러므로, 컴파일러가 동일하다면, Name Mangling을 통해서 encoding된 이름이 동일하지만, 그렇지 않을경우 이름이 동일하다는 보장을 할 수 없다 (DLL에서 extern "C"를 사용하는 이유).
Name Mangling에는 표준이 없고, 컴파일러 나름대의 방법을 사용한다. 그러므로, 컴파일러가 동일하다면, Name Mangling을 통해서 encoding된 이름이 동일하지만, 그렇지 않을경우 이름이 동일하다는 보장을 할 수 없다 (DLL에서 extern "C"를 사용하는 이유).
January 22, 2008
Flickr Pro Account
사진을 많이 찍으면 찍을 수록 걱정되는 것이 바로, 사진의 보관이다. 하드 디스크에 보관하고, 외장 하드디스크에 백업도 하지만, 불안한건 사실이다. 그래서, 웹상에 보관하는 방법을 찾던 차에 Flick Pro를 발견하였다. 물론, 100%안전한 방법은 아니지만, Yahoo!에서 하는 서비스인 만큼 상당히 믿을만 하다는게 나의 생각. 거기다가 $24.95에 무제한 이용이 가능하다 (한달 upload는 2G로 제한). 이 정도면 앞으로 꾸준히 이용할 만한 서비스 일 것으로 생각된다.
결국 사고 말았다...^^;;
결국 사고 말았다...^^;;
__stdcall & __cdecl
WINDEF.H
이렇게 calling convetion을 둘로 나눈 이유는 함수 호출 후, stack pointer (sp)를 누가 원래데로 돌려놓을지 (정리할지)를 분간하기 위함이다. 결론 부터 애기하자면, __stdcall을 이요하면, callee측에서 sp를 정리하고, __cdecl을 이용하면, caller측에서 sp를 정리한다.
예를 들어보자.
반면 __stdcall의 경우는 대락 다음과 같이 구성된다.
Assembly code를 보면 알 수 있듯이, __cdecl은 함수가 return된 이후에, caller가 직접 sp를 정리하고, __stdcall은 callee측에서 정리를 해주기 때문에, caller 쪽에서는 함수가 return된 이후에 sp 정리 작업을 하지 않는다.
sp의 정리를 어느 쪽에서 하든, 차이가 없어보이지만 두가지 정도 차이가 생길 수 있다.
먼저, 속도와 관련된 문제이다. 8086 계열의 assembly 명령어 중,이라는 명령어가 있다. 이 명령어는 함수가 종료된 후, sp를 얼마만큼 add할지를 하나의 명령어로 만든것이다. __stdcall에서는 바로 이 명령어를 이용하여, 의 operation time만큼을 절약할 수 있으며, 그만큼 프로그램 사이즈도 줄일 수 있다 (물론, 한 단위로 보면 그 효과가 미비하지만, 그 수가 많아질 경우 어느정도 차이가 생길 수 있다).
다음으로, 가변 arguments의 지원 여부이다. __cdecl을 이용하면, caller측에서 sp를 정리하기 때문에, 가변 arguments를 지원할 수 있다.
사실, 몇가지 차이점이 더 있는 듯 하지만, 지금까지 파악된 부분은 이 두가지이다.
CALLBACK = WINAPI = PASCAL = __stdcall위에서 알 수 있듯이, MS Windows의 calling convetion은 __stdcall과 __cdecl로 나뉜다.
WINAPIV = __cdecl
이렇게 calling convetion을 둘로 나눈 이유는 함수 호출 후, stack pointer (sp)를 누가 원래데로 돌려놓을지 (정리할지)를 분간하기 위함이다. 결론 부터 애기하자면, __stdcall을 이요하면, callee측에서 sp를 정리하고, __cdecl을 이용하면, caller측에서 sp를 정리한다.
예를 들어보자.
SimpleFunction(TYPE arg1, TYPE arg2, TYPE arg3) { … }__cdecl의 경우, assembly code는 대략 다음과 같이 구성된다.
SimpleFunction(…);
push arg3
push arg2
push arg1
call SimpleFunction
Add sp, 12
반면 __stdcall의 경우는 대락 다음과 같이 구성된다.
push arg3
push arg2
push arg1
call SimpleFunction
Assembly code를 보면 알 수 있듯이, __cdecl은 함수가 return된 이후에, caller가 직접 sp를 정리하고, __stdcall은 callee측에서 정리를 해주기 때문에, caller 쪽에서는 함수가 return된 이후에 sp 정리 작업을 하지 않는다.
sp의 정리를 어느 쪽에서 하든, 차이가 없어보이지만 두가지 정도 차이가 생길 수 있다.
먼저, 속도와 관련된 문제이다. 8086 계열의 assembly 명령어 중,
다음으로, 가변 arguments의 지원 여부이다. __cdecl을 이용하면, caller측에서 sp를 정리하기 때문에, 가변 arguments를 지원할 수 있다.
사실, 몇가지 차이점이 더 있는 듯 하지만, 지금까지 파악된 부분은 이 두가지이다.
Subscribe to:
Posts (Atom)