꿈을 코딩하는 프로그래머.

Class A

{

Public:

A() { AAAAA;}

A(a) { A(); }

}

위와 같이 호출을 하니 자꾸 소멸자가 호출되더라. 이유인 즉슨

A()와 같이 다른 생성자를 호출하면, 자신의 생성자 호출이 아니라 임시 객체를 만들어 생성자를 호출하고

해당 임시객체가 라인을 벗어나며 소멸되어 다시 소멸자가 호출 되더라.

그럼 어떻게 해야 하나?

다른 언어에서는

A(a) { this(); } 혹은

A(a) { this->A() } 와 같은 방법이 가능 하던데

C++에서는 허용 되지 않는 문법. 따라서

A() { init(); }

A(a) {init(); }

와 같이 별도의 초기화 함수를 두는 것이 좋겠다.

바이너리 데이터 : 프로그래밍 언어나 프로그램에서 사용되고, 화면에 출력되는 숫자나 문자열 등이

실제로 메모리에 저장되는 16진수의 형태. 숫자 1의 바이너리 데이터와, 문자열 1의 바이너리 데이터는

다른 값으로 저장된다.

텍스트 데이터 : 바이너리 데이터 중, 문자 코드로 표현이 가능한 데이터. 값 중간에 NULL이 올 수 있냐 없냐 

차이가 바이너리와 텍스트 데이터의 가장 큰 차이. 텍스트 중간에 NULL이 있으면 그 전까지만 텍스트로 

출력 되고, 이 후 데이터는 출력 안됨.

스트림 : 데이터의 흐름, 데이터 전달 되는 모습? 통로?. 예로 파일 스트림을 사용하여 문자열, 정수값 등을 파

일에 바이너리 데이터로 저장 한다.

인코딩 : 문자열을 표현하기 위한 코드 값. 예로 아스키, UTF8, UTF16 등등

*인터넷 뒤지며 얻은 정보를 개인 적으로 종합, 정리 하였음.

- 라인 피드 (LF : Line Feed, 0x0a) : 캐럿을 다음 줄(현재 위치에서 바로 아래)로 이동 시킨다.

- 캐리지 리턴 (CR : Carriage Return ) : 캐럿을 줄의 맨 앞으로 이동 시킨다.

즉 모두 '줄 바꿈'과 관련이 있는 문자다.

줄 바꿈에 대한 정의는 시스템(OS), 언어 마다 다르다.

- 유닉스/리눅스 : LF만으로 줄 바꿈을 정의 한다.

- 윈도우/DOS : CRLF 조합으로 줄 바꿈을 정의 한다.

- C언어 : 유닉스 태생으로 LF만으로 줄 바꿈을 정의 한다.

위와 같이 유닉스/리눅스 시스템과 윈도우/DOS 시스템의 줄 바꿈에 대한 정의에 차이가 있다.

프린터나 타자기?와 같은 장비에선 LF로 캐럿의 위치를 현재 위치에서 바로 아래로 이동 하며 CR을 통해 줄의 맨 앞으로

이동 시키는 CR/LF (LF/CR과 다르다)의 조합을 통해서 줄 바꿈이 이루어 지는데

윈도우와 DOS는 이를 그대로 따라 가고 있다.(시스템 입장에서 보면 불편 한듯?)

따라서 윈도우의 파일을 그대로 리눅스로 옮기면 문자열 맨 끝에 '\r\n'이 붙게 되며

이를 리눅스 프로그램에서 그대로 사용시 문제가 발생할 소지가 있다.

윈도우와  DOS의 경우 C의 줄바꿈에 대한 정의와 차이가 있다.

즉 윈도우와 DOS에서 작성된 C프로그램이 줄바꿈을 '\n'으로 입력하면 하거나 읽어들이면

실제 파일에 '\r\n'으로 기록 되거나 읽히게 된다.

이러한 차이를 없애기 위해 fopen 함수 호출시 두번째 인자로 'b'(바이너리 모드)를 주지 않게 되면 C 라이브러리에서

'\n'을 '\r\n'으로 인식 하게 된다. 그러나 이 경우 두개의 '\r\n' 문자를 하나의 '\n' 문자로 인식 하기 때문에

파일 크기를 다루는 상황 등에서 문제가 발생할 수 있다.

이전 리눅스 파일 시스템에서 File의 최대 크기는 2147483647byte 즉 2GB(1.99)였다.

