Click here to Skip to main content
Rate this: bad
Please Sign up or sign in to vote.
See more: C++
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 27-Jan-12 22:20pm
SAKryukov at 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.
Lakamraju Raghuram at 28-Jan-12 3:29am
Yes both are pointers, but will there be evil effects if we mark them as separate ?
SAKryukov at 28-Jan-12 4:25am
Not clear what do you mean by "mark"...
CPallini at 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.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

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.
Lakamraju Raghuram at 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.
SAKryukov at 28-Jan-12 4:16am
I guess, we agree on that.
Good luck, call again.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

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.
Lakamraju Raghuram at 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 at 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?
SAKryukov at 28-Jan-12 19:03pm
This is a good point; I also voted 5 for the whole answer.
CPallini at 28-Jan-12 16:55pm
Well, as correctly pointed out by Andres, new calls also the constructor(s).
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

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.
SAKryukov at 28-Jan-12 19:02pm
Good point and explanation, my 5.
Albert Holguin at 28-Jan-12 20:05pm
Good explanation! +5
Lakamraju Raghuram at 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)

  Print Answers RSS
0 OriginalGriff 370
1 Sergey Alexandrovich Kryukov 329
2 BillWoodruff 235
3 Afzaal Ahmad Zeeshan 209
4 CPallini 195
0 OriginalGriff 5,560
1 DamithSL 4,476
2 Maciej Los 3,942
3 Kornfeld Eliyahu Peter 3,480
4 Sergey Alexandrovich Kryukov 3,175

Advertise | Privacy | Mobile
Web02 | 2.8.141216.1 | Last Updated 29 Jan 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100