|
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
|
|
|
|
|
I think you are right, thank you very much!![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
I'm amumu, and you?
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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 
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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?
I'm amumu, and you?
|
|
|
|
|
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 
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Forget it.
Now one thing we can be sure that Method 2nd and 3rd are all make another reference to the object created in CreateXXX, right?
I'm amumu, and you?
|
|
|
|
|
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
|
|
|
|
|
It sounds reasonable.
Do you have a msn messager account?
I want to add you, can I?
I'm amumu, and you?
|
|
|
|
|
I have one; but I prefer to use Sonork because of its features.
Sonork: 100.11138
MSN: edgecb@hotmail.com
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Seriously? Traditionally, values have been passed back in the EAX/EDX registers (386 and on processors). (The mechanism for returning floats, structs by value, etc, is different). You can't push the return value on the stack and then do a return, because the address will be wrong (unless there's some funky RET instruction???) So you'd have to pre-allocate space on the stack for the return value and put it there. Is this what it's doing? Even for "simple" types (ints, bools, chars, pointers, etc)?
(Admittedly, I haven't looked at the generated assembly).
Marc
|
|
|
|
|
I don't know how the generated assembly works; I was going by what I know of IL and stack based machines.
Actually I might have confused that with what little Sparc assembly I know and now that I think about it it was registers and not the stack the way it stored the registers on a function call was treated like a stack though; where X registers were used (z0 - zX-1), and the z0 register was where you placed the return value then when the function returned that became the zX-1 register
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Ok, perhaps I wasn't entirely wrong in my thinking of how the IL worked. Here is the accessor for the Count property of an ArrayList.
.method public hidebysig newslot specialname virtual
instance int32 get_Count() cil managed
{
.maxstack 8
IL_0000: ldarg.0
IL_0001: ldfld int32 System.Collections.ArrayList::_size
IL_0006: ret
} Notice that it loads a field onto the stack then returns. It looks that since it knows the return type, enough space will be left on the stack for it to be placed on there so it may be used by the calling method.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Very interesting. Notice though the actual assembly code generated:
00000000 push ebp ; save EBP
00000001 mov ebp,esp ; save ESP
00000003 push eax ; allocates 8 bytes on stack
00000004 push esi ; save ESI
00000005 mov esi,ecx ; get object reference
00000007 mov eax,dword ptr [esi+8] ; get count
0000000a pop esi ; restore ESI
0000000b mov esp,ebp ; restore ESP ***
0000000d pop ebp ; restore EBP
0000000e ret ; return
The value is returned in EAX. I added the comments. The line I designated with *** is interesting, in that it restores the ESP to the state prior to the push eax/push esi. In this code example, the 8 bytes allocated by push eax are actually never used, but forced into creation I suspect by the .maxstack directive.
The IDL (is that the right acronym) uses the stack after saving the ESP for local values (this is the way things are usually done), and then throws away all the local stuff at the end by "mov esp, ebp". In the above case, the optimizer figured out that the stack space allocated didn't need to be used--the return value could just be placed into the EAX register. Unfortunately, it still allocated the space, so a few cycles were wasted.
It would be interesting to see how a struct is returned. I remember looking at assembly code in the past, and something about a memcpy being called.
So, the IDL (I really hope this is the right acronym) abstracts the resulting assembly so you could port it to other processors. What bothers me about the above IDL is that it obscures the return value. There must be some assumptions about what is getting returned, since it clearly wasn't specified in the IDL code. Any ideas?
Marc
|
|
|
|
|
I'm a freshman and not familiar with IL, but I add a finalize method to DataInfo, the print info will indicates the CLI doesn't destroy the object when return the reference.
Does it mean: In C#, the ojbect's lifetime is determined by how many reference it has, instead of the code field scope just like C++?
I'm amumu, and you?
|
|
|
|
|
Your question is sort of faulty. Objects are treated as pointers, which are values that reference the object. The pointer's lifetime is only the scope of the function, but the object's lifetime is based on whether it's still being referenced.
Consider:
C#:
class Foo...
void MyFunction()
{
Foo bar=new Foo();
...
}
The object "Foo" will be cleaned up by the garbage collector later.
C++:
class Foo...
void MyFunction()
{
Foo* bar=new Foo;
...
}
In C++, you are responsible for deleting the object Foo.
However (this is conceptual code, I haven't actually tested the usage of ArrayList):
C#:
void MyFunction(ArrayList array)
{
Foo* bar=new Foo;
array.Add(bar);
}
Now the object "Foo" is not cleaned up by the garbage collector because a reference still exists in the ArrayList, which has a lifetime outside of the scope of MyFunction.
I really wish that instead of garbage collectors, new, delete, Finalize, Dispose, and all this other crap, that someone would implement the ability to explicitly define object lifetime. And why don't we have an implementation that also frees up resources that an object uses? Yes, I know that resources are in the "unmanaged" side of the fence, but you'd think that with all the brain and manpower at Redmond, they could have solved this problem also. Resource leaks seem to be more of a problem to me than memory leaks anyways.
Personally, I find all this behind the scenes stuff disturbing. I know I can "ignore" performing C++ delete's, but now I have to change my thinking to: does the object use resources which requires me explicitly calling "Dispose", which means I need to override either the Dispose or Finalize "destructors"?
Marc
|
|
|
|
|
Welcome,
I hava a project called for example myApp
I defined configuration file myApp.config as below
<configuration>
<globalization requestencoding="utf-8" responseencoding="utf-8">
<appsettings>
<add
="" key="SqlConnection1.ConnectionString" value="data source=localhost;initial catalog=projects;integrated security=SSPI;">
Construction myApp looks like
...
System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader();
try
{
strConn = ((string)(configurationAppSettings.GetValue("SqlConnection1.ConnectionString", typeof(string))));
}
catch(Exception e)
{
MessageBox.Show(e.Message);
}
...
And exception occured
A key SqlConnection1.ConnectionString in the appSettings configuration section.
Do you have any idea what is wrong (I added config file manualy... is it neccasary to set extra references to it) (of course it is added to project)
Tomiga
|
|
|
|
|
oppss of course it was xml file.. (it doesn't look like in previous post)
Tomiga
|
|
|
|
|
You shouldn't need to create an AppSettingsReader for the configuration file. There is an AppSettings property in the ConfigurationSettings class which is a NameValueCollection, this collection contains all of the keys in the appSettings node of the XML file.
Try that and see if it helps.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Thx
Problem was solved. (I had to change a name of config file).
Tomiga
|
|
|
|
|
Ok, I have been messing around with C# lately and am trying to use one of the controls I found here (Carlos's Outlookbar control). I am running into problems using his resX files in my app for some reason. I keep getting the following error when I try to run:
An unhandled exception of type 'System.Resources.MissingManifestResourceException' occurred in mscorlib.dll
Additional information: Could not find any resources appropriate for the specified culture (or the neutral culture) in the given assembly. Make sure "IconImages.resources" was correctly embedded or linked into assembly "csharp_OLApp".
baseName: IconImages locationInfo: <null> resource file name: IconImages.resources assembly: csharp_OLApp, Version=1.0.907.40862, Culture=neutral, PublicKeyToken=null
Now here are the particulars:
My app's namespace: csharp_OLApp
Old app's namespace: Demo
resX filename: IconImages.resX
Code @ the exception:
Bitmap icons = (Bitmap)rmListImages.GetObject("ListIcons");
Code that loads the resource in my app:
Assembly thisAssembly = Assembly.GetAssembly(Type.GetType("csharp_OLApp.Form1"));
rmListImages = new ResourceManager("IconImages", thisAssembly);
rmBitmaps = new ResourceManager("Menus", thisAssembly);
Code that loads the resource in the old app:
Assembly thisAssembly = Assembly.GetAssembly(Type.GetType("Demo.Form1"));
rmListImages = new ResourceManager("IconImages", thisAssembly);
rmBitmaps = new ResourceManager("Menus", thisAssembly);
Now, I have tried everytrick in the book here to try to get this to work. I have fiddled with every project paramter I could find reference to in every Usenet and web-board post I could find. I can not get this to work. I have loaded the resource editor in hopes that I could maybe spot old rements of the root namespace from the old 'Demo' app but I can;t seem to loacte that anywhere inside the resX file. The other thing I can not figure out is why the exception text points to a .resource file!
If anyone can lead me to a solution I would be GREATFULL
 
Can someone please help out before I loose what is left of my hair!
|
|
|
|
|
O,, I have done some more diging. I pulled up my copy of Reflector (Lutz Roeder) and noticed that same resource file in the origonal application that it was used in was listed as:
IconImages.resources
(note that it does not seem to include the root namespace of the application 'Demo' in this case)
I looked at the IL for my app and noticed that the same file was listed as:
csharp_OLApp.IconImages.resources
(note that for some reason this includes the rootnamespace of my application 'csharp_OLApp' in this case)
I changed the line that attemptes to load the images fro the resource manager that I created by including my application root namepsace as so:
Bitmap icons = (Bitmap)rmListImages.GetObject("ListIcons");
and now it seems to work.
My big question is WHY the heck did I have to include the namespace?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
