궁금증, 그 뒷 이야기.

우선 이 궁금증에 대한 자세한 글은 아래에 써놓기는 했지만, 그래도 링크!

그리고, 이야기를 써내려가기에 앞서, 민영신께서 도움 말씀을 전하시니,
성스런 크리스마스 이브거늘
컴퓨터랑 씨름하고 있다니 :)

일단 해당하는 문제는, machine 혹은 compiler 에 relate한 문제가 될텐데 각설하고 일반저긴 이야기를 하자면.

일반적으로 로컬 변수가 그 스코프를 벗어나게 되면 값이 사라진다는것은(=의미를 잃어버린다는것)은 로컬 스코프들이 자신이 CPU타임을 소유했을때 사용하는 공간이 같기 떄문인데(Stack).... 어지럽지?-_-;

간단히 말하자면, 실제로 같은 영역(=공간)을 쓰기 때문에 같다
라고 밖에 말해줄수가 없겠네. 메모리 아키텍쳐를 이해하려면 필수적으로 컴파일러와 링커를 이해해야 하고 그러자면 필수적으로 O/S 와 어셈블리 지식이 붙어야 하고... 갈길이 멀지?

실지로 곰곰히 생각해 보면 저러한것이 합리적이란것도 생각해 볼수 있게 되는데, 만약 계속 사용하는 공간이 달라진다면, 저러한 함수를 정말 엄청 호출해 댄다면, 쓸수 있는 공간이 동나 버리겠지. 그래서 실제로, resursive-function 같은경운 지나친 호출의 경우엔 문제가 되기도해. 스택이 동나버리거든.

이래저래 더 헷갈리게 만들어 버린것 같지만-_-; 지금은 그냥 그래서 그런가보다 할수 밖에 없단 소리. 그래도 정 궁금하면 PE Format Document 나, ELF Format Document 와 링커 그리고 어셈블리, Memory Architecture(..스펠링 맞나--) 관련 문서를 보면 좀 도움이 될꺼야~

...아하하 이브에 뭐하는 짓이람. 배고프다orz


일단 이 문제는 어느 정도, machine, system, compiler에 의존적(dependent)인 것이라, 테스트를 했던 환경에 대해 적지 않을 수 없다.

아래의 '궁금증'에 대한 글을 남겼을 때의 system은, 대략 Ubuntu 5.10 Breezy Badger, Kernel 2.6.10, g++ 4.0의 환경이었고, 그 결과 각각의 function의 return값이 같은 메모리를 가리키고 있었다,라고 결론을 얻었으며, 내 나름대로의 결론은 다음과 같다.

밑에서 글로 쓰기는 했지만, 그렇고 그런 책을 요즘 보고 있는데, 이런 내용이 나왔거든 -_-a

뭐, 줄여서 얘기하자면, 각 fuction의 로컬변수들이 잡히는 Stack Frame들이 운이 좋게[?] 같은 메모리에 잡혔다가 풀렸다가 한다는 말로 이해하고 있삼;

지금 궁금한건, 각 function에서 return을 해주고 나면, compiler가 알아서 이미 잡혀있던 stack 부분을 free해줄텐데, 그럼 정확한 값이 나올 수 없는거 아니야?

뭐, 본문에 제대로 써놓지는 않았지만, 가장 궁금했던 부분은 그거였어. 어떻게 compiler에서 알아서 free해줬을 부분을 잡아서 값을 넘겨줬는지.


하지만, 아직도 풀리지 않은 문제.
방금 학교 서버인 medusa.hanyang.ac.kr에서 같은 코드를 가지고 실행해 보았더니, 다음과 같은 결과값을 내뱉었다. 참고로, medusa는 SunOS 5.8, g++ 3.3.2의 환경이다.
address of x in fv() : 0xffbefae4
v = fv() : 1
address of x in fp() : 0xffbefae4
*p = fp() : 135952
address of x in fr() : 0xffbefae4
r = fr() : 1


그리고, 추가로, Windows XP SP2의 환경에서, g++ 3.4.2를 포함하고 있는 Dev-c++를 통해서는 다음과 같은 결과값을 얻었다.
address of x in fv() : 0x22ff44
v = fv() : 1
address of x in fp() : 0x22ff44
*p = fp() : 2288608
address of x in fr() : 0x22ff44
r = fr() : 1


