Re: Representing and dynamically creating a managed object in assembly
Quote:
IIRC this is a calling convention thing, right? (Already when writing part of the posts above, I wanted to read up on the x64 calling convention, but didn't find the respective MSDN page again.
as for the articles I used to learn it I used http://msdn.microsoft.com/en-us/magazine/cc300794.aspx and http://msdn.microsoft.com/en-us/library/ms235286.aspx I am still a little shaky on the set up of the stack on these concepts, I can set up the stack as I uderstand it, but if I call into a routine I set aside enough storage for the passed variables (at least 4 whether used or not) + whatever other stuff I push onto the stack in that routine, but sometimes I get errors (I allways align the stack on16), where I get the errors is if the called routine is calling another routine if I havent pushed a mutliple of 16 bytes (2 pushes) then I get a runtime error on the second call. Ive figured out a work around to it, by checking the rsp register for 16 byte alignment before doing the second call, if its not on 16 bytes alignment I simply subtract another 8 bytes from the stack pointer before doing the call (and marking a special local variabl in the routine to flag the fact that I subtracted an extra 8 bytes so that I can add that 8 bytes back in upon returning). In some of my routines there are multiple levels of calls to other routines and because of possible different branches in the routine I cannot predetermine how many pushes Ive made. Too me, this check on stack alignment looks sloppy but it works, and works well enough that the call stack show the correct info while debugging (which Ive learned is a good indication if I have a problem somewhere).
Quote:
OIC. As I know myself, that wouldn't work for me: Once I'd have got it working, I'd most probably be too lazy to start another pass of work just to add the comments
Usually by this point I am finally understanding why its working and have a much clearer idea and how it should be implemented and want to try to implement it correctly (as I understand the problem at the time) before walking away from it, thats when I tend to add in my comments, unless the routine is especially complex or long then I add in comments while working on it. I am self taught, so what may be common knowledge to yall, I am learning (probably the hard way). Its sometimes hard to find the answer when you dont even know how to form the question correctly lol.
Quote:
Remember the frequently cited statement about (native) C++, that its combination of power and programmer freedom makes it easy to shoot yoursef in the foot by using it incorrectly. Extending that picture, assembly language makes it easy to hit both feet with a single shot, and maybe cause some more damage...
Shot both feet multiple times lol, its funny how those are the lessons that are easiest to remember.
Quote:
In fact, that's one of the rather complex aspects of interop. There are some specific templates available in C++/CLI, and I think I recall having seen one named gcroot being used in such a context. I found the MSDN page Language Features for Targeting the CLR to be a great starting point for researches on topics like this, short of knowing anything more specific to start from. Of course templates are a library feature rather than a lanuage feature, but at least some of those can be found starting from there as well, following the links on the page
Well I figured out how to make it work without leaking memory, but it lost some of its ease of use. For instance I cant have a statement in my managed code like
Code:
_answer=_val1+_val2;
that leaks memory (and I think its because my attempt to make an object immutable my operator= doesnt change the existing value but returns a whole new object). Anyways, the above statement right now looks like
Code:
_answer->ReplaceAndDelete(_val1+_val2);
Adding that replace and delete routine to the managed code took care of almost all of the memory leaks. I had thought about changing the operator= routine with the code that was in th replaceand delete routine, but figured there are times when youd want to take on the new value without destroying the value youre taking on because it may still be in use by something else.
Of course there is probably a better way to implement all this, and when I come across an article, suggestion, or an idea that I think I can implement that makes it work better then the way I have it, or makes it work more the way I believe it should, Ill change it. This project was never meant to become this big or complex, but I am curious how far I can take it.
