별빛의 낙하지

/*
	Move Constructor( 이동 생성자 )

	c++0x 에는 r-value reference의 도입으로 인해서 Move Constructor가 생겼다.
	이동 생성자의 특징은 복사 대상의 데이터를 지우는 소유권 이전 방식이다.

	기존에 있던 reference는 그래서 이름이 l-value reference 로 불린다.
	l-value 와 r-value 의 차이는 대입식에서 왼쪽에 오느냐, 오른쪽에 오느냐의 차이인데
	
	간단히 말해서 l-value 는 변수라고 보면 되고, r-value는 상수라고 보면 된다.
	기존에 l-value reference는 l-value들만, 즉 변수들만 가리킬 수 있는 반면에
	r-value reference는 r-value 들만, 즉 상수들을 가리킬 수 있다.
	
	int b = 3;
	int& a = b;
	int& c = 3; // error
	
	int&& d = a; // error
	int&& d = 3; // ok.

	r-value reference가 사실 그냥 보기에는 이동 생성자와 전혀 무관해 보이는데, 이것은 기존에
	복사 생성자로 표현하기 어색했던, 소유권 이전방식을 적절히 표현하기에 적합하다.

	무슨 말이냐면,  기존에 auto_ptr 과 같은 소유권 이전의 스마트 포인터들은 값을 이동시키고 싶어하지만,
	적절한 표현이 없어서, const를 제외시킨 아래와 같은 방식으로 구현을 했었다.

	auto_ptr(auto_ptr& a)
	
	문제는 이것이 복사하려는 것인지, 이동하려는 것인지에 대한 명확한 지표가 되기 힘들다는 것.
	이 문제를 해결한 것이 r-value reference(&&)의 등장이다.
r
*/

#include 

class MoveClass
{
public:
	// Default Constructor
	MoveClass() {
		std::cout << "Default Constructor Call" << std::endl;
	}
	
	// Copy Constructor
	MoveClass(const MoveClass& a)	// 반드시 const로 해야 된다. 그렇지 않으면 Move Constructor가 제대로 호출되지 않는다.  
	{
		std::cout << "Copy Constructor Call" << std::endl;				

	}

	// Move Constructor
	MoveClass(MoveClass&& a)
	{
		std::cout << "Move Constructor Call" << std::endl;

	}
};


// 값이 복사되는 곳에서는 일반적으로 복사 생성자가 호출된다.
MoveClass foo(MoveClass& a)
{
	MoveClass local;
	return local;		// 값이 복사 되는데, 우선순위가 존재한다.
						// MoveClass(const MoveClass& a) 형태의 복사 생성자가 존재하고,
						// MoveClass(MoveClass&& a) 형태의 이동 생성자가 존재하면
						// 이동 생성자를 호출한다.
}

int main()
{
	MoveClass a;	// Default Constructor Call

	foo(a);

	MoveClass b(a);					// Copy Consturctor call
	MoveClass b(std::move(a));		// Move Constructor call

}

C++은 함수 오버로딩을 지원하기 때문에 기존의 C스타일의 이름의 함수로는 함수오버로딩을 지원할 수 없다. 

따라서 함수 이름에 대한 데코레이션(decoration) 혹은 맹글링(mangling)이 필요하다.

(데코레이션과 맹글링은 이름을 꾸미는 것, 섞는 것이라는 그런 의미다.)

*네임 맹글링 자체가 함수를 구분해주기 위한 용도로써라고 이해하기 되면 약간 거시기 하다.

정확히 이야기하면 C에서도 함수를 부를때 네임 맹글링을 한다. 

"_"를 함수 이름에 붙이는데,  C++기준으로 보면 이건 네임맹글링 수준이 매우 미미하다.

여기서는 함수 오버로딩을 지원하기 위한 측면에서 살펴보겠다.

name mangling, 혹은 name decoration을 하기 위한 것은 컴파일러가 결정하게 되는데,

일반적으로 함수의 파라미터로 함수 지원한다고 생각했었으나 실제 테스트 해보니 그렇지 않았다.

VC++ Compiler에서 반환값도 네임 맹글링에 포함된다.

예를 들어서 아래는 반환값 test2(void) 의 함수 시그니처이다.

PE View를 만드는 과정을 블로그에 업데이트 할 예정이다.

C++ 관련 책을 보면 아래와 같은 코드에서 C++ 컴파일러가 클래스 내에서 생성자가 정의되어 있지 않을 경우, 기본 생성자(default constructor)를 삽입한다고 알려져 있다.

하지만 실제로는 컴파일러 구현체에 따라서 달라지겠지만, 내가 현재 주로 쓰고 있는 VC++에서는 그러한 뻘짓(?)을 하지 않는다.

class Ref
{
public:
	int a;
	int b;

};

