함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자.


유리수를 나타내는 클래스가 있고 이 클래스에는

두 유리수를 곱하는 멤버 함수가 선언되어 있다.


Rational {

private:

int n ,d;

public:

Rational(int _n, int _d);

...

const Rational operator*(const Rational& lhs, const Rational& rhs);

};




Rational operator*(..); 위 함수에서는

참조자가 아닌 객체를 반환하고 있다.

이 함수가 참조자를 반환하도록 만들어졌다면,

이 함수가 반환하는 참조자는 반드시 이미 존재하는

Rational 객체의 참조자여야 한다.


참조자를 반환한다면 객체의 생성과 소멸에 드는

비용을 조금이라도 줄여지지 않을까?

그렇다면 참조자를 반환해보자.


const Rational& operator*(const Rational& lhs, const Rational& rhs){

Rational result (lhs.n * hrs.n, lhs.d * rhs.d );

return result;

}




참조자를 반환하려면 그 객체가 존재해야 한다고 말했다.

따라서 어차피 함수 안에서 객체가 하나 만들어진다.

즉, 객체의 생성과 소멸에 드는 비용을 지불한다는 말이다.


이보다 더 큰 문제는 result는 지역 객체이다.

함수가 끝나면 이 객체는 소멸된다.

따라서 이 함수는 소멸된 객체의 참조자를

리턴하고 있는 것이다. 이 참조자가

가리키고 있는 놈은 존재하지 않는다.




그렇다면 스택이 아닌 힙에 생성하고 참조자를 반환하면 어떤가?

const Rational& operator*(const Rational% lhs, const Rational& rhs){

Rational *result = new Rational (lhs.n * hrs.n, lhs.d * rhs.d);

return *result;

}


여전히 생성자가 호출되어야한다.

그리고 new로 할당한 메모리를 누가 해제를 해주는가?

operator* 로부터 반환되는 참조자 뒤에 숨겨진

포인터에 대해서는 사용자가 어떻게 접근할 방법이 없다.

즉, 자원누출이 심각한 코드가 된다.




스택에 할당하든 힙에 할당하든 생성자를 한번은 호출한다.

그렇다면 정적 객체로 함수 안에 정의해 놓고 참조자를 반환해보자.

const Rational& operator*(const Rational% lhs, const Rational& rhs){

static Rational result;

result = ...;

return result;

}




operator==가 선언되었고 a,b,c,d 모두 Rational 객체

if((a*b) == (c*d)); 

위의 표현식은 항상 값이 true이다.


왜? operator*은 정적 객체의 참조자를 반환한다.

둘의 값이 같지 않을 수가 없다.


이쯤되면 정적 배열을 써보는 것은 어떨까?

함수가 불릴 때마다 다른 객체를 반환해야 하기 때문에

n번의 호출이 있다면 n개의 배열이 있어야 한다.

비록 한번이지만 생성자가 n번 호출되고 소멸자가 n번 호출된다.

그리고 객체에 값을 어떻게 넣을 것인가?




그냥 새로운 객체를 반환하도록 하자!

inline const Rational operator*(const Rational& lhs, const Rational& rhs){

Rational result (lhs.n * hrs.n, lhs.d * rhs.d );

return result;

}




이 코드에도 반환 값을 생성하고 소멸시키는 비용이 들지만

올바른 동작에 지불되는 작은 비용이다. 또한 몇몇 조건하에서는

최적화 메커니즘에 의해 operator*의 반환 값에 대한 생성과

소멸 동작이 안전하게 제거 될 수 있다. (반환 값 최적화 : RVO)


POINT!!

값에 의한 반환이 최선이라면 그냥 그렇게 하자.

그리디 알고리즘 06 공주님의 정원


처음으로 한방에 성공~





01 클래스 선언




02 초기화



03 정렬




04 재귀함수 호출 그리고 답 출력




05 메인 함수




이제 백트래킹으로 넘어가 봅시다~

값에 의한 전달 보다는 상수객체 참조자에 의한 전달 방식을

택하는 편이 대개 낫다.


기본적으로 C++는 함수로부터 객체를 전달받거나

함수에 객체를 전달할 때 값에 의한 전달 방식을 사용한다.

실제 인자의 사본을 통해 초기화 되며 그 함수가 반환한

값 또한 사본을 돌려받는다. 이는 복사생성자에 의해 수행되며

때에 따라서는 고비용 연산이 되기도 한다.


class AAA{             --> Base 클래스

private:

string name;

string address;

public:

AAA();

virtual ~AAA();

}


