only memory allocationj in new

Discussion in 'C++' started by asit, Nov 22, 2011.

  1. asit

    asit Guest

    new does the following two things.
    1>allocate memory
    2>calls constructor

    can I avoid the 2nd step ?
    asit, Nov 22, 2011
    #1
    1. Advertising

  2. On 11/22/2011 3:14 PM, asit wrote:
    > new does the following two things.
    > 1>allocate memory
    > 2>calls constructor
    >
    > can I avoid the 2nd step ?


    You can, if you need to. Just don't use "new yourclass". Allocate
    sizeof(yourclass) bytes:

    char* ptr = new char[sizeof(yourclass)];

    But keep in mind that 'ptr' is not an object of 'yourclass' in that
    case. Yet, that is. You can construct an object of your class by using
    "placement new" syntax:

    yourclass *pYourClass = new (ptr) yourclass;

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Nov 22, 2011
    #2
    1. Advertising

  3. On 22.11.2011 21:14, asit wrote:
    > new does the following two things.
    > 1>allocate memory
    > 2>calls constructor
    >
    > can I avoid the 2nd step ?


    Yes.

    If you don't add a "call" parenthesis then for POD type 'new' will just
    allocate an uninitialized chunk of memory. Or more precisely it's not
    then guaranteed to initialize it. POD means Plain Old Data, like in C.

    For example,

    char* pBuffer = new char[256];

    However, instead of using explicit 'new', try to use standard library
    containers or strings, e.g.

    std::array< char, 256 > fixedSizeBuffer; // C++11 or Boost

    or

    std::vector< char > dynamicBuffer( 256 );

    or

    std::string anotherDynamicBuffer( 256, '\0' );

    The main advantage is that then you don't have to deal with difficult
    things such as copying and deallocation.


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Nov 22, 2011
    #3
  4. asit

    Goran Guest

    On Nov 22, 9:14 pm, asit <> wrote:
    > new does the following two things.
    > 1>allocate memory
    > 2>calls constructor
    >
    > can I avoid the 2nd step ?


    You can (as others explained), but it's a bad idea to do so almost all
    off the time. I think you don't understand why it's a bad idea.

    If you --do-- have some related particular situation, C++ language
    offers a solution for it. You would do better to ask about what you
    are trying to achieve, as opposed to asking how to avoid calling a
    constructor.

    By the way, if not calling a constructor is important to you, and if
    you want to have an object on the stack, you can do this:

    #define MAKE_OBJ_REF(name, type) void* ____ = alloca(sizeof type);
    type& name = *reinterpret_cast<type*>(____);

    and then

    MAKE_OBJ_REF (dummy, dummy_class)
    dummy.member();

    I think the above is dumb. Don't you? And yet, that's what you ask
    for, only on heap.

    Goran.
    Goran, Nov 23, 2011
    #4
  5. Goran <> wrote:
    > By the way, if not calling a constructor is important to you, and if
    > you want to have an object on the stack, you can do this:
    >
    > #define MAKE_OBJ_REF(name, type) void* ____ = alloca(sizeof type);


    Except that 'alloca()' is not a standard function (and will not work
    eg. on VS2005, and probably not in any other VS either.)

    What you could do instead is to use a bit of trickery:

    unsigned char buffer[sizeof(type)];
    type* obj = reinterpret_cast<type*>(buffer);

    Unless 'type' is a POD type, be prepared for undefined behavior if
    you don't construct the object with placement new (and destroy it by
    calling its destructor explicitly).
    Juha Nieminen, Nov 23, 2011
    #5
  6. asit

    Goran Guest

    On Nov 23, 10:17 am, Juha Nieminen <> wrote:
    >   What you could do instead is to use a bit of trickery:
    >
    >     unsigned char buffer[sizeof(type)];
    >     type* obj = reinterpret_cast<type*>(buffer);
    >
    >   Unless 'type' is a POD type, be prepared for undefined behavior if
    > you don't construct the object with placement new (and destroy it by
    > calling its destructor explicitly).


    ;-)

    Just what we need, more ways to do dumb things!

    There's already two of you commenting (as of now) on what was stated
    as a dumb idea from the start. Forest, trees?

    Goran.
    Goran, Nov 23, 2011
    #6
  7. On Nov 23, 1:17 am, Juha Nieminen <> wrote:

    >   What you could do instead is to use a bit of trickery:
    >
    >     unsigned char buffer[sizeof(type)];
    >     type* obj = reinterpret_cast<type*>(buffer);
    >
    >   Unless 'type' is a POD type, be prepared for undefined behavior if
    > you don't construct the object with placement new (and destroy it by
    > calling its destructor explicitly).


    .... Or if the alignment is wrong :)

    - Kevin B. McCarty
    Kevin McCarty, Nov 23, 2011
    #7
  8. asit

    Joe keane Guest

    class Foo
    {
    ...
    struct bar { int bs; };

    static const struct bar uninit;

    inline Foo(struct bar& bs) { }
    ...
    };

    ...

    int f(int x)
    {
    Foo u(Foo::uninit);

    ...
    }

    [it still calls the base class ctor]
    Joe keane, Nov 23, 2011
    #8
  9. asit <> wrote:
    > new does the following two things.
    > 1>allocate memory
    > 2>calls constructor


    > can I avoid the 2nd step ?


    What about using malloc()? Seems to be considered as "bad"
    when it comes to C++, but that's the function that just
    allocates memory and nothing else. Of course, when you
    don't need the memory anymore you instead of using delete
    you must to call free() (which then, also of course, does
    not call the destructor of your object).

    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Nov 23, 2011
    #9
    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.
Similar Threads
  1. ABC
    Replies:
    7
    Views:
    681
    Luke Dalessandro
    Jan 13, 2006
  2. vnssoftware
    Replies:
    4
    Views:
    458
    Dmitry R
    Dec 31, 2003
  3. windandwaves
    Replies:
    1
    Views:
    375
    windandwaves
    Apr 10, 2006
  4. keithb
    Replies:
    2
    Views:
    7,990
    keithb
    Jun 7, 2006
  5. Replies:
    2
    Views:
    439
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page