정적으로 링크 된 라이브러리
런타임에로드 할 수 있지만, 당신은 당신의 실행 파일을 링크 할 때 이진 파일에 통합해야합니다. 즉, 정적으로 링크 된 라이브러리의 코드에 대한 모든 진입 점은 잘 정의되어 있으며 해당 주소는 실행 가능 코드의 시작에 비례하여 변경되지 않습니다 (따라서 "정적").
동적으로로드 된 라이브러리에서는 코드가있는 위치를 알 수 없으므로 런타임에 라이브러리가로드 될 때로드 된 코드를 "바인딩"하기 위해 일정량의 성능 오버 헤드가 필요합니다. 본질적으로, 링크는 런타임에 지연되므로 "후기 바인딩"이라고도합니다.
구현하기로 선택한 것은 사용 요구 사항에 따라 다릅니다. 사용자가 종속성에 대해 걱정할 필요없이 자신의 응용 프로그램 폴더로 간단히 끌어다 놓을 수있는 자체 포함 실행 파일을 원한다면 라이브러리를 정적으로 링크하는 것이 좋습니다.
그러나 규모가 큰 프로젝트의 경우 많은 기능을 제공하는 앱에서 모든 기능을 한꺼번에로드하는 것이 금지되거나 불필요 할 수 있습니다. 동적으로로드 할 수있는 라이브러리 세트를 제공하면 메모리를 절약하고 시작 시간을 단축 할 수 있습니다. 그런 다음 사용자가 기능에 액세스 할 때 관련 코드가로드되고 잠시 동안 사용되지 않은 기능이 언로드 될 수 있습니다.
또한 코드를 변경하면 전체 실행 파일을 다시 컴파일하고 다시 링크하지 않고 하나 또는 두 개의 라이브러리를 재배포 할 수 있습니다. 그리고 나는 플러그인의 전망에 대해서 언급 할 필요가 있니?
위의 두 템플릿의 차이점은 미묘합니다. 둘 다 GNU99 표준에 따라 C를 컴파일합니다. 그러나 C/C++ Library 템플릿은 C++/C++/GNU ++ 0x "standard"에 따라 xcode를 설정하여 C++을 컴파일합니다. 2011 년 C++/GNU ++ 0x는 공식적으로 C++/GNU ++ 11로 게시되었습니다. 두 템플릿 모두 기본적으로 libC++를 사용하지만 STL C++ 템플릿을 사용하면 대신 이전 libstdC++에 대한 링크를 선택할 수 있습니다. 왜 이럴거야? 코드가 libC++에 링크되어 있지만 libstdC++을 참조하는 다른 라이브러리와 링크되어 있고 충돌하는 심볼을 통해 실행하는 경우 대신 libstdC++에 링크하여이 문제를 해결할 수 있습니다. STL C++ Library 템플릿을 사용하면 컴파일러가 GNU ++ 11 확장을 제외한 C++ 11 표준을 따르도록 요청하거나 C++/GNU ++ 98로 돌아갈 수 있습니다 (레거시 코드를 컴파일해야하는 경우 예).
libC++ 대 libstdC++ 어쩌면? – Praetorian