AI 작업의 특징
외부 코드에 많의 의존한다
시간의 흐름에 따라 연속적으로 변화한다
그러므로 이터레이션 속도 = 생산성!
이터레이션 = 코드 수정 + 빌드 + 로딩 + 테스트
일반적인 해결책들
컴파일 시간: pch, 의존성 감소
링크 시간: DLL 빌드
로딩 시간: 로딩 최적화
실행 중 DLL 교체
Dynamic Linked Library: 실행 시점에 코드를 메모리에 로드
Implicit link(묵시적 링크)
보통 접하는 dll 빌드. __declspec(dllimport)
라이브러리 프로젝트 빌드하면 .lib와 .dll 생성됨
사용하는 쪽에선 .lib을 static 링크함
.lib가 초기화될 때 .dll을 찾아서 자동으로 로드한다(언로드 또는 교체할 수 없다)
Explicit Link(명시적 링크)
HMODULE WINAPI LoadLibrary(LPCTSTR lpFileName);
typedef int (FAR WINAPI *FARPROC)();
FARPROC WINAPI GetProcAddress(HMODULE hModule, LPCSTR lpProcName);
진입점 문제
extern "C"로 묶어주지 않으면 이름이 바뀐다
노출하는 함수가 많아지면 피곤하다. (일일히 GetProcAddress 해야하므로)
함수 시그니처가 어긋남을 컴파일러가 감지하지 못한다
진입점 문제 해결책
인터페이스 클래스를 라이브러리와 호출부가 공통 참조, 이것을 상속, 구현한 객체를 라이브러리 함수가 리턴
GetProcAddress로 단 하나의 함수만 불러오면 된다
Com의 QueryInterface와도 비슷하다
외부 심볼 참조 문제
Explicit Link DLL은 exe의 심볼을 볼 수 없다.
프로그램의 다른 부분이 Implicit Link DLL로 되어 있다면 추가 비용 없이 그대로 사용 가능하다.
DLL 안전하게 해제
DLL을 해제하기 전에 내부로의 연결을 모두 끊어야 한다. (아니면 Crash 발생)
=> DLL을 해제하지 않고 코드 변경할 때마다 계속 중복 로드하게 함
DLL 덮어쓰기
로드된 DLL은 덮어쓰기 불가능
=> 로드 전에 DLL 파일 이름을 랜덤하게 바꿔서 해결
=> 쌓이는 DLL 파일은 검색해서 삭제
스크립트 자체 제작
은 내용정리 생략.. 출저내용 확인
출처: 이승재 / 넥슨코리아
http://ndcreplay.nexon.com/NDC2013/sessions/NDC2013_0029.html