operator new (iNumBytes) vs std::malloc(iNumBytes)

[Andrew Tomazos]

Given:

void f(void* p) { ... }

and assuming the operator new has not been overloaded, what are the
concrete differences in behaviour of:

void* p = operator new(iNumBytes);
f(p);

vs

void* p = std:malloc(iNumBytes);
f(p);

That are visible by f?

For example is one reallocable and the other not? Does one consider
alignment restrictions that the other does not? Are there other
differences?

Under g++ and vc++ are the operator new(bytes) and std::malloc
implemented with the same function?

Thanks,
Andrew.

 

[James Kanze]

Given:

void f(void* p) { ... }

and assuming the operator new has not been overloaded, what
are the concrete differences in behaviour of:

void* p = operator new(iNumBytes);
f(p);

void* p = std:malloc(iNumBytes);
f(p);

That are visible by f?

The main one is that in the first, p must be freed by :perator
delete, and in the second, by std::free.

For example is one reallocable and the other not?

I'm not sure what you mean "reallocable". If you want to use
std::realloc, only memory allocated by the second is eligible.

Does one consider alignment restrictions that the other does
not?
No.

Are there other differences?

Just that they're two different functions, which may (or may
not) draw memory from a different arena.

Under g++ and vc++ are the operator new(bytes) and std::malloc
implemented with the same function?

I don't know off hand, but many :perator new do, in fact, call
malloc to obtain their memory. (The reverse is not allowed.)

 

[Thomas J. Gritzan]

The main one is that in the first, p must be freed by :perator
delete, and in the second, by std::free.

I think that it's also important to know that, in the second, p can be NULL.

 

[Gerhard Fiedler]

The main one is that in the first, p must be freed by :perator
delete, and in the second, by std::free.

But AFAIK that's not visible by f, right? If f were to de/reallocate the
memory, there has to be a convention about how the memory was allocated,
as this is not visible by f.

Gerhard

 

[airfish09]

operator new ( 0 ) returns a distinct non-null pointer if there's
sufficient memory. malloc( 0 ) can return a null pointer, even if there's
enough memory.

If the requested size is 0, malloc may return a null pointer or a
non-null pointer.

On my OS, FreeBSD, malloc will first look up the configuration and
decide whether to return a null pointer:

/usr/src/lib/libc/stdlib/malloc.c:

void *
malloc(size_t size)
{
void *ret;

....

if (size == 0) {
if (opt_sysv == false)
size = 1;
else {
ret = NULL;
goto RETURN;
}
}

ret = imalloc(size);

REUTRN:

....

return (ret);

}

 

[James Kanze]

I think that it's also important to know that, in the second,
p can be NULL.

Very good point (and I'm surprised I forgot it). The two differ
considerably in the way they report an error: :perator new
raises an exception (std::bad_alloc, or something which derives
from std::bad_alloc), std::malloc returns a null pointer (which
you have to test for).

Another difference, at least in theory, is that you can replace
:perator new, but not std::malloc. I say in theory, because
in all implementations I actually know, you can also replace
std::malloc. The standard says that attempting to do so is
undefined behavior, but in practice, it always works. On the
other hand, you almost certainly have to use implementation
dependent code if you replace std::malloc, where as if you
replace :perator new, you can portably use std::malloc for the
actual allocation.

 

[James Kanze]

But AFAIK that's not visible by f, right? If f were to
de/reallocate the memory, there has to be a convention about
how the memory was allocated, as this is not visible by f.

I guess it depends on what you mean by "visible by f". Given
just a pointer, there's no way f can know if it was allocated by
malloc or by new. Or for that matter, whether it was
dynamically allocated, or points to a local variable. On the
other hand, if p was allocated by operator new, and f attempts
to free it with ::free, there will be undefined behavior. Which
means that the results may be very visible (or invisible---you
just don't know).

 

[Andrew Tomazos]

operator new can be replaced by the user in a portable way (which is
distinct from overloading, where additional arguments are added). malloc
can't.

Sorry I meant override, not overload. My mistake.
-Andrew.