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

Discussion in 'C++' started by Andrew Tomazos, May 10, 2009.

  1. 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.
    Andrew Tomazos, May 10, 2009
    #1
    1. Advertising

  2. Andrew Tomazos

    James Kanze Guest

    On May 10, 2:12 pm, Andrew Tomazos <> wrote:
    > 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?


    The main one is that in the first, p must be freed by ::eek: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 ::eek:perator new do, in fact, call
    malloc to obtain their memory. (The reverse is not allowed.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 10, 2009
    #2
    1. Advertising

  3. James Kanze schrieb:
    > On May 10, 2:12 pm, Andrew Tomazos <> wrote:
    >> 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?

    >
    > The main one is that in the first, p must be freed by ::eek: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.

    --
    Thomas
    Thomas J. Gritzan, May 10, 2009
    #3
  4. James Kanze wrote:

    > On May 10, 2:12 pm, Andrew Tomazos <> wrote:
    >> 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?

    >
    > The main one is that in the first, p must be freed by ::eek: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
    Gerhard Fiedler, May 10, 2009
    #4
  5. Andrew Tomazos

    Guest

    blargg <> wrote:
    >
    > 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);

    }
    , May 11, 2009
    #5
  6. Andrew Tomazos

    James Kanze Guest

    On May 10, 10:36 pm, "Thomas J. Gritzan"
    <> wrote:
    > James Kanze schrieb:
    > > On May 10, 2:12 pm, Andrew Tomazos <> wrote:
    > >> 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?


    > > The main one is that in the first, p must be freed by
    > > ::eek: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.


    Very good point (and I'm surprised I forgot it). The two differ
    considerably in the way they report an error: ::eek: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
    ::eek: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 ::eek:perator new, you can portably use std::malloc for the
    actual allocation.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 11, 2009
    #6
  7. Andrew Tomazos

    James Kanze Guest

    On May 10, 11:15 pm, Gerhard Fiedler <> wrote:
    > James Kanze wrote:
    > > On May 10, 2:12 pm, Andrew Tomazos <> wrote:
    > >> 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?


    > > The main one is that in the first, p must be freed by ::eek: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.


    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).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 11, 2009
    #7
  8. On May 11, 7:50 am, (blargg) wrote:
    > > and assuming the operator new has not been overloaded


    > 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.
    Andrew Tomazos, May 11, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page