Object Initialization

Discussion in 'C++' started by JKop, Oct 12, 2004.

  1. JKop

    JKop Guest

    Consider a simple POD:

    struct Blah
    int a;

    const char* p_b;

    unsigned c;

    double d;

    Now, let's say we want to create a "zero-initialized" object of this class,

    a == 0
    p_b == null pointer value (not necessarily all bits zero)
    c = 0U
    d = 0.0

    The only way to achieve this is via:

    Blah poo = Blah();

    ....which ridiculously, ludacrisly, may create a temporary if it wishes.

    Okay... so let's say we have a template. This template is a function:

    template<class T> void Monkey();

    What this function does is define an automatic local object of type T and
    makes it zero initialized.

    template<class T> void Monkey()
    T poo = T();

    But... this template function is to be designed to work with ALL types
    (intrinsics, POD's, non-POD's, what have you). But then some-one goes and


    which brings in the bullshit complication of not being able to copy certain
    types (ie. the above syntax must have the choice to copy).

    Anyway, short of using dynamic memory allocation, I've found one way of
    making a zero-initialized automatic object. . . but it has to be const:

    template<class T> void Monkey()
    T const &poo = T();

    Now Monkey<std::eek:stringstream> will work, and the "temporary" bound to the
    reference lasts for the length of the function... but it has to be const.

    Okay anyway... can anyone think of a way of doing this to achieve a *non-
    const* object? So far all I've got is:

    template<class T> void Monkey()
    T &poo = *new T();

    delete &poo;

    ....and all of this because of the "function declaration Vs object
    definition" bullshit! If only the "extern" keyword were mandatory... or if
    the "class" keyword could specify that it's an object definition...

    While I'm on the subject... is there actually anything "wrong" with using
    dynamic memory allocation? I myself don't know assembly language, so I can't
    see what's going on under the hood... but could you tell me, do the
    following two programs result in the same assembly code?

    Program 1:

    int main()
    int k = 5;

    k -= 2;

    Program 2:

    int main()
    int &k = *new int(5);

    k -=2;

    delete &k;

    Is there anything inherently "efficent" or "...bad" about using dynamic
    memory allocation... ?

    JKop, Oct 12, 2004
    1. Advertisements

  2. JKop

    JKop Guest

    > Is there anything inherently "efficent" or "...bad" about using dynamic
    > memory allocation... ?



    JKop, Oct 12, 2004
    1. Advertisements

  3. JKop

    Ron Natalie Guest

    JKop wrote:

    > Is there anything inherently "efficent" or "...bad" about using dynamic
    > memory allocation... ?

    Well, it's probably a bit less efficient for small objects than using
    the automatic storage, but of course, that won't meet your requirements.
    Ron Natalie, Oct 12, 2004
  4. JKop wrote:

    > Is there anything inherently "efficent" or "...bad" about using dynamic
    > memory allocation... ?

    Putting objects on the "stack" (automatic storage) is more typically
    efficient since all of the work needed to allocate and deallocate memory
    for the object can be done during compile time. The downside is that
    there is no standard way to see if you running out of stack space.

    With dynamically allocated memory (free store) work needs to be done
    during runtime, which means slower code. Depending on the compiler,
    run-time library and platform the performance difference can be quite
    significant. With dynamic memory allocation there is also the risk of
    heap fragmentation. This is a concern when a system has to run 24/7 and
    frequently allocates and deallocates memory. This can fragment the heap
    in such away that there is no free memory block large enough to fulfill
    an allocation request even though the total amount of free memory is
    sufficient. Another disadvantage of dynamically allocated objects is
    that you have to explicitly deallocate too, unless you use smart
    pointers. Without smart pointers it is very hard to write exception safe
    leak free code.

    Peter van Merkerk
    Peter van Merkerk, Oct 12, 2004
  5. JKop

    Howard Guest

    I'm curious: if you want to initialize everything (to zero, or anything
    else, for that matter), why not just have a constructor that does it for
    you? That's what they're for, after all. In my opinion, having all the
    members of a class be set to zero initially is no different conceptually
    from having them set to any other desired value. Granted, member pointers
    are a different matter, since you generally don't want them to be non-zero
    unless they're valid, but still, the constructor can simply set those to
    NULL, if needed. But in any case, adding a default constructor that
    initializes everything to whatever you want them to be seems easier than
    messing around with templates like that. And if one day, you decide that
    you want one of those members to initialize to something other than zero,
    all you have to do is change the single assignment (or better, the single
    entry in your initializer list).

    Howard, Oct 12, 2004
    1. Advertisements

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. JKop
  2. Matthias Kaeppler
    Victor Bazarov
    Jul 18, 2005
  3. Replies:
    Ron Natalie
    Dec 11, 2005
  4. toton
    Victor Bazarov
    Sep 28, 2006
  5. Jess
  6. aaragon
    James Kanze
    Nov 2, 2008
  7. , India
    Dec 30, 2008
  8. Replies:
    Arne Mertz
    Mar 26, 2009