C ++의 스택, 정적 및 힙

C ++의 스택, 정적 및 힙

---

검색했지만이 세 가지 개념을 잘 이해하지 못했습니다. 힙에서 동적 할당을 언제 사용해야합니까? 그리고 실제 장점은 무엇입니까? 정적 및 스택의 문제점은 무엇입니까? 힙에 변수를 할당하지 않고 전체 응용 프로그램을 작성할 수 있습니까?

다른 언어에는 "가비지 수집기"가 내장되어 메모리에 대해 걱정할 필요가 없다고 들었습니다. 가비지 수집기는 무엇을합니까?

이 가비지 수집기를 사용하여 수행 할 수없는 메모리를 직접 조작 할 수 있습니까?

누군가가이 선언으로 저에게 말했습니다 :

int * asafe=new int;

"포인터에 대한 포인터"가 있습니다. 무슨 뜻이에요? 다음과 다릅니다.

asafe=new int;

?

---

비슷한 질문 이 있었지만 정적에 대해서는 묻지 않았습니다.

정적, 힙 및 스택 메모리의 요약 :

• 정적 변수는 전역 적으로 액세스 할 수없는 경우에도 기본적으로 전역 변수입니다. 일반적으로 실행 파일 자체에 주소가 있습니다. 전체 프로그램에 대해 하나의 사본 만 있습니다. 함수 호출 (또는 클래스) (및 스레드 수)에 몇 번이나 상관없이 변수는 동일한 메모리 위치를 참조합니다.

• 힙은 동적으로 사용할 수있는 메모리입니다. 객체에 4kb를 원하면 동적 할당자는 힙에서 사용 가능한 공간 목록을 살펴보고 4kb 청크를 선택하여 사용자에게 제공합니다. 일반적으로 동적 메모리 할당 자 (malloc, new 등)는 메모리의 끝에서 시작하여 뒤로 작동합니다.

• 스택이 어떻게 늘어나고 줄어드는 지 설명하는 것은이 답변의 범위를 벗어난 것이지만 항상 끝에서만 추가하고 제거한다고 말하면 충분합니다. 스택은 일반적으로 시작하여 더 낮은 주소로 증가합니다. 스택이 중간 어딘가에서 동적 할당자를 만나면 메모리가 부족합니다 (물리적 메모리와 가상 메모리 및 조각화 참조). 다중 스레드는 다중 스택을 필요로합니다 (프로세스는 일반적으로 스택의 최소 크기를 예약합니다).

각각을 사용하고 싶을 때 :

• 스태틱 / 글로벌은 항상 필요하고 할당을 취소하고 싶지 않은 메모리에 유용합니다. (이러한 방식으로, 임베디드 환경은 정적 메모리 만있는 것으로 생각할 수 있습니다. 스택 및 힙은 세 번째 메모리 유형 (프로그램 코드)이 공유하는 알려진 주소 공간의 일부입니다. 프로그램 코드는 종종 동적 할당을 수행합니다. 링크 된리스트와 같은 것들이 필요할 때 정적 메모리 그러나, 정적 메모리 자체 (버퍼) 자체는 "할당"되지 않고 오히려 다른 목적은이 목적을 위해 버퍼가 보유한 메모리에서 할당됩니다. 콘솔 게임은 내장 된 동적 메모리 메커니즘을 자주 회피하여 모든 할당에 대해 사전 설정된 크기의 버퍼를 사용하여 할당 프로세스를 엄격하게 제어하는 ​​데 유리합니다.)

• 스택 변수는 함수가 범위 내 (스택 어딘가)에있는 한 변수가 유지되기를 원할 때 유용합니다. 스택은 코드가있는 코드에 필요하지만 해당 코드 외부에서는 필요하지 않은 변수에 좋습니다. 또한 파일과 같은 리소스에 액세스 할 때 유용하며 해당 코드를 떠날 때 리소스가 자동으로 사라지기를 원합니다.

• 힙 할당 (동적 할당 메모리)은 위의 것보다 더 유연하게하고 싶을 때 유용합니다. 종종 이벤트에 응답하기 위해 함수가 호출됩니다 (사용자가 "상자 만들기"버튼을 클릭 함). 적절한 응답을 위해서는 함수가 종료 된 후 오래 지속되어야하는 새 개체 (새 Box 개체)를 할당해야하므로 스택에있을 수 없습니다. 그러나 프로그램을 시작할 때 얼마나 많은 상자를 원하는지 알 수 없으므로 정적 일 수 없습니다.