class BBB : public AAA {  --> Drived 클래스

private:

stirng bName;

stirng bAddress;

...

}


bool validate(BBB b); --> BBB값으로 전달 받는 함수


BBB bbb;

bool check = validate(bbb);




bbb로부터 매개변수 b를 초기화 시키기 위해

1. BBB는 Drieved 클래스이기 때문에 Base 

   먼저 생성 되어야 한다. AAA의 복사생성자 호출

2. AAA 클래스 안의 stiring 생성자 호출.

3. string이 두개이기 때문에 또 생성자 호출.

4. BBB의 복사생성자 호출

5. BBB객체의 string 생성자 호출

6. string이 두개이기 때문에 또 생성자 호출.


7. BBB의 소멸자 호출

8. string 소멸자 호출

9. stirng 소멸자 호출

10. AAA의 소멸자 호출

11. string 소멸자 호출

12. stirng 소멸자 호출




상당히 고비용이다. 따라서 우리는

상수객체에 대한 참조자로 전달하게 만들자.


bool validate(const BBB& b);


새로 만들어지는 객체는 없기 때문에

생성자와 소멸자가 전혀 호출되지 않는다.

값을 전달 받는 validate함수는 전달되는 BBB에 

어떠한 변화가 생겨도 그 변화로부터 안전하게

보호를 받는다. (사본이 넘겨지기 때문에)

이번에는 참조에 의한 전달 방식을 사용했기 때문에

원본을 그 변화로 부터 지켜줘야 한다. --> const




또한 참조에 의한 전달 방식은 복사손실 문제도 해결해준다. 

복사 손실이란?

Drived 클래스 객체가 Base 클래스 객체로서

전달되는 경우가 있다. (함수의 매개변수로 넘길 때)

이 때 객체가 값으로 전달되면 Base 클래스의

복사 생성자만이 호출되고, Drived 클래스의

특징은 잘려나가게 되는데 이를 복사 손실이라 한다.


class AAA{   --> Base 클래스

...

public:

string GetName() const;

virtual void show() const;

};


class BBB : public BBB{  --> Drived 클래스

...

public:

...

virtual void show() const;

};


void print(AAA a){  --> AAA값을 받는 함수

cout<<a.name;

a.show()

}


BBB b;

print(b);




위의 경우 값으로 전달되어 복사가 된다.

Drived클래스의 정보는 잘려나가게 된다.

따라서 print함수의 show()는 절대 BBB의 것이 될 수 없다.


void print(const AAA& a);

print(b);


상수 객체 참조자에 의한 전달 방식을 사용한다면

이러한 문제를 말끔하게 해결 할 수 있다.

참조자를 전달한다는 것은 결국 포인터를

전달한다는 것과 일맥상통하기 때문이다.




하지만 참조자에 의한 전달이 어떤 상황에서든

빛을 발하는 것은 아니다. 기본제공 타입의 경우에는

값으로 넘기는 편이 더 효율적일 때가 많다.

기본제공 타입 외에도 STL의 반복자, 함수객체도 마찬가지.

따라서 반복자와 함수 객체를 구현할 때는 반드시

1. 복사 효율을 높일 것과

2. 복사손실 문제에 노출되지 않도록

만드는 것이 필수이다.




기본제공 타입은 작다. 따라서 타입 크기만

작으면 모두 값에 의한 전달이 더 효율적인가?

--> 크기가 작아도 비용이 비쌀 수 있다.


만약 복사의 비용이 그렇게 비싸지 않더라 하더라도

컴파일러 중에는 기본제공 타입과 사용자 정의 타입을

아예 다르게 취급하는 것들이 있다. 기본제공 타입은

레지스터에 넣어주지만, 사용자 정의 타입 객체는

아무리 기본제공 타입과 비슷하더라도 넣어주지 않는다.

이러한 개발 환경이라면 참조에 의한 전달을 쓰는 것이 낫다.

포인터만큼은 확실하게 레지스터에 들어간다.




복사 비용이 싸더라도 값에의한 전달을 할 수 없는

또 하나의 이유는 사용자 정의 타입의 크기는 언제든

변화에 노출되어 있다는 것이다. 지금은 작더라도

유지보수를 거듭하게 되면 언제 커질지 모르는 것이다.


따라서 기본제공 타입, STL의 반복자, 함수객체 타입

위 세가지 말고는 그냥 상수객체 참조자에 의한 전달방식을 쓰자.




POINT!!

1. 값에 의한 전달 보다는 상수 객체 참조자에 의한 전달

2. 기본제공 타입, STL의 반복자, 함수객체 타입은 값에의한 전달



+ Recent posts