|
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?
|
|
|
|
|
I found it interesting that when I created a Window Form in C#, the IDE hardcoded things like position and size of the controls in the code itself. Why? I never liked the RC file anyways, mainly because I thought it could do a lot more than it did (I ended up rolling my own for my own applications!). But to completely get rid of it seems like taking a big step backwards.
Sounds like someone (maybe me) should write a class that reads an RC-like file and creates the form/controls. And if the class were abstracted, able to generate Window Form and Web Form controls, then you could have one control file for both presentations. Does this sound reasonable?
Any comments/thoughts about the lost RC file?
Marc
|
|
|
|
|
I've seen a sample on GotDotNet that does this with XML. Its definetly not production grade but its a proof of concept. It can be done!
|
|
|
|
|
What's the rational behind this?
Marc
|
|
|
|
|
I beleive the thinking behind this was that Structs tend to be more "Light-Weight" than classes.
|
|
|
|
|
Stack is stored in stack, and Class in heap
Stack never grows, but heap can do.
I'm amumu, and you?
|
|
|
|
|
Did you mean "struct" is stored in stack?
I read somewhere on CP that you can explicitly allocate things on the stack also, so I think stacks can grow. I can't think of a good reason right now to do this, but you never know...
Marc
|
|
|
|
|
Marc Clifton wrote:
you can explicitly allocate things on the stack
This might be along the lines of being able to position things in memory within the struct.
I've seen some code examples and they seem to make use of attributes to pull this off.
Can't see a reason for this, although this might be to allow some interop with C++.
Cheers,
Simon
"Sign up for a chance to be among the first to experience the wrath of the gods.", Microsoft's home page (24/06/2002)
|
|
|
|
|
for the clr, the decision of whether a class is stored on the stack or the heap has been shifted from the consumer of the class to the developer of the class.
an exception is that the consumer of a ValueType ( class stored on the stack ) can "box" the ValueType, which allows her to treat the ValueType as an Object on the heap. I believe this is done by putting a pointer to the ValueType on the heap.
however, you can't put a reference object on the stack.
|
|
|
|
|
I read it from "Professional in .Net framework".
I'm amumu, and you?
|
|
|
|
|
I just read that C# doesn't support global variables. What does everyone think about that? Do you feel that this limits C# to small scale applications, or do you think that static variables in the "main" class can "replace" global variables? What about some sort of global variable management container?
Marc
|
|
|
|
|
Its not as bad as you think, after a while you'll get out of the mindset of wanting to use globals. It promotes good OO design. Hell, academics have been saying globals are the work of the devil since the early days of structured programming. 
In cases where globals would be appropriate you can just make a class with static members. However I rarely find myself doing that.
|
|
|
|
|
True, but like most other things, the difference between academia and the real world is like night and day. So static members are a "workaround" to the global problem (is there a pun in that?)
What about messaging? While the whole GUI event architecture in Window Forms is now changed to use delegates instead of messaging, there doesn't seem to be any support for messaging (well, there's the System.Messaging stuff, but that's way overkill for simple intra-application messaging). I've seen a lot of C++ apps that use custom messages for notifications, etc. Is this whole concept easily converted to delegates?
Thanks for your reply. I'm trying to dig into some of the differences in C# vs. C++ design.
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
