watch port? - C# Discussion Boards

27-Jun-02 1:44

I have tried three method:
public class Factory
{
public Factory()
{
//
// TODO: Add constructor logic here
//
}
public DataInfo CreateDataInfo1( DataInfo di )
{
if( di == null )
{
di = new DataInfo();
di.DataName = "Factory create";
return di;
}
return di;
}

public DataInfo CreateDataInfo2()
{

DataInfo di = new DataInfo();
di.DataName = "Factory create";
return di;
}

public DataInfo CreateDataInfo3()
{
return new DataInfo("Factory create");
}
}

All of them can work!
But I think 2nd and 3rd cannot work because the object will be reclaimed, i'm right?

Annex:
DataInfo class:

public class DataInfo
{
public DataInfo()
{
//
// TODO: Add constructor logic here
//
}
public DataInfo(string name)
{
//
// TODO: Add constructor logic here
//
this.dataName = name;
}

private string dataName;

public string DataName
{
get
{
return this.dataName;
}
set
{
this.dataName = value;
}
}
}

Demo:

public static void Main()
{
DataInfo di = null;

Factory f = new Factory();

di = f.CreateDataInfo1(di);
if( null!= di )
Console.WriteLine( di.DataName );

di = null;
di = f.CreateDataInfo2();
if( null!= di )
Console.WriteLine( di.DataName );

di = null;
di = f.CreateDataInfo3();
if( null!= di )
Console.WriteLine( di.DataName );
}

Thank you for your help! Smile | :)

I'm amumu, and you?

Marc Clifton27-Jun-02 2:01

Marc Clifton

27-Jun-02 2:01

My (very new) understanding of C# is this:

In CreateDataInfo2 you are instantiating the object DataInfo() and assigning a reference to it in the local DataInfo di. Therefore the reference count to this object is one. Whe you are return the reference and assign it to another DataInfo object in Main(), the reference count goes to two. Now, the local variable in CreateDataInfo2 goes out of scope, and the reference count to the di created in that method goes back to one. So the count of objects referencing the DataInfo is still one, and therefore the object is not released.

The same applies to CreateDataInfo3, except is a simpler case.

Is this right, anyone?

Marc

Feng Qin27-Jun-02 3:05

27-Jun-02 3:05

I think you are right, thank you very much! Rose | [Rose]

I'm amumu, and you?

James T. Johnson27-Jun-02 16:05

27-Jun-02 16:05

No, no, no, no, no, no! :P

There is no such thing as a reference count in .NET (aside from COM Interop anyway). I highly suggest reading the Garbage Collection article in the .NET section of this website, I learned a lot by reading it.

James
"Java is free - and worth every penny." - Christian Graus

Marc Clifton27-Jun-02 16:22

Marc Clifton

27-Jun-02 16:22

I did read it. It seemed to me that it talked a lot about keeping track of memory references, etc. I learned a lot too, reading it.

OK, could you be a little less obtuse and tell me why I'm wrong?

Thanks,
Marc

James T. Johnson27-Jun-02 16:42

27-Jun-02 16:42

You mention that it keeps a reference count, perhaps I shouldn't point this out as being wrong; but more of the mind set it puts you in with throwbacks to COM and VB style deterministic finalization.

Now the count isn't what is important; it is whether or not any reachable reference exists. If the count was important there would be problems with circular references.

That is why I flagged it as being incorrect Smile | :)

James
"Java is free - and worth every penny." - Christian Graus

Marc Clifton28-Jun-02 0:37

Marc Clifton

28-Jun-02 0:37

Ah. A subtle difference.

I wonder what the actual implementation looks like. In the article on garbage collection, Chris wrote:

"...It then lists all your application's global and static memory pointers, local or parameter variables and CPU registers containing references to objects on the heap, and then uses these objects to build a graph of all objects on the heap that are either directly or indirectly referenced by your application. Any object on the managed heap that can somehow be accessed by your application will be marked. There are optimisations in place to remove the possibility of circular memory references causing infinite loops, and to ensure that chains of references are only processed once.

The GC then compacts the heap by moving non-garbage items together...In doing so the GC is also responsible for updating the values of all pointers into the heap, so that references to objects on the heap that have been moved are still valid."
(Sorry for the long quote).

The interesting thing here is that the GC has to go back and "fix up" all references to non-garbage items. So it must maintain a list of fix-ups, which means that a count should be easily obtainable. It has to iterate through a list somehow.

Anybody have source code to the GC?

Marc

James T. Johnson28-Jun-02 11:50

28-Jun-02 11:50

Marc Clifton wrote:
Anybody have source code to the GC?

I have the source to a GC, but I don't think its the same implementation that MS used. Its included with the Rotor project's source code.

James
"Java is free - and worth every penny." - Christian Graus

Feng Qin27-Jun-02 16:45

27-Jun-02 16:45

I'v read the msdn about garbage collection, it doesn't tell us what way microsoft use to keep reference information of the object if the object hasn't a Finalize method.
Am I right? Confused | :confused:

I'm amumu, and you?

James T. Johnson27-Jun-02 17:18

27-Jun-02 17:18

Logic would dictate that it should work similarly; but there isn't as much overhead involved with a class that doesn't have a finalizer. My guess is that it still keeps track of what is reachable; but when it performs the garbage collection it will free up the memory then instead of placing it in a queue to be dealt with by a finalizer thread.

Only a guess though Unsure | :~

James
"Java is free - and worth every penny." - Christian Graus

Feng Qin27-Jun-02 18:33

27-Jun-02 18:33

Forget it. Smile | :)

Now one thing we can be sure that Method 2nd and 3rd are all make another reference to the object created in CreateXXX, right? Roll eyes | :rolleyes:

I'm amumu, and you?

James T. Johnson27-Jun-02 18:41

27-Jun-02 18:41

Actually you won't need to make a reference in the 2nd and 3rd methods because of the way it works underneath it all. When you go to return the value a reference to it is placed on the stack; so there is still a reference to the value.

Now when the reference is assigned to the variable it is popped off the stack and you now have the reference stored in another place.

If that makes any sense to you; I'm having a hard time coming up with clear thoughts on it myself.

James
"Java is free - and worth every penny." - Christian Graus

Feng Qin27-Jun-02 19:06