방프리

오류 C1189 #error: MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header. 라는 오류를 발견하였다. 윈도우 버전이 너무 낮기 때문에 발생하는 에러로 #define WINVER의 값을 수정하면 된다. * 컴파일러 버전 구분 값 1000 : Visual C++ 4.x (4.0) 1100 : Visual C++ 5 (5.0) 1200 : Visual C++ 6 (6.0) 1300 : Visual C++ .NET (7.0) 1310 : Visual C++ .NET 2003 (8.0) 1400 : Visual C++ ...

* SAFESEH ( Structured Exception Handling) 윈도우 상에서 예외처리를 하는 기법 - 메모리에 대한 손상이 발생하거나 시스템이 예기치 않게 종료되는 이벤트 발생시 프로그램에 대한 예외처리 담당 - 외부 공격자가 프로그램에 대해 예외처리 레코드를 덮어쓰게 되면 이 예외를 탐지하여 프로그램 종료 * 해결방안 (1) 옵션 On/Off 프로젝트 속성 - Linker - 고급 - 이미지에 안전한 예외처리기 포함 (예 /아니오) 혹은 명령줄에서 /SAFESEH:NO 입력 해결법 프로젝트 속성 - 구성 속성 - Linker - 명령줄 /safeseh:no

LNK2005 에러로 몇 시간동안 헤맸었다. 이 에러를 고치면서 발생원인이나 해결 방법 여러 개를 찾아보았는데 한번 정리해볼까 한다. 1. 헤더파일이 중복으로 선언된 경우 보통 이 경우는 그리 많이 발생되지 않을 것이라 생각된다. LNK2005 에러가 발생하는 주 원인이기는 하나 현재 Visual Studio에서 클래스를 생성하면 자동으로 #pragma once를 선언해주기 때문에 헤더 중복 선언이 일어나지 않을 것이기 때문이다. 일어난다면 아주 옛날 버전의 프로젝트에서 발생된 확률이 매우 크다. 해결방법으로는 #ifdef !defined _STDIO_H \n #define _STDIO_H 이렇게 해주면 된다. 2. 문제의 모듈을 찾아 순서대로 적용하는 것이다. - 링커 -> 명령줄에서 /verbose를..

항목 41. ptr_fun, mem_fun, mem_fun_ref의 존재에는 분명한 이유가 있다. 위의 함수들이 C++이 원래부터 가진 문법적 모순을 감싸주는 함수라고 합니다. (몰라요 전.... 저자가 그랬어요...) 무슨 모순인지 예제를 통해서 알아보겠습니다. f란 이름의 함수와 x란 이름의 객체가 있습니다. x에 대해 f를 호출하고 싶으며, 호출하는 위치는 x의 멤버 함수의 바깥쪽입니다. 이런 상황에서 다음과 같은 문법을 제공할 수 있습니다. f(x); // 문법 #1 : f가 멤버 함수가 아닌 경우 x.f(); // 문법 #2 : f가 x의 멤버 함수이고, x는 객체이든지 객체에 대한 참조자인 경우 p->f(); // 문법 #3 : f가 x의 멤버 함수이고, p는 x 객체에 대한 포인터인 경우 v..

항목 45. count, find, binary_search, lower_bound, upper_bound 그리고 equal_range를 제대로 파악해두자 (1). count : 작업 대상이 정렬되어 있지 않았을 때 사용합니다. 작업 후 true는 양수, false는 0으로 해석이 가능하며 작업이 시작되면 원하는 대상을 찾아도 범위 끝까지 갑니다. (2). find : 범위의 접근자를 지정해주어야 한다는 단점이 있지만 요소를 찾으면 바로 실행을 중단합니다. 객체의 존재 여부 뿐만 아니라 객체 자체에 대해 알고 싶을 때 사용합니다. (3). binary_search : 객체가 존재하는지 여부에 대해서만 확인합니다. 반환값은 bool 입니다. (4). lower_bound : 원하는 값을 가진 객체의 첫째 ..

항목 40. 함수자 클래스는 어댑터 적용이 가능하게(adaptable) 만들자 - 이 항목을 살펴보기 전 우리는 먼저 ptr_fun에 대해 알아보아야 합니다. ptr_fun이란 typedef 타입 몇 개를 쓸 수 있도록 만들어 주는 것입니다. 왜 typedef 타입으로 해주어야 할까요? STL의 4대 표준 함수 어댑터(not1, not2, bind1st, bind2nd)가 모두 typedef 타입으로 동작하기 때문입니다. 표준 STL이 아닌 SGI, Boost 등도 마찬가지 입니다. 그래서 typedef를 제공하는 함수 객체를 "어댑터 적용이 가능하다"라고 하고 제공하지 않는 함수 객체를 "어댑터 적용이 불가능하다" 라고 정의합니다. typedef를 제공하는 함수 객체는 그렇지 않은 것보다 더 많은 일을..

항목 46. 알고리즘의 매개 변수로는 함수 대신 함수 객체가 괜찮다. - 프로그래머가 코딩을 할 때 추상화의 정도가 높아질수록 코드의 효율을 떨어지게 됩니다. ( 상속 받는 부모의 클래스의 양이 많아지기 때문인 것 같습니다.) 간단한 예로 double을 가진 클래스를 조작하는 코드는 double을 직접 조작하는 코드보다 느리다는 것을 알 수 있습니다. 하지만 STL 함수객체를 알고리즘에 넘기는 게 진짜 함수를 넘기는 것보다 빠릅니다. (말이 안되죠;; 방금 위에서는 간접 조작이 느리다고 해놓고선) 예로 double의 백터를 내림차순으로 정렬한다 코딩을 한다면 이렇게 할 것입니다. vector v; ... // 이외의 코드 sort(v.begin(), v.end(), greater()); 만약 위의 내용을..

항목 1. 적재적소에 알맞는 컨테이너를 사용하자. - 각각의 컨테이너에는 장, 단점이 존재합니다. 프로그래머는 컨테이너들의 기능에 대해 잘 숙지하고 만들고자 하는 기능에 맞게 컨테이너를 사용할 줄 알아야 합니다. 항목 2. "컨테이너에 독립적인 코드" 라는 환상을 조심하자. - 컨테이너를 사용할 때 항상 하나의 컨테이너만 사용한다는 고정관념을 버려야 합니다. 유지보수나 제작 시에도 해당 기능의 방향이 달라질 수 있음을 고려해야 한다는 것입니다. 예를 들어 처음엔 vector 컨테이너가 적합하다고 생각하다가 나중엔 list 컨테이너로 바꾸어야할 상황이 올 수도 있기 때문입니다. 해결방법으로는 typedef를 활용하여 컨테이너를 선언하는 것입니다. ex) typedef std::vector VInt; VIn..