이는 2^31 -1의 값이다. 즉

int32형에서 표현 가능한 최대 양수이다.

OS상에서 File의 주소, Offset 관련 Data가 int32형으로 표현 되어 있었기에 제한이 있었던 것 같다.

마찬가지로 fopen, fwrite등의 함수로 2GB넘는 파일에 접근이 불가능 하다. 내부적응로 int32가 박혀 있을 것 같다.

그래서 라이브러리에서는 2GB 이상의 파일을 다룰 수 있도록 fopen64, fwrite64등의 함수를 제공 하고 있다.

그렇다면 기존의 파일은 어떻게 하나? 일일히 바꾸기 힘들기에 다음 옵션을 사용 할 수 있다.

컴파일 옵션에 -D_FILE_OFFSET_BITS=64 을 입력 하면 file 관련 함수, 변수들이 자동으로 32->64 bit용으로 변경이 

된다고 한다.

** 16.02.07 추가

fseek 함수와 ftell 함수는 위의 컴파일 옵션으로 해결이 안된다.

이 함수들은 자체적으로 fseeko 와 ftello 함수로 변경 해주어야 한다.

BSD(Berkeley Software Distribution)는 1977년 미국 캘리포니아 대학교 버클리(University of California, Berkeley)에서 개발한 유닉스 계열의 컴퓨터 운영 체제이다.

출처 : 위키 백과

소프트웨어 개발 프로세스에서 

개발 단계 이상의 자원(인력, 시간 등)이 소모 되는 단계가 바로 유지보수 단계이다.

유지보수를 고려하여 설계되지 않은 프로그램을 수정하는대에는

많은 시간,돈,인력이 필요 하며 그러한 투자가 프로젝트에 이익을 남기지 않는다.

즉. 아무리 투자해도 이윤은 남지 않는 결과를 초래 한다.

그래서 유지보수 단계는 개발보다 중요하며, 유지보수를 고려하여 프로그램을 설계해야 하는 이유가 된다.

유지보수를 고려하지 않은 프로그램에 요구사항 수정이 들어오면 개발자들은 다음과 같은 반응을 보이곤 한다.

"별거 아닌 기능이지만, 그 기능을 추가 하기 위해서는 너무 많은 코드를 수정 해야하고, 그로 인해 어떠한 사이드 이펙트가 발생할지 모른다"

프로그램을 설계할때는 수정이 용이하게, 유지보수가 쉽도록 설계 해야 한다. 그렇기 위해 필요한 것이 바로

캡슐화와 추상화를 적용한 객체 지향 설계!

정수 표현시에 반올림을 적용하면 0~4까지는 내림, 5~9까지는 올림수가 된다.

한 예로 1의자리 반올림을 하면

14 - > 10

15 - > 20

이와 같이 변한다. 하지만 소수점은 어떻게 적용이 될까??

소수점 이하 첫째자리까지만 표시하도록 해보았다.

float a = 0.54;

float b = 0.55;

float c = 0.56;

printf("%f\n", a);      - a1

printf("%0.1f\n", a);  - a2

printf("%f\n", b);      - b1

printf("%0.1f\n", b);  - b2

printf("%f\n", b);      - c1

printf("%0.1f\n", b);  - c2

이때 출력값은

a1 : 0.54    a2: 0.5 (예상 결과 0.5)

b1 : 0.55    b2 : 0.5 (예상 결과 0.6)

c1 : 0.56    c2 : 0.6 (예상 결과 0.6)

어째서 b의 결과는 예상 결과와 상이한 것일까?

0.55를 소수 첫째자리까지 반올림하면, 두번째 자리 5가 올림되어 0.6되는게 아닌가?

해석.

2진수 컴퓨터 체계에서 숫자는 정수부분과 실수부분으로 나뉜다.

이때 정수부분 표현은 어떤수라도 표현 가능 범위에만 있으면 100% 정확하게 표현이 가능하다.

하지만 실수 부분은 그렇지 않은데 

0.5 = 0.1 (2)

0.25 = 0.01 (2) 와 같이 2진수로 맞아 떨이지게 계산되는 수가 있는가 하면

0.55 = 0.1000110011001100....(2)와 같이 떨어지지 않는 수도 있다

즉 2진수 체계에서는 실수를 정확하게 표현할 수 없다.

위의 예를 돌아가 보자.

입력 값들은 실제 다음과 같은 값으로 저장되어 있다.