가비지 콜렉션

최근 가비지 콜렉터가 얼마나 훌륭한 지에 대해 많이 들었으므로 약간의 반대 의견이 도움이 될 것입니다.

가비지 콜렉션은 성능이 큰 문제가 아닐 때 훌륭한 메커니즘입니다. GC가 점점 더 정교 해지고 있다고 들었지만 사실 (사용 사례에 따라) 성능 저하를 감수해야 할 수도 있습니다. 게 으르더라도 여전히 제대로 작동하지 않을 수 있습니다. 가비지 콜렉터는 최상의 경우 참조가 더 이상 없다는 것을 알게되면 메모리가 사라진다는 것을 알게됩니다 ( 참조 횟수 계산 참조)). 그러나 자신을 참조하는 오브젝트가있는 경우 (아마도 다른 오브젝트를 참조하여 참조하는 경우) 참조 횟수만으로는 메모리를 삭제할 수 있음을 나타내지 않습니다. 이 경우 GC는 전체 참조 수프를보고 자신 만 참조하는 섬이 있는지 확인해야합니다. 오프 핸드, 나는 O (n ^ 2) 연산이라고 생각하지만, 그것이 무엇이든간에 성능에 관심이 있다면 나빠질 수 있습니다. (편집 : Martin B 는 합리적으로 효율적인 알고리즘의 경우 O (n)임을 지적 합니다. 성능에 관심이 있고 가비지 수집없이 일정한 시간에 할당을 취소 할 수 있으면 여전히 O (n)입니다.)

개인적으로 사람들이 C ++에 가비지 수집이 없다고 말하면 내 마음에 C ++의 기능으로 태그가 지정되지만 소수에 해당합니다. 아마도 사람들이 C와 C ++에서의 프로그래밍에 대해 배우기 가장 어려운 것은 포인터와 동적 메모리 할당을 올바르게 처리하는 방법 일 것입니다. 파이썬과 같은 다른 언어는 GC가 없으면 끔찍할 것이므로 언어에서 원하는 것에 달려 있다고 생각합니다. 신뢰할 수있는 성능을 원한다면 가비지 수집이없는 C ++이 Fortran의 유일한 측면입니다. 사용하기 쉽고 훈련 휠을 원한다면 ( "적절한"메모리 관리를 배우지 않고도 충돌을 피하기 위해) GC로 무언가를 선택하십시오. 메모리를 잘 관리하는 방법을 알고 있더라도 다른 코드를 최적화하는 데 시간을 절약 할 수 있습니다. 실제로 더 이상 성능 저하가 발생하지 않지만 신뢰할 수있는 성능 (및 커버 아래에서 진행 상황을 정확하게 알 수있는 기능)이 정말로 필요한 경우 C ++을 고수합니다. 내가 들어 본 모든 주요 게임 엔진이 C ++ (C 또는 어셈블리가 아닌 경우)에있는 이유가 있습니다. Python 등은 스크립팅에는 적합하지만 주요 게임 엔진에는 적합하지 않습니다.

---

다음은 물론 모든 것이 정확하지는 않습니다. 읽을 때 소금 한알과 함께 가져 가십시오. :)

글쎄, 당신이 말하는 세 가지 것은 자동, 정적 및 동적 저장 기간 이며, 이것은 객체의 수명과 수명이 시작되는 시간 과 관련이 있습니다.

---

자동 저장 기간

당신은 자동 저장 기간 사용 짧은 수명 과 작은 에만 필요 데이터를 로컬로 일부 블록 내를 :

if(some condition) {
    int a[3]; // array a has automatic storage duration
    fill_it(a);
    print_it(a);
}

수명은 블록을 종료하자마자 끝나고 객체가 정의 되 자마자 시작됩니다. 이들은 가장 간단한 종류의 스토리지 기간이며 특히 동적 스토리지 기간보다 훨씬 빠릅니다.

---

정적 저장 기간