int main()
{
	Ref a;
	a.a = 12;
	a.b = 13;
	Ref b = a;

}

실제 어셈블리로 변환된 코드는 아래와 같다.

놀랍지 않은가?  보시다시피 기본 생성자를 부를꺼라고 예상했지만, 실제로는 그러한 코드는 없다.

또한 디폴트 복사 생성자도 존재하지 않음을 알 수 있다.

만약 생성자가 존재하는 상태에서 기본 복사 생성자도 존재할까?

아래의 코드를 디스어셈블 해보았다.

class Ref
{
public:
	int a;
	int b;
	Ref(int a, int b) { cout << "1 "; }
};

int main()
{
	Ref a(1, 2);
	Ref b = a;
}

그 결과 아래와 같은 코드로 변환이 되었음을 알 수 있었다.

즉 사용자가 정의한 생성자는 호출되었지만, 복사 생성자는 역시 존재하지 않음을 알 수 있다.

객체의 동적 할당인 경우는 어떻게 될까?

아래의 코드를 보자

class Ref
{
public:
//	Ref(){ cout << "constructor call" << endl; }
//	~Ref() { cout << "destructor call" << endl; }

};

int main()
{
	Ref* p = new Ref;

	delete p;


}

즉 여전히 기본 생성자는 찾아 볼 수가 없다. 메모리 할당, 해제와 관련된 함수 호출이 있을 뿐이다.  여기서 재미있는 것은 소멸자 또한 없다는 사실이다.

비교를 하기 위해서 아래는 명시적으로 생성자를 지정한 경우의 동적할당 어셈코드이다.

class Ref
{
public:
	Ref(){ cout << "constructor call" << endl; }
	~Ref() { cout << "destructor call" << endl; }

};

int main()
{
	Ref* p = new Ref;

	delete p;


}

어셈블러 입장에서 C++의 파라미터를 값으로 넘기는 함수(call by value), 레퍼런스로 넘기는 함수(call by reference), 포인터로 넘기는 함수(call by pointer) 의 구현체들은 어떠한 차이가 있을까?

void callByValue(int a )
{

}

void callByReference(int& a)
{

}

void callByPointer(int* a)
{

}

int main()
{
	int number = 1;
	int value = number;
	int* pointer = &value;
	int& reference = value;
	
	int depointer = *pointer;
	int dereference = value;

	callByPointer(pointer);
	callByValue(value);
	callByReference(reference);


}

함수의 구현체는 파라미터의 종류에 관계 없이 동일한 방식이었다.

함수 호출전 변수에 값을 대입하는 코드는 변수의 경우 dword ptr[변수이름]을 통해서 해당하는 변수의 값을 가져와서 mov(복사) 하는 코드임을 알 수 있으며, pointer와 reference의 경우 lea 명령(load effective address)을 이용한다.

Load Effective Address란 의미로 다음의 인자를 주소값으로 인식합니다.

  지난 3년간 안드로이드와 관련된 부분들은 주로 앱을 만드는 것부터 시작해서 안드로이드 프레임웍까지 관심을 가져왔다.  이 책은 '안드로이드의 모든 것 분석과 포팅' 이후 버전으로 나온 책으로 서문에 따르면, 원래 이전 책에서 다루고 싶었지만, 시간 관계상 미뤄졌던게 드디어 책으로 나왔다고 한다.

  국내에서 안드로이드의 구조를 분석한 책은 몇권 되지 않아서, 개인적으로 다 보았었는데(저자의 이전 책 포함), 편집이나 흐름 자체가 이전 책과 비슷한 맥락이다.

  책은 전반적으로 NDK를 다루고 있고, 현재 나와 있는 NDK로 지원안되는 부분들에 대한 방법(PDK)도 제시하고 있다.  (어차피 NDK나 SDK나 PDK에 포함되는 관계이므로 라는 설명으로)

  책 전반적인 구성은 JNI와 같은 C/C++와 자바를 이어주는 가교부터 시작해서, 빌드하는 방법, NDK 관련해서는 주로 지원되는 라이브러리(OpenGL, Neon 등)와 관련된 예제에 대한 설명이 주를 이룬다.  Makefile 관련해서는 필요한 설명만 되어 있어서,  실습할 때 발생하는 예외적인 경우는 구글링으로 찾아봐야 될 것이다. 

  책을 읽으면서 좋았던 부분중에 하나는 저자가 이전에 실제 삽질한 결과나 고생했던 것에 대한 케이스에 대한 설명이 있다는 것이고(ex) 라이브러리를 불러 오는 과정에 있어서 순서가 꼬인 경우), 전반적으로 학습하기에 정리가 잘 되어 있다는 점이다.(처음 부터 예제를 설명하지 않는다. 필요한 기본 선수 지식에 대한 설명이 되어 있다.)

  책을 읽으면서 인상깊었던 부분은 예전에 과제를 진행하면서 불편하지만, 있는지 조차 몰라서 쓰지 못했던 것들이다.  나같은 경우 JNI쪽의 SWIG을 비롯해서 디버깅쪽에 addr2line, ndk-gdb 등이다.

  또한 중반 이후로 순수(?) NDK를 지나서 PDK로 넘어가게 되면 직접적으로 binder 의 개념자체가 필수불가결하게 되는데, 이러한 설명이 구조와 연관된 부분이라 이 책에서는 많이 다루지 않아서 이 부분은 이책만 봐서는 이해하기 힘들것이다.

  그리고 Appendix 에서 안드로이드와 관련해서 대략적인 설명을 하고 있는데, NDK와 관련해서 큰 그림을 먼저 알고 싶다면, 먼저 봐도 괜찮을 것 같다.

  아쉬운점으로 IT 전공서적의 특징상 책의 소스코드가 사실 그렇게 보기 좋게 나열된 것은 아니다.  소스코드가 끝난 다음에서야 설명이 등장하는 식인데,  주석처럼은 아니지만 중간중간에 설명을 인라인화 시키는 것이 가독성 측면에서 어떨까 생각한다.

