Object Initialization

[JKop]

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::ostringstream>();

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

[JKop]

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

TYPO

"inefficent"
-JKop

[Ron Natalie]

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.

[Peter van Merkerk]

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

[Howard]

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