You use static storage duration for free variables, which might be accessed by any code all times, if their scope allows such usage (namespace scope), and for local variables that need extend their lifetime across exit of their scope (local scope), and for member variables that need to be shared by all objects of their class (classs scope). Their lifetime depends on the scope they are in. They can have namespace scope and local scope and class scope. What is true about both of them is, once their life begins, lifetime ends at the end of the program. Here are two examples:

// static storage duration. in global namespace scope
string globalA; 
int main() {
    foo();
    foo();
}

void foo() {
    // static storage duration. in local scope
    static string localA;
    localA += "ab"
    cout << localA;
}

The program prints ababab, because localA is not destroyed upon exit of its block. You can say that objects that have local scope begin lifetime when control reaches their definition. For localA, it happens when the function's body is entered. For objects in namespace scope, lifetime begins at program startup. The same is true for static objects of class scope:

class A {
    static string classScopeA;
};

string A::classScopeA;

A a, b; &a.classScopeA == &b.classScopeA == &A::classScopeA;

As you see, classScopeA is not bound to particular objects of its class, but to the class itself. The address of all three names above is the same, and all denote the same object. There are special rule about when and how static objects are initialized, but let's not concern about that now. That's meant by the term static initialization order fiasco.

---

Dynamic storage duration

The last storage duration is dynamic. You use it if you want to have objects live on another isle, and you want to put pointers around that reference them. You also use them if your objects are big, and if you want to create arrays of size only known at runtime. Because of this flexibility, objects having dynamic storage duration are complicated and slow to manage. Objects having that dynamic duration begin lifetime when an appropriate new operator invocation happens:

int main() {
    // the object that s points to has dynamic storage 
    // duration
    string *s = new string;
    // pass a pointer pointing to the object around. 
    // the object itself isn't touched
    foo(s);
    delete s;
}

void foo(string *s) {
    cout << s->size();
}

Its lifetime ends only when you call delete for them. If you forget that, those objects never end lifetime. And class objects that define a user declared constructor won't have their destructors called. Objects having dynamic storage duration requires manual handling of their lifetime and associated memory resource. Libraries exist to ease use of them. Explicit garbage collection for particular objects can be established by using a smart pointer:

int main() {
    shared_ptr<string> s(new string);
    foo(s);
}

void foo(shared_ptr<string> s) {
    cout << s->size();
}

You don't have to care about calling delete: The shared ptr does it for you, if the last pointer that references the object goes out of scope. The shared ptr itself has automatic storage duration. So its lifetime is automatically managed, allowing it to check whether it should delete the pointed to dynamic object in its destructor. For shared_ptr reference, see boost documents: http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm

---

It's been said elaborately, just as "the short answer":

• static variable (class)
  lifetime = program runtime (1)
  visibility = determined by access modifiers (private/protected/public)

• static variable (global scope)
  lifetime = program runtime (1)
  visibility = the compilation unit it is instantiated in (2)

• heap variable
  lifetime = defined by you (new to delete)
  visibility = defined by you (whatever you assign the pointer to)

• stack variable
  visibility = from declaration until scope is exited
  lifetime = from declaration until declaring scope is exited

---

(1) more exactly: from initialization until deinitialization of the compilation unit (i.e. C / C++ file). Order of initialization of compilation units is not defined by the standard.

(2) Beware: if you instantiate a static variable in a header, each compilation unit gets its own copy.

---

I'm sure one of the pedants will come up with a better answer shortly, but the main difference is speed and size.

Stack

Dramatically faster to allocate. It is done in O(1) since it is allocated when setting up the stack frame so it is essentially free. The drawback is that if you run out of stack space you are boned. You can adjust the stack size, but IIRC you have ~2MB to play with. Also, as soon as you exit the function everything on the stack is cleared. So it can be problematic to refer to it later. (Pointers to stack allocated objects leads to bugs.)

Heap

Dramatically slower to allocate. But you have GB to play with, and point to.

Garbage Collector

The garbage collector is some code that runs in the background and frees memory. When you allocate memory on the heap it is very easy to forget to free it, which is known as a memory leak. Over time, the memory your application consumes grows and grows until it crashes. Having a garbage collector periodically free the memory you no longer need helps eliminate this class of bugs. Of course this comes at a price, as the garbage collector slows things down.

---

What are the problems of static and stack?

