기타 (21) 썸네일형 리스트형 라이브러리 추가 라이브러리 추가 include - c/c++의 추가포함디렉터리에 include폴더를 추가 lib폴더 - 링커의 일반의 추가라이브러리 디렉터리 에 lib폴더 추가 lib파일 - 링커의 입력의 추가종속성에 ABC.lib형식으로 추가 dll파일 - dll파일은 동적으로 사용하므로 이 프로그램 소스가 있는 폴더에 직접 넣어주어서 사용 lib파일 - 정적으로 라이브러리 선언 cin.get() cin.get() /////////////////////////사용자는 Hello World입력//////////////////// char input[32]; cin >> input; input에는 "Hello"만 들어간다. 즉 "Hello" 다음의 white space를 감지 하지만 다음과 같이 하면, char input[32]; cin.get(input,32); 이렇게 하면 input에는 "Hello world"가 모두 들어간다. Static static - 정적선언 class GameLoop { public: static GameLoop * getInstance() { static GameLoop instance; return &instance; } void run(); private: GameLoop() { } }; - 정적 선언으로 컴파일시 스택에 메모리가 잡히게 된다. - 보통 멤버 변수는 그 함수나 클래스가 실행시 메모리에 잡히게 되는데 - static로 선언하면 컴파일시 스택에 메모리가 잡혀서 - 클래스가 종료 되어도 메모리에 남아 있게 되어 그 클래스를 후에 다시 호출해도 - static로 선언된 변수는 다시 생성되는 것이 아니고 처음에 생성된 값으로 연산 - 전역변수로 선언해도 같은 결과인데 전역 변수 선언은 객체지향의 - 캡슐.. ifndef. define // GameLoop.h #ifndef GAME_LOOP_H #define GAME_LOOP_H ~~ #endif - GameLoop헤더파일이 중복 컴파일 되는 것을 막아준다. - #include "GameLoop.h" 시 헤더 파일 내용이 붙어서 사용되는데 GameLoop.h를 다른 데서도 include 하면 중복으로 include하게 되므로 에러가 발생하게 되므로 그것을 막아주는 역할을 한다. 유니코드 사용 2005 이전은 Use Multi-Byte Character Set 인데, 2005 에서는 Use Unicode Character Set 이라 발생하는 문제. 해결방법은, 프로젝트 → 속성 → 구성속성 → 프로젝트 기본값(문자 집합)에서 해당 설정값 을 유니코드 문자집합에서 멀티바이트 문자집합사용으로 체크 Singleton pattern 1. An issue ● 오직 하나의 인스턴스를 구현하여 유지할 수 있는가? 2. Why ● 오직 하나의 인스턴스만을 얻어와서 그것을 제어 ● 다수의 인스턴스 존재시 상호간의 영향으로 예상외의 버그 발생 ● 하나의 클래스에서 각각의 인스턴스를 얻어오면 엄청난 리소스의 손실 발생 ● 개별적인 인스턴스로 많은 Garbage가 발생하고 CPU의 낭비 ● 하나의 인스턴스만을 얻어온다는 것은 메모리 공유의 효과 3. An example ● 프린터 스풀러 - 각각의 인스턴스 발생 시 시스템의 엄청난 리소스와 CPU의 낭비 ● 데이터 베이스 엔진 - 하나의 데이터 베이스로 여러 사용자에게 같은 정보 공유, 효과적인 관리 ● 사용자 인증 시스템 - 하나의 로컬 pc에서 하나의 user ID와 password를 얻어와 .. Decorator pattern 1. Issue ● 객체에 정해진 기능이 아닌 동적으로 기능을 추가할 수 있는가? 2. Why ● 프로그램의 확장에 따라서 새로운 기능이 추가되거나 삭제 될 때가 잇다. ● 클래스에 새로운 기능을 추가하면 클래스를 재정의 해야 한다. ● 새로운 기능 추가에 대해 클래스 상속을 이용하면 수많은 클래스가 생겨버린다. 3. Solution (Decorator 패턴) ○ 기존에 존재하는 기능 외에 새로운 기능 추가 시 연결고리(Decorator) 를 하나 만들어 준다. ○ 기존에 존재하는 기능이 아닌 기능이 새로 추가 된 것처럼 적용 ○ 객체들 간의 관계 class Decorator : public Airplane { public : Decorator(Airplane * pObj) { pComponent_ = .. Builder pattern 1. Background ● 실제적인 객체의 생성은 한번에 생성되지 않는다. ● 객체를 구성하는 데이터 멤버들을 일일이 생성 ● 생성자의 호출로 인해서 객체를 생성 2. Issue ● 효과적인 객체 생성을 위해 부분 부분을 따로 생성하여 이를 조합해서 객체를 생성할 수 있는가? 3. Why ● 여러 부분에 걸쳐서 값이 입력되는 객체의 경우 ● 입력된 정보만을 저장할 많은 공간 필요 ● 최종 입력 후 객체 생성에도 시간이 많이 걸릴 수 있다. ● 내부구조의 변경 시 기존 소스 코드에 많은 영향을 준다. 4. Good point ● 객체의 생성 부분과 실제 표현하고 구성하는 부분을 분리시켜 서로간의 독립성 보장 ● 독립성의 보장으로 독립적인 수정 및 재사용이 가능 ● 서로 다른 표현방식을 가지는 객체를 동일.. 이전 1 2 3 다음
