NO

Author Topic: memory allocations  (Read 6880 times)

czerny

  • Guest
memory allocations
« on: March 27, 2013, 01:25:13 PM »
Hi,

I would like to discuss two different ways to virtualize (don't know if this is the right expression) the way, memory is allocated:

1. use malloc() and free() and if you like to replace them, you provide a file mem.h
Code: [Select]
#define malloc(x) myalloc(x)
void *myalloc(unsigned size);

#define free(p) myfree(p)
void myfree(void *p);
and if necessary a corresponding file mem.c

2. use not the standard names. Use something like ALLOC() and FREE() instead and provide a file mem.h
Code: [Select]
#define ALLOC(x) myalloc(x)
void *myalloc(unsigned size);

#define FREE(p) myfree(p)
void myfree(void *p);
and if necessary a corresponding file mem.c.

There are pros and cons for both methods. Sometimes I use the first, sometimes I use the second.

What do you think about?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: memory allocations
« Reply #1 on: March 27, 2013, 01:44:16 PM »
With first method you cannot use malloc and free anymore in current module.
With second you can use both.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

migf1

  • Guest
Re: memory allocations
« Reply #2 on: May 16, 2013, 10:31:22 AM »
Hi czerny,

Actually I don't see any advantage in the 1st method. I would most definitely go for the 2nd one, except that I wouldn't redefine my custom allocator in the pre-processor. Just the prototype should be enough, at least in most cases I can think of.

czerny

  • Guest
Re: memory allocations
« Reply #3 on: May 16, 2013, 07:36:13 PM »
Actually I don't see any advantage in the 1st method.
If you want to hook in the memory allocation process, even for third party source code. Look for tmalloc as an example.
I would most definitely go for the 2nd one, except that I wouldn't redefine my custom allocator in the pre-processor. Just the prototype should be enough, at least in most cases I can think of.
If you redefine it with the preprocessor, you can easily change the mem alloc function set, without any changes in your source code. Just recompile.

migf1

  • Guest
Re: memory allocations
« Reply #4 on: May 21, 2013, 08:18:43 PM »
Actually I don't see any advantage in the 1st method.
If you want to hook in the memory allocation process, even for third party source code. Look for tmalloc as an example.

You are right (a rather specific case though).

Quote
I would most definitely go for the 2nd one, except that I wouldn't redefine my custom allocator in the pre-processor. Just the prototype should be enough, at least in most cases I can think of.
If you redefine it with the preprocessor, you can easily change the mem alloc function set, without any changes in your source code. Just recompile.

I'm not sure I follow you on this one. I mean, you will have to change the source code of mymalloc() and myfree() anyway, no?

czerny

  • Guest
Re: memory allocations
« Reply #5 on: May 22, 2013, 08:06:50 AM »
I'm not sure I follow you on this one. I mean, you will have to change the source code of mymalloc() and myfree() anyway, no?
Imaging you have source code including a header file mem.h where amongst others ALLOC() is definde.

Then this definition could be as simple as:

Code: [Select]
#define ALLOC(size) malloc(size)
or
Code: [Select]
#define ALLOC(size) (GlobalLock(GlobalAlloc(GPTR, (size))))
or
Code: [Select]
#include "myalloc.h"
#define ALLOC(size) myalloc(size)
so you can see: there are multiple choices to provide a header file mem.h and the source modules using them don't know about there specific content.