함수자체를 input 으로 받아서 어떤 일을 수행하는 프로그램이
shared library 로 배포가 되었다면
함수포인터를 쓰지않을 수가 없겠죠
자신을 가져다쓰는 프로그램의 Symbol Table이 없을것이고
애당초 Symbol Table 은 반드시 있다고 신뢰할수 없는것이므로...
Highlevel programming 에서도
function 의 이름에 대한 매핑이 runtime 에 결정될 필요가
있다거나 뭐 여러가지 상황이 있을거같은데요
RPC 를 구현할때도 필수적일거같고
함수포인터 없이, 그냥 함수 이름을 직접 써서 호출하는것은 정적 바인딩입니다.
해당 함수의 위치가 컴파일 당시에 파악이 가능하므로
컴파일러가 해당 위치를 바이너리에 포함시키고, 해당 파일이 실행될때는 항상 같은 부분을 가리키게 되는거죠.
하지만, 어떤 함수를 호출할지 컴파일 타임이 아니라, 런타임에 동적으로 결정해야 할 경우들이 생깁니다.
대표적으로, 플러그인 같은것들이죠.
플러그인 모듈을 설치하더라도, 플러그인을 불러드리는 프로그램을 재컴파일 할 필요가없습니다.
왜냐면, 함수 포인터를 이용하여, 동적바인딩을 하기 때문입니다.
즉, 실행시에 해당 플러그인 모듈을 열어서, 거기안에 들어있는 함수를 동적으로 로드한후,
함수포인터를 이용하여 해당 함수를 호출하는 것입니다.
새로운 함수/모듈을 추가할때마다,
매번 프로그램을 재컴파일 해야한다면, 프로그램의 유용성/확장성이 많이 떨어질것입니다.
사실, C++의 virtual function도 함수 포인터를 이용하여 구현되어있습니다.
컴파일타임에는 어떤 객체가 불러들일지 알수가 없습니다.
따라서, 어느 virtual function을 바인딩 해야하는지도 알수가 없죠.
virtual function은 동적으로 객체가 할당될때마다, 해당 class의 virtual table에 stack의 구조로
자신의 멤버함수를 쌓아가는 구조로 동작합니다.
암튼, 함수포인터는
함수를
정적바인딩(컴파일타임)뿐만이 아니라,
동적바인딩(런타임)도 가능하게 하기위해 필요합니다.
함수포인터 없이, 그냥 함수 이름을 직접 써서 호출하는것은 정적 바인딩입니다.
해당 함수의 위치가 컴파일 당시에 파악이 가능하므로
컴파일러가 해당 위치를 바이너리에 포함시키고, 해당 파일이 실행될때는 항상 같은 부분을 가리키게 되는거죠.
하지만, 어떤 함수를 호출할지 컴파일 타임이 아니라, 런타임에 동적으로 결정해야 할 경우들이 생깁니다.
대표적으로, 플러그인 같은것들이죠.
플러그인 모듈을 설치하더라도, 플러그인을 불러드리는 프로그램을 재컴파일 할 필요가없습니다.
왜냐면, 함수 포인터를 이용하여, 동적바인딩을 하기 때문입니다.
즉, 실행시에 해당 플러그인 모듈을 열어서, 거기안에 들어있는 함수를 동적으로 로드한후,
함수포인터를 이용하여 해당 함수를 호출하는 것입니다.
새로운 함수/모듈을 추가할때마다,
매번 프로그램을 재컴파일 해야한다면, 프로그램의 유용성/확장성이 많이 떨어질것입니다.
사실, C++의 virtual function도 함수 포인터를 이용하여 구현되어있습니다.
컴파일타임에는 어떤 객체가 불러들일지 알수가 없습니다.
따라서, 어느 virtual function을 바인딩 해야하는지도 알수가 없죠.
virtual function은 동적으로 객체가 할당될때마다, 해당 class의 virtual table에 stack의 구조로
자신의 멤버함수를 쌓아가는 구조로 동작합니다.
암튼, 함수포인터는
함수를
정적바인딩(컴파일타임)뿐만이 아니라,
동적바인딩(런타임)도 가능하게 하기위해 필요합니다.
짧은 지식으로 답변을 드리자면.. 함수 포인터라는
짧은 지식으로 답변을 드리자면.. 함수 포인터라는 개념이 굳이 왜 존재하는가? 하고 물을 필요는 없는 듯 합니다. 함수 또한 변수와 마찬가지로 메모리 상의 특정 지점이라고 할 수 있기 때문에, 자연스럽게 포인터로 표현할 수 있는 것이죠.
그리고 함수 포인터의 실제 활용도는 다양합니다. 기본적으로 확장성을 위해 사용하죠.
strategy 패턴 등이 적절한 예입니다.
굳이 사용하진 않습니다.
다형성을 구현 할수도 있습니다. 적절한 예가 안떠오르네요..
굳이 사용하지 않으셔도 됩니다. 언젠가는 필요하게 될겁니다.
언제나 시작
가장 기본적인 용도는 callback 이지요.
가장 기본적인 용도는 callback 이지요. tpe4님이 말씀하신 strategy 패턴의 기초적인 형태라고 할 수도 있습니다.
sort 함수를 생각해보세요.
음
함수자체를 input 으로 받아서 어떤 일을 수행하는 프로그램이
shared library 로 배포가 되었다면
함수포인터를 쓰지않을 수가 없겠죠
자신을 가져다쓰는 프로그램의 Symbol Table이 없을것이고
애당초 Symbol Table 은 반드시 있다고 신뢰할수 없는것이므로...
Highlevel programming 에서도
function 의 이름에 대한 매핑이 runtime 에 결정될 필요가
있다거나 뭐 여러가지 상황이 있을거같은데요
RPC 를 구현할때도 필수적일거같고
자기실력이 좋다고 느껴지는건 공부를 안하고 있다는 신호.
함수포인터는 함수의 동적바인딩과 정적바인딩
함수포인터는
함수의 동적바인딩과 정적바인딩 때문입니다.
함수포인터 없이, 그냥 함수 이름을 직접 써서 호출하는것은 정적 바인딩입니다.
해당 함수의 위치가 컴파일 당시에 파악이 가능하므로
컴파일러가 해당 위치를 바이너리에 포함시키고, 해당 파일이 실행될때는 항상 같은 부분을 가리키게 되는거죠.
하지만, 어떤 함수를 호출할지 컴파일 타임이 아니라, 런타임에 동적으로 결정해야 할 경우들이 생깁니다.
대표적으로, 플러그인 같은것들이죠.
플러그인 모듈을 설치하더라도, 플러그인을 불러드리는 프로그램을 재컴파일 할 필요가없습니다.
왜냐면, 함수 포인터를 이용하여, 동적바인딩을 하기 때문입니다.
즉, 실행시에 해당 플러그인 모듈을 열어서, 거기안에 들어있는 함수를 동적으로 로드한후,
함수포인터를 이용하여 해당 함수를 호출하는 것입니다.
새로운 함수/모듈을 추가할때마다,
매번 프로그램을 재컴파일 해야한다면, 프로그램의 유용성/확장성이 많이 떨어질것입니다.
사실, C++의 virtual function도 함수 포인터를 이용하여 구현되어있습니다.
컴파일타임에는 어떤 객체가 불러들일지 알수가 없습니다.
따라서, 어느 virtual function을 바인딩 해야하는지도 알수가 없죠.
virtual function은 동적으로 객체가 할당될때마다, 해당 class의 virtual table에 stack의 구조로
자신의 멤버함수를 쌓아가는 구조로 동작합니다.
암튼, 함수포인터는
함수를
정적바인딩(컴파일타임)뿐만이 아니라,
동적바인딩(런타임)도 가능하게 하기위해 필요합니다.
함수포인터는 함수의 동적바인딩과 정적바인딩
함수포인터는
함수의 동적바인딩과 정적바인딩 때문입니다.
함수포인터 없이, 그냥 함수 이름을 직접 써서 호출하는것은 정적 바인딩입니다.
해당 함수의 위치가 컴파일 당시에 파악이 가능하므로
컴파일러가 해당 위치를 바이너리에 포함시키고, 해당 파일이 실행될때는 항상 같은 부분을 가리키게 되는거죠.
하지만, 어떤 함수를 호출할지 컴파일 타임이 아니라, 런타임에 동적으로 결정해야 할 경우들이 생깁니다.
대표적으로, 플러그인 같은것들이죠.
플러그인 모듈을 설치하더라도, 플러그인을 불러드리는 프로그램을 재컴파일 할 필요가없습니다.
왜냐면, 함수 포인터를 이용하여, 동적바인딩을 하기 때문입니다.
즉, 실행시에 해당 플러그인 모듈을 열어서, 거기안에 들어있는 함수를 동적으로 로드한후,
함수포인터를 이용하여 해당 함수를 호출하는 것입니다.
새로운 함수/모듈을 추가할때마다,
매번 프로그램을 재컴파일 해야한다면, 프로그램의 유용성/확장성이 많이 떨어질것입니다.
사실, C++의 virtual function도 함수 포인터를 이용하여 구현되어있습니다.
컴파일타임에는 어떤 객체가 불러들일지 알수가 없습니다.
따라서, 어느 virtual function을 바인딩 해야하는지도 알수가 없죠.
virtual function은 동적으로 객체가 할당될때마다, 해당 class의 virtual table에 stack의 구조로
자신의 멤버함수를 쌓아가는 구조로 동작합니다.
암튼, 함수포인터는
함수를
정적바인딩(컴파일타임)뿐만이 아니라,
동적바인딩(런타임)도 가능하게 하기위해 필요합니다.
댓글 달기