Secure-Ark

1. std::wstring, string - 쓸만한 문자열 라이브러리가 별로 없어서 (아 이건 윈도우만 문제가 아니구나 c++문제군) atl이나 mfc의 cstring을 쓰고 싶지만 그것도 또 애매해서 그 이유는 format이나 findall처럼 좀 일반적으로 잇을만한 것도 없어서 각 회사들은 대부분 자신만의 라이브러리를 다 들고 있다. 이왕이면 자신만의 문자열 라이브러리는 만들어보는 게 낫다. 2. 유니코드, utf-8, utf-16 등 인코딩 문제 크로스플랫폼까지 안가더라도 유니코드, utf-8에 대해서 변환 및 처리하는 것에 대해 확인하는 것이 좋다. ucs라는 개념도 있고, 지역 코드 및 별 게 다 있는데 이왕이면 숙지하는 편이 좋다. 3. 경로 윈도우는 중간에 패스에 공공연히 Program F..

1. std::wstring, string - 쓸만한 문자열 라이브러리가 별로 없어서 (아 이건 윈도우만 문제가 아니구나 c++문제군) atl이나 mfc의 cstring을 쓰고 싶지만 그것도 또 애매해서 그 이유는 format이나 findall처럼 좀 일반적으로 잇을만한 것도 없어서 각 회사들은 대부분 자신만의 라이브러리를 다 들고 있다. 이왕이면 자신만의 문자열 라이브러리는 만들어보는 게 낫다. 2. 유니코드, utf-8, utf-16 등 인코딩 문제 크로스플랫폼까지 안가더라도 유니코드, utf-8에 대해서 변환 및 처리하는 것에 대해 확인하는 것이 좋다. ucs라는 개념도 있고, 지역 코드 및 별 게 다 있는데 이왕이면 숙지하는 편이 좋다. 3. 경로 윈도우는 중간에 패스에 공공연히 Program F..

위에는 프로젝트 설정이고, 경로는 일반적으로 헤더를 inlcude 하는 이런 추가 포함 디렉토리, 라이브러리 참조 시에 쓰는데, 나는 정말로 상대경로로 ./ 나 ../../ 로 쓰는 사람을 정말로 정말로 정말로 너무 싫어한다. 비주얼 스튜디오는 위에 $(TargetPath) $(SolutionDir) 처럼 '기준점'을 잡아서 찾아낼 수 있는 경로를 만들어두었다. 물론 오픈소스의 경우에는 자신이 '어디에' 포함될지 모르니 그렇게 할 순 있다 치더라도 자신의 프로젝트나 회사 프로젝트에서 ../../../../../ 이런 식으로 도배하는 경우를 보면 정말 화가 난다. 저걸 분석하면 어떤 생각이 드는가. 그러나 $(SolutionDir)\..\..\ 이정도는 괜찮다. 왜냐, 기준점이 있으니까 찾기가 어렵지 않다..

비주얼 스튜디오의 프로젝트 속성 페이지를 보면, 여러가지 참 많다. 그 중에 쓰는 것만 쓸텐데, 오늘은 그냥 날 잡고 전부 '다' 설명하기로 한다. 다음 편엔 빌드, 디버깅, 링크에 대해서 진행하기로 한다. 1. 일반 자 보기만해도 짜증이 밀려온다. 위에 [구성]부터 보자. 이 구성은 '프로젝트의 구성'에 대해 설명한다. 앞으로 당신이 빌드할 일련의 해당 프로젝트에 대한 '빌드' 설정을 의미한다. 원래는 구성과 플랫폼을 엮어서 빌드 설정이라 볼 수 있는데, 플랫폼은 빌드하는 플랫폼을 설명하므로 따로 분리되어 있을 뿐이다. Release - x64 라는 것은 릴리즈 모드라 명명하여 주로 릴리즈 시에 동작 가능하도록 편하게 구성을 맞춰놓고 x64 라는 것은 x64 플랫폼일 때는 x64 플랫폼에 맞는 '바이너..

struct 구조체는 얼핏 보기에 클래스와 비슷하지만 다르다. 기본 멤버들이 public으로 표현된다는 점과, C 파일에서는 struct 구조체 { 멤버1; 멤버2; } 라고 표현한 경우에 그것을 사용하는 함수내에서 즉시 구조체 instance; 라고 출력할 수 없다. struct 구조체 instance;라고 해야 쓸 수 있다. 반면에 C++에서는 (CPP) 사용자 정의 자료형(구조체 포함)이 클래스처럼 기본 자료형으로 인식되기 때문에 그냥 구조체 instance; 이렇게 선언해도 된다. 다만 위의 struct 구조체 { 멤버1; 멤버2; } 는 너무 오래된 c 스타일 방식이다. 그렇다고 typedef struct 구조체이름_ { 멤버1; 멤버2; } 구조체이름; 같은 방식도 마찬가지로 구리다. 그렇기 ..