Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Object Initialization

Reply
Thread Tools

Object Initialization

 
 
JKop
Guest
Posts: n/a
 
      10-12-2004

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,
yielding:

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
does:

Monkey<std:stringstream>();

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: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
 
Reply With Quote
 
 
 
 
JKop
Guest
Posts: n/a
 
      10-12-2004

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


TYPO

"inefficent"


-JKop
 
Reply With Quote
 
 
 
 
Ron Natalie
Guest
Posts: n/a
 
      10-12-2004
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.

 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      10-12-2004
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(at)dse.nl
 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      10-12-2004

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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what's the difference between value-initialization and default-initialization? Jess C++ 23 05-04-2007 03:03 AM
array initialization in initialization list. toton C++ 5 09-28-2006 05:13 PM
Initialization of non-integral type in initialization list anongroupaccount@googlemail.com C++ 6 12-11-2005 09:51 PM
Initialization via ctor vs. initialization via assignment Matthias Kaeppler C++ 2 07-18-2005 04:25 PM
Default Initialization Vs. Value Initialization JKop C++ 10 09-22-2004 07:26 PM



Advertisments