whats the advantageof malloc over new in c++.

[Muzammil]

whats the beauty of "malloc" over "new" why its helpful for
programmer.for its own memory area.??

 

[Nick Keighley]

whats the beauty of "malloc" over "new" why its helpful for
programmer.for  its own memory area.??

malloc() doesn't get used in C++ programs very much.
malloc() just allocates memory. new allocates memory
and constructs the object (by calling the constructor).
Placement new runs the constructor on the memory provided.

malloc() is mainly provided for historical compatibility
with C. new may use malloc() internally (it doesn't have to).

the main use for malloc(), I can see, is if memory is to
be passed to a C function and to be freed by the C function.

 

[tony_in_da_uk]

malloc() doesn't get used in C++ programs very much.
malloc() just allocates memory. new allocates memory
and constructs the object (by calling the constructor).
Placement new runs the constructor on the memory provided.

malloc() is mainly provided for historical compatibility
with C. new may use malloc() internally (it doesn't have to).

the main use for malloc(), I can see, is if memory is to
be passed to a C function and to be freed by the C function.

+ malloc provides memory that _may_ be able to be grown using
realloc() without having to copy the content

+ new can be overridden to do all manner of things - which is normally
a good thing - but malloc() might occasionally be useful as a way to
bypass this (though you can't generally be sure that the "normal"
malloc function will receive your call - there are lots of ways of
installing alternatives)

+ you can free malloced memory without having the destructor called
(not normally a good idea, but may allow optimisations in certain
usages)

Still, the short story is don't use malloc/realloc and free unless you
find a reason to have to.

Tony

 

[Ian Collins]

predictable program flow is a disadvantage? Not even google likes c++ exceptions.

Their loss.

 

[peter koch]

predictable program flow is a disadvantage? Not even google likes c++ exceptions.

I don't know about google, but using an exception is the preferred and
standard way to cope with an error that can't be handled locally. If
you believe that you can handle the exception locally, nothing
prevents you from using the non-throwing version of new.

/Peter

 

[tony_in_da_uk]

Perhaps I didn't explain that well... sorry... off-the-top-of-my head
coding here:

if (X* p = (X*)realloc(old_p, sizeof(X) * new_capacity))
for (int n = old_size; n < new_capacity; ++n)
new(p[n]) X(fn(n)); // meaningful construction...

Hmm, tell me what happens in the code above if realloc unfortunately
fail to be able to grow in place and need to malloc new memory at a
different place?

Guess if X is memcpy-able you'll survive but if not, you are dead.

Agreed - discussed earlier in another of my posts to this thread.

What advantage does this has over (apart from being more bug prone):

std:vector<X> v;
// v.reserve(somenumber); //optional
// ...
for(size_t n = v.size(); v < nerw_capacity ; ++v)
v.append(X(f(n)));

Yan

The advantage (strange that you list error proneness as an advantage)
that I was discussed was that you're making a more explicit request
that the vector not be moved unless necessary.

You seem to be misunderstanding my posts... we're not recommending
these usages, but explaining differences and why sometimes some
vaguely credible excuse/argument for using malloc/realloc/free exists.

Tony

 

[Dilip]

Their loss.

Ian

To make the discussion concrete, it might be interesting to address
the Cons mentioned at this link:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions

It does look like Google is simply talking about difficulty of
introducing exceptions in an existing codebase and they do agree that
their benefits far outweigh the costs.

 

[Ian Collins]

Ian

To make the discussion concrete, it might be interesting to address
the Cons mentioned at this link:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions

It does look like Google is simply talking about difficulty of
introducing exceptions in an existing codebase and they do agree that
their benefits far outweigh the costs.

In that context their rule does make sense.

 

[tony_in_da_uk]

if (X* p = (X*)realloc(old_p, sizeof(X) * new_capacity))
   for (int n = old_size; n < new_capacity; ++n)
       new(p[n]) X(fn(n)); // meaningful construction...
What advantage does this has over (apart from being more bug prone):
std:vector<X> v;
// v.reserve(somenumber); //optional
// ...
for(size_t n = v.size(); v < nerw_capacity ; ++v)
    v.append(X(f(n)));

[realloc advantage] you're making a more explicit request
that the vector not be moved unless necessary.

(which is exactly what std::vector does)
The problem is that you do not know in advance if the realloc can
grow the buffer or if it will need to malloc and copy.  Either can
happen.  This makes the construct pointless.  Worse,  it gives the
illusion to the poor programmer that the memory will not be moved and
it hides bugs.  

I think this is the second time in this thread that the "can't be sure
= useless" argument has been put. It's blatantly absurd: for example,
is a hash_map useless because it might have a collision? Laws of
averages are relevant.

Re may-or-may-not introducing two code paths to test / hides bugs:
agreed - using malloc/realloc/free is definitely much more fraught
with risks than new/delete. That's not really relevant either, as I'm
saying realloc has one potential advantage - you can be sure if will
realloc in-place if possible - not defending the overall balance of
pros and cons.

But my point was this is not even a vaguely credible excuse.  It is
simply WRONG.  std::vector will do the right thing.  It will probably
internally try to grow its buffer and not move it unless necessary.

"Proabably"? What gives you this idea? The old SGI STL provided a
hint to the allocator which could be used for this, but to the best of
my knowledge this is not common practice in current STL
implementations, it's not available in the GCC headers shipped with
the current Dev-C++ (sorry / no real machine to check handy), and the
Oct '97 draft Standard section 20.1.5.2 Table 6 makes it clear that
there's no expectation of any support for realloc or the SGI-style
hint.

If you use reserve, it will not need to move/copy.
If you didn't or
grow beyond the originally reserved size, if it can grow its buffer,
its performance characteristics will be similar to the use of realloc,
if it can't grow in place, it will copy correctly.

Yes, but often not possible (e.g. when appending elements as they
arrive from an IPC mechanism, or are entered by a user).

It is not a question of not recommending using realloc with objects.
It should be actively recommended against.  

Yes, I believe I've done that already "Still, the short story is don't
use malloc/realloc and free unless you find a reason to have to.".
That doesn't mean that the pros/cons can't be objectively enumerated
and weighed.

Essentially, to go back to the subject of this thread:

If you write C++ use new.  
(you can stop reading here)

Pretty much right. Anyone experienced enough to understand that they
really must use new doesn't need to read this thread anyway....

sorry for the preaching but I've had the unfortunate experience of
working with bad programmers in my life.  Bad C programmers having
moved to C++ insisting on using malloc because it's what they've
always used.  Doing awful premature optimisation without profiling.
Wanting to use malloc/realloc because "C++ is slow and does things
under the hood without telling you" without having profiled nor
bothered looking at std::vector implementation.  

Yes, part of being a programmer... quite understand.

Cheers,

Tony

 

[tony_in_da_uk]

There's a huge difference between hash_map collisions
and failure of realloc to grow in place in the code above:
a hash_map is designed to handle hash collision, a collision
simply result in slightly slower access time. In the sample
code above, realloc deciding that it needs to move everything
elsewhere and memcpy results in a bug! That is not
comparable. Law of average should not be used if it mean
that "most of the time my program will work but once in a
while it will crash" rather than "most of the time my
program will be fast but once in a while it will get a bit
slower".

The code to which you refer is safe for any data which can be safely
and silently relocated. Within those boundaries, use of realloc is
indeed a simple sometimes-fast / sometimes-slow situation.

You can be sure that if it is possible it will realoc in place
but you can't know "if it is possible". So essentially, you
know nothing and you are sure of nothing.

What kind of FUD argument is this? You know realloc has three
possible outcomes - failure to resize, inplace resize, or some manner
of memcopy/move+resize. This isn't impractical - one or two C
programmers have actually written reliable systems handling these
branches. I met one once. His name was Bob. He looked very sad.

The old SGI STL provided a hint to the allocator which
could be used for this, but to the best of
my knowledge this is not common practice in current STL
implementations, it's not available in the GCC headers
shipped with the current Dev-C++ [...], and the
Oct '97 draft Standard section 20.1.5.2 Table 6 makes
it clear that there's no expectation of any support for
realloc or the SGI-style hint.

Sorry, you are right, my implementation appears to move
the buffer (and copy everything) every time
vector.capacity() changes.

So I am left only with that vector will work all the time
and if you can use reserve() it will be as performant
as realloc.

Two very important considerations, but not the basis for a "never
never never use realloc" recommendation.

Correct me if I am wrong but my understanding of realloc
is that it is most likely to be able to grow in place if
there are few allocations happening e.g. if you are in a
loop and the only dynamic memory allocation that happens
is the realloc, it _might_ well be bounded by
unused space and will be able to grow in-place. However,
if there are other mallocs happening between reallocs,
these are likely to be placed right after the realloc
buffer and stop it being able to grow in place.

My point is that in a complex system, you might not be
able to use reserve() correctly but also realloc() is
likely not to grow in-place. In a simpler system where
few things happen and realloc has a good chance to
grow-in-place, you might also be able to use
reserve() in a useful way. Obviously there are
exceptions.

Memory allocation schemes are many and varied, so we can't draw firm
conclusions. Still, I know it's not unusual for them to use separate
pools for different sized requests, rather than allowing any small
malloc request coming along to pack right in behind the last request.
I vaguely remember having heard of schemes deliberately scattering or
otherwise targetting allocations to maximise the chance of in-place
realloc.

Doing a very quick Google, I found:
- Paul Hsieh's "bstrlib.c" assumes 1 in 8 reallocs are in-place
(didn't find any justification, sounds pessimistic to me but I didn't
look at the string operation context)
- a similar discussion (with some "big-name" contributors ;-)) at
http://www.cpptalk.net/1-vt23200.html?postdays=0&postorder=asc&start=0

Yes, I understand that you understand. I am mostly
arguing that what at first sight might appear like a
worthy consideration for using realloc in C++ is quite
possibly not and one should look again

Yannick

Quite so - it'd need to be extreme circumstances before I'd even
consider it seriously....

Cheers,

Tony