<덧붙여>

혹시나 NDK를 모르는 사람들을 위해서 한가지 이야기를 하자면, 기존의 안드로이드 앱 개발방식이 SDK를 통한 자바 개발환경이었다면, NDK는 C/C++ 환경을 제공한다는 것이다. 여기서 NDK에 대해서 자바 코드가 전혀 없이 순수하게 C/C++로 작성하는 방법이라고 잘못 알고 있는 경우도 있는데 그렇지 않다.  java 코드에서 jni 인터페이스를 통해서 C/C++ 라이브러리를 호출하는 것이 NDK이다. 심지어 액티비티를 네이티브 수준으로 끌어 내리는 NativeActivity 예제만 봐도 java 코드에서 C/C++로 작성된 so library를 로드하여 콜백 하는 형태로 되어 있다.

  헤더를 설계할 때는 정의(오직 한번만 사용할 수 있다.)와 선언(여러번 사용할 수 있다.)의 차이를 반드시 기억해야 한다.  다음 문장은 정의이므로 헤더에서는 사용하지 말아야 한다.

extern int ival = 10; // 초기값이 있으므로 정의이다.

double fica_rate; // extern이 없으므로 정의이다.

같은 프로그램에 속한 파일들 가운데 두 개 이상에서 이 정의를 포함하면 여러 개의 정의를 사용했다는 불평과 함께 링커가 오류를 일으킨다.

<예외>

 헤더에 정의를 포함하지 말아야 한다는 규칙에는 예외가 3가지가 있다. 클래스, 컴파일 시점에 값을 알 수 있는 const 객체, inline 함수가 그것인데 이들은 모두 헤더에 정의를 포함한다. 이들 요소는 각 파일별 정의가 똑같을 경우 여러 소스파일에 정의할 수 있다.

왜 그럴까... 컴파일러가 코드를 만들려면 이 요소의 (선언이 아닌) 정의를 알아야 하므로 헤더에 정의해둔다.  예를 들어 클래스 타입 객체를 정의하거나 사용하는 코드를 만들려면 컴파일러는 그 타입에 어떤 멤버가 있는지 알아야 한다.  또한 이 객체에 어떤 연산을 해야 하는지도 알아야 하는데, 이런 정보는 클래스 정의에 들어 있다. const 객체를 헤더에 정의하는 이유는 좀더 설명이 필요하다.

const 객체는 기본적으로 파일에 지역적이다.

  const가 아닌 변수를 전역 사용 범위에서 정의하면 프로그램 전체에서 접근할 수 있다.  한 파일에서 const가 아닌 변수를 정의하고(적절히 선언했다고 가정하면)  다른 파일에서 그 변수를 사용할 수도 있다.

// file_1.cc

int counter; // 정의

// file_2.cc

extern int counter; // file_1의 counter을 사용한다.

++counter;     // file_1에 정의한 counter을 증가시킨다.

다른 변수와 달리(다른 방법을 사용하지 않고) const 변수를 전역 사용 범위에 선언하면 객체를 정의한 파일에 지역적이 된다.  그 변수는 해당 파일에만 존재하며, 다른 파일에서는 접근할 수 없다.

반면에 extern을 사용하면 프로그램 전체에서 const 객체에 접근할 수 있다.

// file_1.cc

// 다른 파일에서 접근할 const 변수를 정의하고 초기화한다.

extern const int bufSize = fcn();

// file_2.cc

extern const int bufSize;     // file_1의 bufSize를 사용한다.

// file_1에 정의한 bufSize를 사용한다.

for(int index = 0; index != bufSize; ++index)

.....