Hi all
recently I have experienced issues with code compatibility backward compatibility to be exact. I first thought this was not much of an issue but now I find out it is. I have coded many functions that I have translated to Nasm from other sources. Changed Macro system and also experimented with all sort of IDEs. I considered it sufficient to constantly update my sources, compile these into DLL's and keep a help file at hand for general information. If I changed a proc I recompiled the DLL and updated the help file. I have done this for a year and have a lot of small test programs code snippets and macros that I used, changed and discarded/updated as needed. Naturally the first programs I made I cannot compile anymore because the DLL's have changed. I'm planning an extensive rework of my macro system and general code layout. What guide lines  should I observe concerning:

1. DLLs adding/changing procs, example changing a proc by adding an extra arg(pointer to allocated memory) instead of local buffer. Should I create a new proc with different name or use the same name and use function overloading?

2.Memory allocation. I try to eg. Allocate memory ? call proc x,pMem and deallocate on return from proc. The problem arises when several procs use allocated memory. Where is the best place to deallocate? Garbage collection??

3.Run time debugging possibly she?
All suggestions are wellcome
Klod
Posted on 2009-09-28 22:06:58 by Klod
1) Function overloading will only work with C++ naming in a DLL. But most languages/linkers won't understand those. So my suggestion is to keep simple C-names in a DLL, and add a new function (eg MyFunctionEx(), like MS does).

2) Whenever possible, I would have the caller allocate memory itself, and just pass a pointer to this allocated memory to the function. If for some reason this isn't possible, I would suggest that you add a function to the DLL that deallocates this memory structure. This way the application doesn't have to know which function to use to deallocate the memory, and it won't cause crashes and bugs later. It also means that you can change the allocation and deallocation in your DLL, without breaking existing applications.
Posted on 2009-09-29 06:00:06 by Scali
I was thinking of moving  all overloaded functions out of the DLL's and keep them in a code module. Overloading could then be done via macros.

I would suggest that you add a function to the DLL that deallocates this memory structure. This way the application doesn't have to know which function to use to deallocate the memory, and it won't cause crashes and bugs later. It also means that you can change the allocation and deallocation in your DLL, without breaking existing applications. 

I'm not sure if I understand what you suggest. How would this memory structure look like? Most memory I allocate with GlobalAlloc and destroy it with GlobalFree. Both functions already reside in DLL's?
Maybe I should ask the question differently. If I could predict the scope of a memory allocation, then maybe deallocation would be more intuitive ? How to predict the scope of memory?
Posted on 2009-10-01 00:07:32 by Klod
Klod: if your library does memory allocations, which the client-side code must later free, then offer your own "FreeMemory" functions - that lets you change the internal memory allocation functions without client-side code having to worry.

Why do you use Global* instead of Heap*, btw? :)
Posted on 2009-10-01 02:01:39 by f0dder

I'm not sure if I understand what you suggest. How would this memory structure look like? Most memory I allocate with GlobalAlloc and destroy it with GlobalFree. Both functions already reside in DLL's?
Maybe I should ask the question differently. If I could predict the scope of a memory allocation, then maybe deallocation would be more intuitive ? How to predict the scope of memory?


What I mean is more like this...
Say you have the following function:
DataObject* GetDataObjectOfSomeDescription();

Then you pair it with this:
void FreeDataObjectOfSomeDescription(DataObject* pMyObject);

So your library knows how to allocate AND how to deallocate the data objects that it uses. This is especially useful in cases of nested datatypes, such as trees, where you can never really be sure who needs to deallocate what... Do you only deallocate the nodes, or do you also deallocate the data referenced in these nodes? Etc.
If you're familiar with COM, technically they do it the same way... each object has its own Release(), which takes care of any cleanup.
Posted on 2009-10-01 02:16:43 by Scali
To fOdder
Why do you use Global* instead of Heap*, btw?

Just an old habit. This was the first allocation api I used and it seemed to work for all the needs I had and so I never looked further :lol:
To Scali
If i understand correctly then memory would be released when the object is destroyed. An array of pointers or a linked list would then be passed as argument to the release function. This means that each object has to keep track of its memory allocations.

Regards
Klod
Posted on 2009-10-04 00:33:30 by Klod