Lifetime and scope in C ++

What is the relationship between survival and scope?

Let's explain the lifetime first.
The memory space corresponding to a process contains five different data zones.
Stack, heap, BSS segment, data segment, and code segment are arranged in the ascending order of memory.
STACK: stores local objects temporarily created by the program. Generally, the executable file generated by VC ++ 6.0 is only 1 MIB of stacks.
Heap: stores the memory segments dynamically allocated during process running. It is not fixed in size and can be dynamically expanded or reduced. It is the most memory resource.
BSS segment: (it is short for block started by symbol) If no global object is initialized in the stored program, the operating system will automatically set all BSS segments to zero.
Data Segment: stores initialized global and static objects.
Code segment: The operation command for storing executable files to execute the image of the program in the memory. The code segment must be read-only because it cannot be modified during runtime.
It can be seen that only the code segment is protected by the operating system as read-only, and constants in other places are only protected by the compiler.
Of course, there are many areas in the memory that do not belong to the data zone. They cannot be read or written.
The data in the stack has a lifetime {};
The life cycle of the data in the heap is before it is released by free or delete.
For other data, the lifetime is before the end of the process.
User-Defined variables or constants are not modified during the lifetime unless they are modified by themselves or by external factors.

The scope is the region where the variable or constant can be used explicitly.
Note: This is just my own definition. In this way, the data in the heap should have no scope, because it cannot be directly displayed and used (through pointers or references ).
Except for the local static variables whose scope is {}, other static variables have the same lifetime.

The following is a simple test, which is messy. If you cannot see it, you can just draw a conclusion.

 

 

// File name: life_test.cpp
// Author: keakon
// Create Date: 2006/5/26
// Last edited Date: 2006/5/27
// Test the lifetime and scope of various objects
// Compiled and run in VC ++ 6.0
/////////////////////////////////////////
# Include <iostream>
# Include <string>

Using STD: cout;
Using STD: string;
/////////////////////////////////////////
Class
{
Public:
A (string const & name): m_name (name) {cout <m_name <". A: A ()/n ";}
~ A () {cout <m_name <". ::~ A ()/n ";}
String const & getname () const {return m_name ;}
PRIVATE:
String m_name;
};
/////////////////////////////////////////
A g ("G ");
Const A g_c ("g_c ");
Static A G_s ("G_s ");
Const static A g_c_s ("g_c_s ");

Const int num = 10; // store the size of the pointer Array
/////////////////////////////////////////
Void print (a const * P [])
{
Cout <"/n ";
For (INT I = 0; I <num; ++ I)
{
Cout <p [I]-> getname () <":/t" <p [I] <'/N ';
}
Cout <"/n ";
}
/////////////////////////////////////////
Void printname (a const * P [])
{
Cout <"/n ";
For (INT I = 0; I <num; ++ I)
{
# Ifndef ndebug
// If ndebug is not defined, skip 4, 5, 8, and 9 because the object has been destructed.
// Ndebug is a system macro of VC ++ 6.0. It is not defined in debug mode and is defined in release mode.
// In release mode, the names of objects 4, 5, 8, and 9 become garbled characters.
// If this macro is canceled, an error occurs in debug mode.
// This is related to the way in which the two modes process variables that have left the lifetime.
// PS: If this macro is canceled, several screen garbled characters may be displayed in G ++ ^
If (I = 4 | I = 5 | I = 8 | I = 9)
{
Continue; // enter the next For Loop
}
# Endif
Cout <p [I]-> getname () <":/t" <p [I] <'/N ';
}
Cout <"/n ";
}
/////////////////////////////////////////
Void assign (a const * P [])
{
A l ("L ");
Const A l_c ("l_c ");
Static A l_s ("l_s ");
Const static A l_c_s ("l_c_s ");
Register a R ("R ");

P [0] = & G;
P [1] = & g_c;
P [2] = & G_s;
P [3] = & g_c_s;
P [4] = & L;
P [5] = & l_c;
P [6] = & l_s;
P [7] = & l_c_s;
P [8] = new A ("l_h"); // leave it to your own character if it fails to be checked.
P [9] = & R;

Print (P );

Delete P [8];
}
/////////////////////////////////////////
Namespace Test
{
Const string STR ("keakon is handsome guy =. = ");

Const string & getstr ()
{
Return STR;
}

Void printstr ()
{
Cout <STR <"/n ";
}
}
/////////////////////////////////////////
Int main ()
{
A const * P [num] = {null}; // The full value is null.

Assign (P );
Printname (P );

Assign (P );
Printname (P );

String const & Pi = test: getstr (); // you can also use a pointer, but the reference is more intuitive.
Const_cast <string &> (PI) = "keakon is beauty ^ V"; // constant changed, Khan =. =
Test: printstr (); // output "keakon is beautiful ^ V"

Return 0;
}

/*
Note:
1. When naming, G table global, l table local, C table constant, s table static, H table heap, r table register
2. The following conclusions use "object" to represent variables or constants, because I can't think of any good words to represent them.
3. The following conclusions are valid only in VC ++ 6.0.

Conclusion:
1. Global Objects have static attributes (addresses and static objects are put together)
2. The register object has the auto attribute (the address and the auto object are put together) // The book on which you forgot to see it. It seems that you cannot get the address of the register object.
3. Partial non-static objects (including constant objects, register objects, and heap objects) are random after they are out of scope.
4. After the static object is out of scope (before the end of the program), it can still be accessed normally and the content remains unchanged.
5. The object in another namespace meets the above conclusion (only global objects are tested here)
6. When a global or static object is destructed, the compiler may have destructed other non-static objects (such as cout), so information may not be output.
In fact, if a global or static object has non-static members, the members of the Global or static object will be destructed before its analysis.
*/