Click here to Skip to main content
15,881,380 members
Please Sign up or sign in to vote.
5.00/5 (4 votes)
See more:
Say if we are having two pointers p and q. One is allocated by 'malloc' and another by 'new' operator.

Is there a way to identify this difference - The way they are allocated.

It could be useful while deallocating. We always look back how they are allocated and deallocate appropriately, but is there a way to do it programmatically ?

Hope this is not naive
Posted
Comments
Sergey Alexandrovich Kryukov 28-Jan-12 3:24am    
Interesting question from the theoretical point of view, needs some thinking. From the first glance, it's impossible (a pointer is a pointer). However, in practice it's the best to avoid such technique even if it was possible.
--SA
Lakamraju Raghuram 28-Jan-12 3:29am    
Yes both are pointers, but will there be evil effects if we mark them as separate ?
Sergey Alexandrovich Kryukov 28-Jan-12 4:25am    
Not clear what do you mean by "mark"...
--SA
CPallini 28-Jan-12 16:57pm    
As suggested by Richard you may override new/delete. This fact provides you an effective way to distinguish how a memory buffer was allocated.

I don't thinks there is a simple or compatible way to solve the problem in this way. Suppose you use some "system" tricks to look into some internal system structures responsible for allocation. This method would not be multi-platform or portable. Besides, it would violate the principle of abstraction of the platform from the applications.

I would rather suggest a practical approach. You can always use new/delete. In rare cases you need to use low-level allocation using malloc/calloc/realloc/free, wrap the set of such operations and the means to access allocated object in some class. For example, in the simplest case, allocate what you need to allocate on a low-level in the constructor of this wrapper class, free in destructor. In this case, if you use the object of this class on stack, allocation will be done in initialization of the object and deallocation — on the exit from the stack frame. If you want to use heap for the object of this wrapper class, the allocation/deallocation will be done on new/delete.

Using this technique, you will provide an object-oriented facade for all memory in the form of new/delete only.

—SA
 
Share this answer
 
v4
Comments
Lakamraju Raghuram 28-Jan-12 3:56am    
"use some "system" tricks to look into some internal system structures"
-- I too at some time taught to sweep around sys structures to get results, but dropped it.

"You can always use new/delete. In rare cases you need to use low-level allocation using malloc/calloc/realloc/free, wrap the set of such operations" -- This setup is clean and neat

My 5.
Sergey Alexandrovich Kryukov 28-Jan-12 4:16am    
I guess, we agree on that.
Good luck, call again.
--SA
There is some useful information about new and delete here[^], which also explains how to write your own class overrides. Under the covers (discovered by debugging) new uses malloc() and as far as I know just adds some control information to the memory block before handing back to the caller.
 
Share this answer
 
Comments
Lakamraju Raghuram 28-Jan-12 5:47am    
"new uses malloc()" -- yes i too observed it. It does something like "while ((p = malloc(size)) == 0)" as lifted from new.cpp.

And coming to that link, it gives useful info about new and delete, but haven't mentioned any where about how to separeate malloc and new allocated memories. My intention is to separate them so that I can know what to use (free or delete) when deallocating.

Thanks for the info.
Richard MacCutchan 28-Jan-12 6:22am    
Unfortunately you can't do this, as even if you figure it out today, Microsoft are free to change their implementation any time. The general rule is, if you are writing C++ code then you must always use new and delete; in fact, why would you not?
Sergey Alexandrovich Kryukov 28-Jan-12 19:03pm    
This is a good point; I also voted 5 for the whole answer.
--SA
CPallini 28-Jan-12 16:55pm    
Well, as correctly pointed out by Andres, new calls also the constructor(s).
First, it might help to understand what happens behind the scene before discussing if free or delete is to be called.

  1. malloc simply acquires some memory and returns the address to it.
  2. calloc calls malloc and in addition, initializes the memory with 0.
  3. new calls malloc and then calls the constructor code of the respective type.
  4. free marks the memory block at the given address to be free for being used by some other entity.
  5. delete calls the destructor code of the static type (or the polymorphic type if the destructor of the static type is virtual) and finally calls free on that memeory.


For POD types it doesn't hurt if you call new or delete, since the constructor/destructor is trivial, i.e. the constructor might initialize memory and the destructor doesn't do anything).
For non-POD types, I would say, it is a programming mistake in C++ if you use malloc and free: if the constructor/destructor was trivial, you don't gain anything, if it was not trivial, you break the logic of the program.

Whichever way you did acquire memeory, normal application and library implementation never get into the situation where it matters if you have to call delete or not, unless you have void* or you work on raw memory (char*) and you must free memory(?!).

If you want to check if a C++ program is correct regarding malloc/free versus new/delete, then the issue is very simple: No C++ uses ever malloc/free. If you have any C-code in C++ program, segregate it from the rest and skip that part from the check (and write a fascade towards C++ so that this C-resource never get washed directly into the C++ code).

BTW: the undelying memory management in C/C++ is a matter of the Operating System. I've seen some OS that acquires for each malloc some more bytes for the book keeping (memory size and if it is an array or a single entity). That block is usually just before the memory adderess that is returned to the client code.

Cheers

Andi
 
Share this answer
 
v3
Comments
Sergey Alexandrovich Kryukov 28-Jan-12 19:02pm    
Good point and explanation, my 5.
--SA
Albert Holguin 28-Jan-12 20:05pm    
Good explanation! +5
Lakamraju Raghuram 29-Jan-12 0:54am    
Good. Expanded SA's and Richard's argument in a nice way. My 5.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900