The problem with "static" allocation is that the allocation is made at compile-time: you can't use it to allocate some variable number of data, the number of which isn't known until run-time.

The problem with allocating on the "stack" is that the allocation is destroyed as soon as the subroutine which does the allocation returns.

I could write an entire application without allocate variables in the heap?

Perhaps but not a non-trivial, normal, big application (but so-called "embedded" programs might be written without the heap, using a subset of C++).

What garbage collector does ?

It keeps watching your data ("mark and sweep") to detect when your application is no longer referencing it. This is convenient for the application, because the application doesn't need to deallocate the data ... but the garbage collector might be computationally expensive.

Garbage collectors aren't a usual feature of C++ programming.

What could you do manipulating the memory by yourself that you couldn't do using this garbage collector?

Learn the C++ mechanisms for deterministic memory deallocation:

• 'static': never deallocated
• 'stack': as soon as the variable "goes out of scope"
• 'heap': when the pointer is deleted (explicitly deleted by the application, or implicitly deleted within some-or-other subroutine)

---

Stack memory allocation (function variables, local variables) can be problematic when your stack is too "deep" and you overflow the memory available to stack allocations. The heap is for objects that need to be accessed from multiple threads or throughout the program lifecycle. You can write an entire program without using the heap.

You can leak memory quite easily without a garbage collector, but you can also dictate when objects and memory is freed. I have run in to issues with Java when it runs the GC and I have a real time process, because the GC is an exclusive thread (nothing else can run). So if performance is critical and you can guarantee there are no leaked objects, not using a GC is very helpful. Otherwise it just makes you hate life when your application consumes memory and you have to track down the source of a leak.

---

What if your program does not know upfront how much memory to allocate (hence you cannot use stack variables). Say linked lists, the lists can grow without knowing upfront what is its size. So allocating on a heap makes sense for a linked list when you are not aware of how many elements would be inserted into it.

---

An advantage of GC in some situations is an annoyance in others; reliance on GC encourages not thinking much about it. In theory, waits until 'idle' period or until it absolutely must, when it will steal bandwidth and cause response latency in your app.

But you don't have to 'not think about it.' Just as with everything else in multithreaded apps, when you can yield, you can yield. So for example, in .Net, it is possible to request a GC; by doing this, instead of less frequent longer running GC, you can have more frequent shorter running GC, and spread out the latency associated with this overhead.

But this defeats the primary attraction of GC which appears to be "encouraged to not have to think much about it because it is auto-mat-ic."

If you were first exposed to programming before GC became prevalent and were comfortable with malloc/free and new/delete, then it might even be the case that you find GC a little annoying and/or are distrustful(as one might be distrustful of 'optimization,' which has had a checkered history.) Many apps tolerate random latency. But for apps that don't, where random latency is less acceptable, a common reaction is to eschew GC environments and move in the direction of purely unmanaged code (or god forbid, a long dying art, assembly language.)

I had a summer student here a while back, an intern, smart kid, who was weaned on GC; he was so adament about the superiorty of GC that even when programming in unmanaged C/C++ he refused to follow the malloc/free new/delete model because, quote, "you shouldn't have to do this in a modern programming language." And you know? For tiny, short running apps, you can indeed get away with that, but not for long running performant apps.

---

Stack is a memory allocated by the compiler, when ever we compiles the program, in default compiler allocates some memory from OS ( we can change the settings from compiler settings in your IDE) and OS is the one which give you the memory, its depends on many available memory on the system and many other things, and coming to stack memory is allocate when we declare a variable they copy(ref as formals) those variables are pushed on to stack they follow some naming conventions by default its CDECL in Visual studios ex: infix notation: c=a+b; the stack pushing is done right to left PUSHING, b to stack, operator, a to stack and result of those i,e c to stack. In pre fix notation: =+cab Here all the variables are pushed to stack 1st (right to left)and then the operation are made. This memory allocated by compiler is fixed. So lets assume 1MB of memory is allocated to our application, lets say variables used 700kb of memory(all the local variables are pushed to stack unless they are dynamically allocated) so remaining 324kb memory is allocated to heap. And this stack has less life time, when the scope of the function ends these stacks gets cleared.

참고URL : https://stackoverflow.com/questions/408670/stack-static-and-heap-in-c