우리는 두번째 function인 fp에서 리턴해준 값을 주목할 필요가 있다. 이미 한번의 테스트에서 1이 나왔기 때문에, 역시 내가 의도한 값은 이전의 테스트와 같은 값인 1이었다. 하지만, function fp는 두 시스템에서 모두 전혀 엉뚱한 값을 가리키고 있다. 과연 system-dependent 이기 때문에, 이런 값을 가르키게 되는 것일까, 아니면 다른 이유가 있는 것일까.
  • tay at 2005.12.25 09:12

    저 *p의 값은 쓰레기 값이라고 생각함. 왜냐면, fp에서 p에다가 x의 주소를 리턴해줬는데, 이미 그 x는 fp가 종료되면서 free 되어 버렸으니까 cout << *p 하면 쓰레기값을 토하는거지;;

    그리고 주소값 다 같은거는 그냥 변수 선언해서 메모리 잡는건 Stack 방식으로 잡으니까 그런거라~라고 하면 간단한거 아닌가... 학교에서 Stack이랑 heep이랑 배웠지 않...나...?

  • 무릇밝음 at 2005.12.25 09:30

    Stack을 제대로 배우진 않았지..
    내 생각에 LIFO를 철저하게 지키고 있는거 같은데?
    heap의 메모리를 앞부분에서부터 사용한다면
    같은 자리를 잡아주고, 풀어주고,
    또 잡고 풀고 할 수 있지 않나?

    메모리도, 앞에서부터 차곡차곡 쓰는게 좋아보이지않아? 'ㅁ'
    [이후는 설계자들한테]

    • sy at 2005.12.27 01:55

      응. 확실히 LIFO의 원칙을 잘 지키는 거였어.
      다만, 우분투에서의 리턴값이 다른 시스템과 달라서;

  • kkung at 2005.12.26 12:14

    저 *p의 값은 쓰레기 값이 맞쌈.

    이유로는,

    int *fp()
    {
    int x = 1 <---- x가 스택에 위치
    ~~~
    return &x; <--- 요&#46468;까진 &x가 의미가 있으나..
    } <---- x소멸.

    아마도 저 코드는, vc에서 로컬변수의 주소를 리턴하고
    있다고 워닝 혹은 에러를 내뱉을 텐데,

    기본적으로 Scope룰에 의해 함수내 변수는 그 함수
    밖에서는 의미를 잃기 &#46468;문에, 굳이 값을 변환해야 한다면
    래퍼런스(=포인터) 가 아닌 값으로 반환해야 하는거지.

    그런 의미에서,

    #include <iostream>
    #define null 0
    using namespace std;
    class someClass
    {
    public:

    char *pArray;
    int m_ArraySize;

    someClass(int _Size)
    {
    m_ArraySize = _Size;
    pArray = new char[_Size];
    memset(pArray,null,_Size);
    }

    ~someClass()
    {
    if (pArray)
    delete [] pArray;
    }

    someClass operator+(const someClass& right)
    {
    someClass _Temp(right.m_ArraySize + this->m_ArraySize);
    strcpy(_Temp.pArray,this->pArray);
    strcat(_Temp.pArray,right.pArray);

    return _Temp;
    }
    const char* str() { return pArray; }
    };

    int main(void)
    {
    someClass a(256);
    strcpy(a.pArray,"abcdef");

    someClass b = someClass(256);
    strcpy(b.pArray,"ghijk");

    someClass c = a + b;
    cout << c.str();
    return 0;
    }

    위 코드는 vc에서 컴파일한것과 g++에서 컴파일한것의
    결과가 다르다
    ....

    뭐 그런거지-_-;;

    • sy at 2005.12.27 02:09

      응. 분명 warning이 뜨기는 했지.
      VC++은 너무 무거우서 지운 상태라, 테스트 불가능;

  • 飛정상 at 2005.12.26 12:45

    무슨 말씀 하시는거예요? +_+;;

  • HILL at 2005.12.26 22:07

    와아 처음보는거다 >_< (응?;)

댓글 남기기
◀ PREV 1···555657585960616263···71 NEXT ▶