繁体中文
设为首页
加入收藏
当前位置:程序开发首页 >> 其他开发语言 >> 8.4 Automatic memory management(cont')

8.4 Automatic memory management(cont')

2005-12-16 23:55:04  作者:masterall  来源:互联网  浏览次数:4  文字大小:【】【】【
简介:public void Push(object o) {first = new Node(o, first);}class Node{public Node Next;public object Value;public Node(object value): this(value, null) {}public Node(object value, Node next) {Next = ...

public void Push(object o) {

first = new Node(o, first);

}

class Node

{

public Node Next;

public object Value;

public Node(object value): this(value, null) {}

public Node(object value, Node next) {

Next = next;

Value = value;

}

}

}

shows a Stack class implemented as a linked list of Node instances. Node

instances are created in the Push

method and are garbage collected when no longer needed. A Node instance

becomes eligible for garbage

collection when it is no longer possible for any code to access it. For

instance, when an item is removed

from the Stack, the associated Node instance becomes eligible for garbage

collection.

The example

class Test

{

static void Main() {

Stack s = new Stack();

for (int i = 0; i < 10; i++)

s.Push(i);

s = null;

}

}

shows code that uses the Stack class. A Stack is created and initialized

with 10 elements, and then

assigned the value null. Once the variable s is assigned null, the Stack

and the associated 10 Node

instances become eligible for garbage collection. The garbage collector is

permitted to clean up immediately,

but is not required to do so.

The garbage collector underlying C# may work by moving objects around in

memory, but this motion is

invisible to most C# developers. For developers who are generally content

with automatic memory

management but sometimes need fine-grained control or that extra bit of

performance, C# provides the

ability to write .unsafe. code. Such code can deal directly with pointer

types and object addresses, however,

C# requires the programmer to fix objects to temporarily prevent the

garbage collector from moving them.

This .unsafe. code feature is in fact a .safe. feature from the perspective

of both developers and users.

Unsafe code must be clearly marked in the code with the modifier unsafe, so

developers can’t possibly use

unsafe language features accidentally, and the compiler and the execution

engine work together to ensure

that unsafe code cannot masquerade as safe code. These restrictions limit

the use of unsafe code to situations

in which the code is trusted.

The example

using System;

class Test

{

static void WriteLocations(byte[] arr) {

unsafe {

fixed (byte* pArray = arr) {

byte* pElem = pArray;

for (int i = 0; i < arr.Length; i++) {

byte value = *pElem;

Console.WriteLine("arr[{0}] at 0x{1:X} is {2}",

i, (uint)pElem, value);

pElem++;

}

}

}

}

static void Main() {

byte[] arr = new byte[] {1, 2, 3, 4, 5};

WriteLocations(arr);

}

}

shows an unsafe block in a method named WriteLocations that fixes an array

instance and uses pointer

manipulation to iterate over the elements. The index, value, and location

of each array element are written to

the console. One possible example of output is:

arr[0] at 0x8E0360 is 1

arr[1] at 0x8E0361 is 2

arr[2] at 0x8E0362 is 3

arr[3] at 0x8E0363 is 4

arr[4] at 0x8E0364 is 5

but, of course, the exact memory locations may be different in different

executions of the application.

责任编辑:admin
相关文章