이번 글도 역시 뉴스그룹에서 가져왔습니다. ((c.l.c.m:Returning local variable
그런데 이 질문을 올린 Minkoo Seo라는 이름을 보니 얼마전 댓글을 달아주신 서민구님이네요. :-)))
그런데 이 질문을 올린 Minkoo Seo라는 이름을 보니 얼마전 댓글을 달아주신 서민구님이네요. :-)))
Question
#include <iostream>
using namespace std;
const char *foo()
{
string f = "fo";
f += "o";
return f.c_str();
}
int main()
{
cout << foo() << endl; // I need const char * here!!!
return EXIT_SUCCESS;
}
질문은. - 위의 코드와 같이 local 변수를 const char*로 리턴하면 괜찮다고 하던데 정말인가요? (어디서 char*로 리턴하는건 안되지만 const char*로 리턴하는건 된다는 내용을 읽은 것 같아요.)
- 만약 안 괜찮다면 foo()함수는 어떻게 만들어야 할까요?
Answer
사실 이 질문들에 대한 답은 간단합니다.- 괜찮지 않습니다. local 변수인 string 객체는 이미 파괴되었기 때문에 cout 에서 그 포인터를 읽을 때는 이미 존재하지 않는 객체에 access하는 것이기 때문입니다.
- 간단히 리턴 타입을 string으로 바꿔주면 됩니다. 물론 리턴할때도 f.c_str() 대신에 그냥 f 를 리턴하면 되겠죠?
class Widget;
Widget getWidget();
void useWidge(Widge& w);
Widget w = getWidget() + getWidget(); // 1)
const Widget& w1 = getWidget(); // 2)
useWidget(w1); // 3)
먼저 1)번 라인의 두개의 getWidet()에서 리턴된 temporary 객체들의 수명은 그 라인이 끝날때까지뿐입니다. 1)번 라인을 pseudo code로 설명해보면 다음과 같습니다. Widget temp1 = getWidget();
Widget temp2 = getWidget();
Widget w = temp1 + temp2;
destroy temp2;
destroy temp1;
즉, 1)번 라인이 수행되고 나면 w에는 두개의 Widget을 더한 값이 정상적으로 들어있으나 각 getWidget()에서 리턴한 temporay 객체들은 모두 없어집니다. 그럼 2)번 라인은 어떨까요? 만약 1)번과 같은 규칙이 적용된다면 3)번 라인에서는 이미 없어진 temporary 객체에 대한 const reference로 함수를 호출하는 것이 되어 문제가 발생할것입니다. 하지만 이 경우에는 const reference가 이 temporary 객체의 수명을 w1 이름의 수명만큼으로 연장시켜줍니다. 따라서 이 temporary 객체의 수명은 라인의 끝을 벗어나 w1이 포함된 scope가 끝날때까지로 연장되며 따라서 3)번의 함수 호출은 정상적으로 이루어지게 됩니다. ((Cast to reference 이 관련 링크는 예전에 제가 만들었던 홈페이지입니다. 여기서 설명한 내용의 좀 더 자세한 내용을 보시려면 참고하세요. 그런데 인코딩이 utf-8이라 firefox에서 인코딩을 조정해주어야 보이더군요. 잊고 있다가 다시 보니 감회가 새롭군요. 그때에 비하면 지금은 블로깅 툴들이 있어서 글쓰기는 쉽네요. ;-))) 이러한 원리를 잘 사용하고 있는 것중의 하나가 바로 ScopeGuard 클래스죠.((원본 링크를 걸려고 했는데 원본 링크가 없어져 버렸네요. -_-;))
더 재밌는건.. const char*를 리턴하는 코드가 libstd++나 stlport기반에서는 동작 할거라는 생각이 문득...
ReplyDelete컨테이너들이 memory pooling을 하기 때문에 재수좋으면 작동 하지요..
요런 버그때문에 삽질을 많이 한다는.. -_-;
const char*로 리턴한다는 이야기는 아마도 c_str()의 리턴타입이 const char*이기 때문에 나온게 아닐까라는... ^_^
사실 문제가 된 코드도 대부분의 single-thread환경에서는 문제가 없으리라 생각됩니다. 굳이 delete한 char 배열에 다른 값을 채워넣을만큼 한가한 CPU는 없을테니까요.
ReplyDelete하지만 이게 단순히 const char*가 아니고 클래스 포인터라던지 multi-thread환경이라던지 하면 문제가 되겠지요.
저희도 가끔 문제가 발생해서 원인을 찾아보면 이런 문제가 있더라고요. 요샌 거의 다 찾았는지 잘 나진 않지만 multi-thread 환경에서도 CPU 로드가 적당할때는 안나다가 거의 노는 CPU가 없어질때쯤이면 다양한 문제들이 생기더군요. :-)
네!!!!!! 바로 그겁니다... 제가 정말 기억이 잘 안나지만 아마도 cout 로 출력하는것과 연관이 있었던거 같아요..
ReplyDelete아 정말 감사;;
2번 라인에 대해서 이해가 확실하지 않아서 질문하고싶은데요..
2번의 경우에는 const를 썼기 때문에, return Widget()이 있다면 임시 객체가 생성되어서
이것이 카피되는데 그 임시 객체가 바로 파괴가 안된다는 것이고, const는 생성된
임시 객체를 잠시 보존해준다는 것이라구 이해했고요..
c_str()을 반환할때는 이미 있는 객체를 반환하는 것이므로 그것이 파괴되는 것을
막을 수 없는것.. 맞는지요?
[...] http://ideathinking.com/blog/?p=51 [...]
ReplyDelete먼저 c_str()을 받는 경우 수명에 대해 생각해야 할 값은 const char* 그 자체입니다. 이 포인터 값을 변수에 저장하면 그 값의 수명은 변수의 수명만큼이 됩니다. 하지만 그 포인터가 가리키는 객체의 수명은 리턴받는 입장에서는 제어하기 불가능하며 이 경우 함수의 로컬에 선언된 auto 변수(스택 변수)이므로 함수가 끝나는 순간 파괴됩니다. 따라서 이후 그 저장하고 있는 포인터의 값을 사용하면 존재하지 않는 객체에 접근하는 것이 되어 문제가 발생합니다.
ReplyDelete하지만 위의 2번 라인의 경우 수명에 대해 생각해야 할 것은 임시 객체가 되며 const reference에 임시 객체를 할당하는 경우 그 수명이 연장됩니다. 그리고 const 만으로는 수명에 아무 영향을 미칠 수 없죠. :-)