(wwj) wrote:
[ Don't top-post, please. Corrected. ]
> "Roose" <> wrote in message news:<rHIpb.13664$ om>...
> > char a[6], if declared in a function, is a character array on the stack,
> > typically (flamers note: if I go into auto, it's going to take a lot more
> > explanation than he cares to hear, so STFU)
The point is that "automatic memory" is a higher-level concept, and
therefore more useful to the reliable, foresightful programmer than "on
the stack". In particular, automatic memory has properties that a stack
need not have, and vice versa.
Besides, automatic memory need not be kept in any stack. It's quite
common, for example, for the smaller auto objects to reside in
registers. Well-written C doesn't care about the difference, as long as
auto objects function as the Standard says they should.
> > char *p = new char[6]; assigns to p a pointer to the beginning of 6
> > bytes of dynamically allocated memory, typically located on the "heap" as
> > you said
> >
> > Google for "stack" and some other stuff maybe "function" "compiler", if you
> > don't know what a stack is. It's an abstract data type,
Not in this context, it isn't. _If_ automatic memory is placed in a
stack, it's almost certainly a hardware one. Of course, it would be
possible to write a C implementation for a LISP machine which puts its
auto memory in a software stack, which would be an example of an ADT
after all... and a well-written C program wouldn't care a jot about his
detail.
> > That is, it manages their automatic cleanup after the function exits.
Erm, no. The demands of automatic memory do that. That's why it's called
"automatic", see? Internally, the C implementation does a lot of byte
shuffling whether your auto memory is on a stack or not; but the point
is that this is hidden from you no matter how it is implemented.
> > The difference is that they are basically different systems of managing
> > memory. With a stack, you don't have to worry about cleaning up -- however
> > the variable has limited scope.
YM duration. Memory has no scope, identifiers have scope. It _is_
possible to have allocated memory, with only one identifier pointing to
it which has block scope, but with allocated duration which lasts beyond
that scope - and this knowledge is important, because failure to
recognise it often causes memory leaks. Like this:
{
int *a;
a=malloc(100* sizeof *a);
}
Note that the pointer a has a scope of no larger than this single block
- yet the memory it is made to point to has a duration beyond the
block's execution time. In this case, this causes a memory leak. A
single return a;, which affects neither the scope of the identifier nor,
strictly speaking, the duration of the object, could solve the leak.
> Ok,thanks Roose very much.You are a good person , goodness.
I doubt that. His information, in any case, is dubious.
> In our here ,I learn from school that basiclly C++ is a extension of
> C,and C is a subset of C++,expcept some difference.
That is, alas, a much-held view, but it's wrong. _Good_ C++ is
fundamentally different from good C. It is, indeed, possible to write a
restricted kind of C++ which looks like a restricted kind of C, but in
the general case the result will be bad C, and AFAICT worse C++.
> Maybe it is that my teacher do not express that clearly
All too many teachers don't know what the blazes they are on about, and
all too many teachers do indeed think that they know C == C++ minus
classes, which is patently and obviously false.
Richard
Similar Threads