0.54 = 0.539559..... (출력시에는 0.54로 보임)

0.55 = 0.5487....     (출력시에는 0.55로 보임)

0.56 = 0.558......     (출력시에는 0.56으로 보임)

즉 가장 근사한 값일 뿐이지 실제 0.55를 입력했다고해서 메모리에 0.55가 정확히 저장되어 있지 않는다.

그렇기 때문에 소수점 첫째자리까지 출력한다고 하면.

입력한 0.54 -> 0.5가 되는 것이 아니라 0.539559 -> 0.5가 되고

입력한 0.55 -> 0.6이 되는 것이 아니라 0.5487 -> 0.5가 되고

입력한 0.56 -> 0.6이 되는 것이 아니라 0.558 -> 0.6이 되는 것이다.

결론.

컴퓨터에서 소수점 이하 출력시에는, 입력한(눈에 보이는) 값 자체로 반올림을 따지면 결과가 다르고,

실제 저장된 값을 확인해 봐야 한다.

strcpy_s 함수 사용으로 인해 발생한 버그를 잡느라 몇시간을 소비했다.

그 이유를 알아 보자.

우선 문제 발생한 코드를 간략하게 구현해 본다.

a[100] = "test1";

b[100] = "";

c[100] = "test2";

위처럼 선언을 하면

아래와 같이 메모리가 할당된다

a메모리 : 't', 'e', 's', 't', '1', '\0', '\0', '\0', , , , , , , , 

b메모리 : '\0', '\0', '\0', ,,,,,,,,

c메모리 :  't', 'e', 's', 't', '2', '\0', '\0', '\0', , , , , , , , 

이때 

strcpy_s ( b, 200, "test3" ); 

함수를 선언하면

어처구니 없게도 a메모리 공간에 있던(꼭 배열 a가 아닐수도 있다.) test1이라는 문자열은 사라지고 이상한(?) 

값들이 채워져 버린다.

(회사에서 vs2008, .c 로 코딩시 런타임 에러가 없었는데 집에서 vs2012, c++ 로 코딩시 런타임 에러가 뜬다.)

이유를 알아보자.

strcpy(char *dest, char *src);

이 함수는 dest 포인터가 가리키는 메모리 공간에 src 포인터가 가리키는 문자열을 복사한다.

문자열 복사후 남은 공간은 모두 '\0'(0, 널값) 으로 채운다.

strcpy_s(char *dest, size_t length, char *src);

이 함수는 dest 포인터 위치에 src 문자열을 length만큼 복사한다.  - 문제1

문자열 복사후 남은 공간은 모두 이상한(?) 값으로 채운다.  - 문제2

(msdn 페이지에서 strcpy_s함수 설명을 보면, 디버깅모드에서는 남은 공간을 0xfd값으로 채운다고 하나

내가 확인했을때는 -2라는 값이 들어가 있었다.)

이 버그는 문제1, 문제2의 특성때문에 일어난다.

 strcpy_s 함수는 문자열을 length만큼 복사하며(dest 메모리 공간보다 클지라도 복사해 버린다.) - 문제1

src문자열 복사 이후에는 모두 0xfd 문자로 채워 버린다. - 문제2

그렇기 때문에 a배열까지 침범하여 문자열 복사를 진행하였고 이때 a배열에는 '\0'값이 아닌 0xfd값이

채워지므로 a배열을 사용할때에는 이유도 모르게 값이 바뀌어 있는 것이다.

* 집에서 vs2012, cpp로 테스트 한 결과 런타임 에러를 즉각즉가 출력해줬음.

* 회사에서 재 확인

LNK2019의 원인은 여러가지가 있는데

내가 방금 겪은 이 에러의 원인은

프로젝트에 .c파일과 .cpp파일이 공존하는 아주 기초적 실수로 인한 발생이었다.

더 자세한건 아래의 블로그를 통해 확인하자.

http://blog.naver.com/PostView.nhn?blogId=sadiles&logNo=10072075057

"좋은 조건으로 일하고 싶다면 단순히 코딩만 잘하는 사람으로 남아서는 안될 것이다. 큰 그림을 그릴 줄 아는

사람이 되어야 한다. 만일 기술의 진보가 프로그래머의 수요를 줄이는 날이 와도 매니저 그리고 시스템 디자인 

능력을 가진 이들에 대한 수요는 분명히 있을 것이다"

- 프로그래머 그들만의 이야기 by 한기용