Re: Dynamic memory management, straightening my understanding of its details
On Aug 30, 7:27 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* Francesco S. Carta, on 30.08.2010 19:59:
Bo Persson <b...@gmb.dk>, on 30/08/2010 19:28:45, wrote:
Francesco S. Carta wrote:
Hi there,
I'm trying to understand the details of the dynamic memory
management.
These are the various sections I've read these days:
1.7 [intro.memory]
3.7.3 [basic.stc.dynamic]
5.3.4 [expr.new]
5.3.5 [expr.delete]
12.5 [class.free]
18.4.1 [lib.new.delete]
20.4 [lib.memory]
The last sections above are quite technical and wide, I'm
still far from having any decent grasp on them.
Before going on I need to clear out if what I understood
so far is correct.
I wrote the following at the best of my comprehension and,
as far as I can tell, it should be a well-defined C++
program, please tell me if and where I've gone off the
track:
//-------
Other than that printing unitialized data is undefined behavior, it
seems pretty much ok.
[dcl.init] 8.5p9 seems to tell me that an uninitialized data
like that "int" in my code has just an indeterminate initial
value, I don't recognize that as UB - printing it out should
be well-defined: it should always show that initial value,
it shouldn't shoot me in the foot ;-)
Though, maybe, you were referring to some other clause -
could you please point it out for me, if that's the case?
In practice it's just arbitrary values.
But formally, except that char, unsigned char and signed char
have only value representation bits, the standard allows for
non-participating bits that may be used for e.g. error
checking, literally trapping your program. This is early in
the standard somewhere, section 3 perhaps? Even so, on
esoteric machine, you should be safe for integers, but
floating point values are different.
There are, in fact, two ways that it can fail. One is trapping
bits in the hardware. There is at least one machine in
production today which has bits which don't participate in the
value in an integer, and are required to be zero. In this
case, I don't think it will cause a core dump, but the results
could be rather unexpected. (The architecture is tagged, and if
the bits in question aren't zero, it will treat the value as
floating point, or as a pointer.) The other way is simply a
debugging implementation of C++, which somehow tracks which
bytes have been initialized or not. One obvious example of this
is code linked with Purify, although in this case, the
"undefined behavior" is an error message. In the past (and
maybe still---the product still has a Web page saying you can
buy it), CenterLine C++ did such error checking as well.
And that you must promise to never, ever do this in a real
program!
Sorry, I cannot :-)
I want to use the raw storage allocation in a home-cooked
Vector template - in it.comp.lang.c++ a person was looking
for a tutorial about a dynamic menu to be used in an
embedded C++ environment.
Why, do you think a new expression is somehow inefficient or
needs extra runtime lib support or something?
It's efficient and it does what you're doing manually, only more safe.
It depends. Within containers, it is often useful to separate
allocation and initialization.
--
James Kanze