Are "auto" arrays allocated in heap?
B R Balaji
I would like to know where the "auto" arrays are allocated in memory. Is it
implicitly allocated in heap through *new* operator ?
I'm having this doubt since they cant be allocated in local stack as they
retain their values between function calls.
PS: what I mean by "auto" arrays are the arrays declared like 'int a[10]';
Thanks in advance,
Balaji.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Jon Trauntvein
> Hi All,
>
> I would like to know where the "auto" arrays are allocated in memory. Is it
> implicitly allocated in heap through *new* operator ?
> I'm having this doubt since they cant be allocated in local stack as they
> retain their values between function calls.
>
> PS: what I mean by "auto" arrays are the arrays declared like 'int a[10]';
>
Although the storage allocation for automatic variables is no doubt
implementation dependent, they are, at least on windows and DOS
platforms that I have worked on defined on the stack along with
function parameters and return values (and the return address).
Regards,
Jon Trauntvein
Martin Vuille
In article <3a96bcfc$1...@godavari.wipro.com>, "B R Balaji" <balaji.ra...@wipro.com> wrote:
>Hi All,
>
>I would like to know where the "auto" arrays are allocated in memory. Is it
>implicitly allocated in heap through *new* operator ?
>I'm having this doubt since they cant be allocated in local stack as they
>retain their values between function calls.
>
>PS: what I mean by "auto" arrays are the arrays declared like 'int a[10]';
>
>Thanks in advance,
>
>Balaji.
Your premise is incorrect. Local automatic (i.e., not static or extern)
arrays are just like any other local automatic variable: their lifetime
ends when the block in which they are defined exits. [cf. 3.7.2/1]
The standard doesn't discuss where local automatics are stored (or, if
it does, I couldn't find it). This is what I expected, since some
architectures don't have stacks, or have a specialized stack that can
only be used to store call/interrupt return addresses.
The behaviour you observed is not unexpected. Under the right
circumstances, it is likely that the same area of memory is used on
consecutive function invocations and that the contents of that area
are unchanged between invocations.
If you do not initialise the array, it may _appear_ that the array
retains its value. Sadly, this is only because you are invoking
undefined behaviour (accessing the value of an uninitialised variable.
[cf. 4.1/1]) On a different processor/compiler/version of the same
compiler/day of the week, spontaneous combustion would be just as
reasonable an outcome.
If you _do_ want the array to retain its value across invocations,
declare it 'static'. In any case, initialise it.
MV
Martin Vuille | Real-time and | Software & Firmware Contracting
JPMV Realtime Inc. | embedded | Turnkey Controls Development
Tel.:(613)823-0777 | control | System Integration
Fax.:(613)823-3034 | specialist | Product Development Consulting
Francis Glassborow
n...@wipro.com> writes
>Hi All,
>
>I would like to know where the "auto" arrays are allocated in memory. Is it
>implicitly allocated in heap through *new* operator ?
No, an implementation must not call the new expression implicitly.
>I'm having this doubt since they cant be allocated in local stack as they
>retain their values between function calls.
How on earth do you arrive at that conclusion? Of course if there are
no intervening function calls that alter the contents of the memory that
was used for the stack frame, a subsequent call may get the same
(unmodified) stack frame.
Actually a compiler does not have to put an array (or anything else) on
a stack. Several compilers I have used in the past put arrays somewhere
else, and you might well get the same block back again.
Do not rely on chance (just like relying on getting zero initialised
stack frames because the memory has not yet been written to and the OS -
e.g. NT - has zeroed all memory before releasing it to your program)
>
>PS: what I mean by "auto" arrays are the arrays declared like 'int a[10]';
>
>Thanks in advance,
>
>Balaji.
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
Frank Muzzulini
> implicitly allocated in heap through *new* operator ?
> I'm having this doubt since they cant be allocated in local stack as they
> retain their values between function calls.
I am quite sure the standard says nothing about how these arrays are
to be allocated, all it says is how they should behave. Now if you
read those values before they are initialized, you may get any values
(You may even crash your program, since reading uninitialized
variables leads to undefined behaviour, IIRC). If you get the same you
wrote in the last call, this may have various reasons and it surely
depends on your compiler. However this can never be guaranteed, after
all the function may be recursive and then the compiler *must* use
diffenent memory.
Muzz
--
___ Frank Muzzulini
<*,*> ... until the colour of a man skin is of no more
[`-'] significance than the colour of his eyes ... Haile Selassie
-"-"-
Carlos Moreno
>
> Hi All,
>
> I would like to know where the "auto" arrays are allocated in memory. Is it
> implicitly allocated in heap through *new* operator ?
> I'm having this doubt since they cant be allocated in local stack as they
> retain their values between function calls.
>
> PS: what I mean by "auto" arrays are the arrays declared like 'int a[10]';
You'll have to learn to stop second-guessing the compiler :-)
No, int a[10] does not invoke new. new can only be part of a statement;
a declaration of an object of a user-defined type could invoke new, as
the constructor for that object is executed. But int a[10] is no user-
defined type, so it is allocated on the stack.
So what that the values between calls are preserved?? Where did you
see in the language definition that the values of auto variables can NOT
be preserved between calls? They are not guaranteed to be preserved,
and of course it is a sane programming practice to assume for a fact
that they won't. But depending on your platform and depending on what
your program does, it may be possible (even likely) that the values are
preserved, as it may be very likely that you can still access delete'd
memory and get the right values. Of course, you'd never rely on any of
these things happening, but that doesn't mean that they can not happen!
HTH,
Carlos
--
Andrew Koenig
> implicitly allocated in heap through *new* operator ?
No, they're allocated on the heap.
> I'm having this doubt since they cant be allocated in local stack as they
> retain their values between function calls.
They don't retain their values between function calls, except in
the case where nothing else happens to overwrite that memory.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Carlos Moreno
Andrew Koenig wrote:
>
> > I would like to know where the "auto" arrays are allocated in memory. Is it
> > implicitly allocated in heap through *new* operator ?
>
> No, they're allocated on the heap.
Did you mean to write "they're not allocated on the heap" and it was
just a typo?
Or am I completely wrong in thinking that it would be almost impossible
for a compiler to allocate auto-arrays on the heap? (the compiler would
have to "manually" implement its own stack of allocated space on the
heap -- otherwise, how would it implement a recursive function that
uses a local array?)
I know that it is not your habit to make mistakes or write incorrect
statements... so I'm wondering if it was a typo?
Carlos
--
Francis Glassborow
<a...@research.att.com> writes
>> I would like to know where the "auto" arrays are allocated in memory. Is it
>> implicitly allocated in heap through *new* operator ?
>
>No, they're allocated on the heap.
I think you meant 'stack' :)
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Nicola Musatti
This might explain the misconception...
Best regards,
Nicola Musatti
John Potter
<francis.g...@ntlworld.com> wrote:
> In article <3A9B98A0...@divalsim.it>, Nicola Musatti
> <obje...@divalsim.it> writes
> >Is it my memory playing tricks or local arrays in C used to be static?
> >This might explain the misconception...
>
> Your memory, I think, is playing tricks on you.
His memory may be fine. Implementations have used static rather than
stack space for local arrays. As long as there is no recursion it
will work and a conforming program will never know. Not that the
standard said they were static, just that an implementation can get
away with it if careful.
John
Carlos Moreno
John Potter wrote:
>
> His memory may be fine. Implementations have used static rather than
> stack space for local arrays. As long as there is no recursion it
How could the compiler know if there is recursion?
In translation unit 1:
void f1 ();
void f2 ()
{
int values[] = { ... };
// ...
f2();
}
In translation unit 2:
void f2 ();
void f1 ()
{
// ...
if (certain condition)
{
f1();
}
}
How can the compiler know that it can not allocate the local array
statically? Maybe as soon as it sees that the function does call
another function it would allocate it on the stack? (sounds like
too twisted a solution for so little gain, mainly given that 99.99%
of the times, a function will indeed call another function)
Carlos
--
Neil Butterworth
news:3aa2467b...@news.csrlink.net...
> On 4 Mar 2001 05:23:31 -0500, Francis Glassborow
> <francis.g...@ntlworld.com> wrote:
>
> > In article <3A9B98A0...@divalsim.it>, Nicola Musatti
> > <obje...@divalsim.it> writes
> > >Is it my memory playing tricks or local arrays in C used to be static?
> > >This might explain the misconception...
> >
> > Your memory, I think, is playing tricks on you.
>
> His memory may be fine. Implementations have used static rather than
> stack space for local arrays. As long as there is no recursion it
> will work and a conforming program will never know.
And as long as the program is single-threaded, which of course a conforming
compiler need not address but which a practical one must.
> Not that the
> standard said they were static, just that an implementation can get
> away with it if careful.
Can you name an implementation that did this?
NeilB
Francis Glassborow
<jpo...@falcon.lhup.edu> writes
>His memory may be fine. Implementations have used static rather than
>stack space for local arrays. As long as there is no recursion it
>will work and a conforming program will never know. Not that the
>standard said they were static, just that an implementation can get
>away with it if careful.
Where a compiler places an auto array is entirely its choice. If that
happens to be in a static area, it better make sure that there is no
recursion possible and that would seem an awful lot of work. However I
know of quite a few compilers that did not put auto arrays in a stack
frame but used an entirely different pool of memory. My point is that C
never specified this kind of behaviour, though it never forbade it.
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> In article <3aa2467b...@news.csrlink.net>, John Potter
> <jpo...@falcon.lhup.edu> writes
> >His memory may be fine. Implementations have used static rather
> >than stack space for local arrays. As long as there is no
> >recursion it will work and a conforming program will never know.
> >Not that the standard said they were static, just that an
> >implementation can get away with it if careful.
> Where a compiler places an auto array is entirely its choice. If
> that happens to be in a static area, it better make sure that there
> is no recursion possible and that would seem an awful lot of
> work. However I know of quite a few compilers that did not put auto
> arrays in a stack frame but used an entirely different pool of
> memory. My point is that C never specified this kind of behaviour,
> though it never forbade it.
I once (many years ago) used a Pascal compiler which more or less did
this. The target processor was an 8080; accessing stack data was
extremely expensive, and recursive functions relatively rare. So the
compiler generated all of the local variables statically. It also
generated a flag to indicate whether it was already in the function;
if it was, it copied the current values onto the stack, and restored
them on leaving the function.
I doubt that a C implementation could use this trick, however. It
would get into trouble as soon as you took the address of a local
variable.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
John Potter
>
> John Potter wrote:
> >
> > His memory may be fine. Implementations have used static rather than
> > stack space for local arrays. As long as there is no recursion it
>
> How could the compiler know if there is recursion?
> How can the compiler know that it can not allocate the local array
> statically? Maybe as soon as it sees that the function does call
> another function it would allocate it on the stack? (sounds like
> too twisted a solution for so little gain, mainly given that 99.99%
> of the times, a function will indeed call another function)
Consider the static bool which is used to control initialization of a
local static. A static counter can be used to detect a call while
another is still active. The first invocation uses the static and
others will use the stack. Considering that recursion with a local
array is unusual, it could be a win on a system with limited stack
space such as dos.
But, maybe I am also dreaming about something that never happened.
John
John Potter
<neil_but...@lineone.net> wrote:
> "John Potter" <jpo...@falcon.lhup.edu> wrote in message
> news:3aa2467b...@news.csrlink.net...
> > On 4 Mar 2001 05:23:31 -0500, Francis Glassborow
> > <francis.g...@ntlworld.com> wrote:
> >
> > > In article <3A9B98A0...@divalsim.it>, Nicola Musatti
> > > <obje...@divalsim.it> writes
> > > >Is it my memory playing tricks or local arrays in C used to be static?
> > > >This might explain the misconception...
> > >
> > > Your memory, I think, is playing tricks on you.
> >
> > His memory may be fine. Implementations have used static rather than
> > stack space for local arrays. As long as there is no recursion it
> > will work and a conforming program will never know.
>
> And as long as the program is single-threaded, which of course a conforming
> compiler need not address but which a practical one must.
>
> > Not that the
> > standard said they were static, just that an implementation can get
> > away with it if careful.
>
> Can you name an implementation that did this?
Nope. Maybe Nicola and I both visited another universe where this
happened. It is curious that we both remember arrays being allocated
differently from scalars somewhere. Maybe another language or just
another time. Anyone with a better memory?
John
John Potter
<francis.g...@ntlworld.com> wrote:
> Where a compiler places an auto array is entirely its choice. If that
> happens to be in a static area, it better make sure that there is no
> recursion possible and that would seem an awful lot of work. However I
> know of quite a few compilers that did not put auto arrays in a stack
> frame but used an entirely different pool of memory. My point is that C
> never specified this kind of behaviour, though it never forbade it.
Well said. I think we are in agreement. It is semantics. My problem
is in using the common view of *the* stack of contiguous memory and
*the* heap leaving *the* static. As you have pointed out, there is
no requirement that automatics be in a stack, they are just automatics.
In another article, you stated that the implementation may not
implicitely call the new expression as proof that an automatic array
could not be in the heap. Could you give me a reference for this?
Does this imply that an implementation without a hardware stack which
uses a linked list of stack frames may not call malloc to allocate
the frames?
John
Francis Glassborow
<jpo...@falcon.lhup.edu> writes
>> Can you name an implementation that did this?
>
>Nope. Maybe Nicola and I both visited another universe where this
>happened. It is curious that we both remember arrays being allocated
>differently from scalars somewhere. Maybe another language or just
>another time. Anyone with a better memory?
Oh, they were certainly allocated differently on some systems (I think
that Salford Software's C compiler in full debug mode did that)
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Nicola Musatti
John Potter wrote:
[...]
> Nope. Maybe Nicola and I both visited another universe where this
> happened. It is curious that we both remember arrays being allocated
> differently from scalars somewhere. Maybe another language or just
> another time. Anyone with a better memory?
I even pulled my battered copy of K&R1 out of the bookshelf and,
obviously enough, there was no trace supporting my conviction. Now I'm
trying to understand why I thought what I thought; maybe it is connected
with the fact that arrays are not passed by value or learning of the use
of "static" on local variables... Who knows?
Best regards,
Nicola Musatti
James Kanze
> On 5 Mar 2001 07:59:05 -0500, Francis Glassborow
> <francis.g...@ntlworld.com> wrote:
> > Where a compiler places an auto array is entirely its choice. If
> > that happens to be in a static area, it better make sure that
> > there is no recursion possible and that would seem an awful lot of
> > work. However I know of quite a few compilers that did not put
> > auto arrays in a stack frame but used an entirely different pool
> > of memory. My point is that C never specified this kind of
> > behaviour, though it never forbade it.
> Well said. I think we are in agreement. It is semantics. My
> problem is in using the common view of *the* stack of contiguous
> memory and *the* heap leaving *the* static. As you have pointed
> out, there is no requirement that automatics be in a stack, they are
> just automatics.
The C++ standard speaks of the lifetime of variables. It says nothing
about *where* they are.
I once used a C compiler on a machine without a stack. The compiler
basically implemented its stack as a linked list of malloc'ed blocks.
The distinction between stack and heap was tenuous at best. (In
practice, the compiler was just barely usable, because run-time
overhead for a function call was so high.)
> In another article, you stated that the implementation may not
> implicitely call the new expression as proof that an automatic array
> could not be in the heap. Could you give me a reference for this?
The user can replace operator new. The replacement may contain
"observable behavior". The implementation cannot just introduce
observable behavior because it feels like it.
An implementation *can* implicitly call malloc to obtain the memory,
because the user does not have the right to replace that function.
> Does this imply that an implementation without a hardware stack
> which uses a linked list of stack frames may not call malloc to
> allocate the frames?
Malloc, yes. Operator new, no.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Francis Glassborow
<jpo...@falcon.lhup.edu> writes
>In another article, you stated that the implementation may not
>implicitely call the new expression as proof that an automatic array
>could not be in the heap. Could you give me a reference for this?
I wish I could, but I am still not as nimble with the Standard as I
should be, but I distinctly recall this issue being discussed back in 96
or there abouts, because the question was what would happen if operator
new was replaced by a user written version (at global scope) and the
decision I remember was that operator new was strictly in the user
domain.
>
>Does this imply that an implementation without a hardware stack which
>uses a linked list of stack frames may not call malloc to allocate
>the frames?
But malloc is different because that is strictly in the implementation
domain (needs to be so that we can comfortably write global over-riders
for operator new and operator new[].
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Carlos Moreno
>
> > How could the compiler know if there is recursion?
>
> > How can the compiler know that it can not allocate the local array
> > statically? Maybe as soon as it sees that the function does call
> > another function it would allocate it on the stack? (sounds like
> > too twisted a solution for so little gain, mainly given that 99.99%
> > of the times, a function will indeed call another function)
>
> Consider the static bool which is used to control initialization of a
> local static. A static counter can be used to detect a call while
> another is still active.
I'm soooo dumb!! :-)
See, I'd be tempted to blame you for always making me feel so
dumb... But I asked for it! :-)
Carlos
--
Luis Pedro Coelho
There is a very important difference between calling malloc() and calling
operator new(): operator new() can be overriden by the user. So I cannot
detect in a standard program whether malloc gets called, but I can detect
whether operator new() gets called by overriding it.
The implementation can do whatever it wants if you cannot detect it.
{ BTW: is it my newsserver or has the volume of this ng dropped
dramatically in the last week ? }
Regards,
--
Luis Pedro Coelho.
Check out my game of Hearts, a card game, for KDE at:
http://www.geocities.com/deepblack9/index.html
Carlos Moreno
> { BTW: is it my newsserver or has the volume of this ng dropped
> dramatically in the last week ? }
I don't know, but a few messages that I sent didn't make it to the
newsgroup, and I'm positive that in these instances it wasn't
because they were explicitly rejected by the moderators -- they
were very on-topic, nothing trivial or redundant, and very
respectful (as my messages always are, of course... ;-))
I don't know how the process of routing NG messages work, but
is it possible that there is some sort of bottleneck and there
is a temporary problem at a critical point?
Carlos
--
PS: I know that it's not specifically my news client or my ISP,
since some other messages that I sent did make it to the
newsgroup...
Michiel Salters
>Andrew Koenig wrote:
>>
>> > I would like to know where the "auto" arrays are allocated in memory. Is it
>> > implicitly allocated in heap through *new* operator ?
>>
>> No, they're allocated on the heap.
>
>Did you mean to write "they're not allocated on the heap" and it was
>just a typo?
>
>Or am I completely wrong in thinking that it would be almost impossible
>for a compiler to allocate auto-arrays on the heap? (the compiler would
>have to "manually" implement its own stack of allocated space on the
>heap -- otherwise, how would it implement a recursive function that
>uses a local array?)
I think it's a mistake - usually they will be allocated on the/a stack.
But technically, I think a compiler can put a pointer on the stack, and
call ::operator new() under water. Recursive functions have
multiple stack frames and could have multiple pointers to arrays.
( any user-defined operator new should be ignored, though. )
This might be useful for systems with relatively small stacks (say, 64K
stacks max due to HW limits but 4Gb heap).
Regards,
Michiel Salters
Francis Glassborow
<Michiel...@cmg.nl> writes
>I think it's a mistake - usually they will be allocated on the/a stack.
>But technically, I think a compiler can put a pointer on the stack, and
>call ::operator new() under water.
No, it must not do that. It can allocate memory from where-ever it likes
but it must not call ::operator new(). The reason is that that function
is user replaceable which could break such usage by the compiler.
--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dave Harris
> I think it's a mistake - usually they will be allocated on the/a stack.
> But technically, I think a compiler can put a pointer on the stack, and
> call ::operator new() under water. Recursive functions have
> multiple stack frames and could have multiple pointers to arrays.
> ( any user-defined operator new should be ignored, though. )
>
> This might be useful for systems with relatively small stacks (say, 64K
> stacks max due to HW limits but 4Gb heap).
It can also improve locality of reference.
Typically a stack frame contains a handful of local variables which are
frequently accessed - eg a vector<> is the size of 3 or 4 pointers. With
an array of say, 1024 elements, each element will be accessed much less
often than, eg, the index variable used to point to them. Putting such
large objects into a separate memory area can keep the rest of the stack
small and less likely to be spilled from hardware caches.
Or so I'm told. I've not measured it myself. It's worth remembering that
allocation will be stack-like - first-in, last-out - where ever it is
stored, so a special arena like a software stack might be cheaper than
raw malloc/new. Allocation is incrementing a pointer, deallocation is
decrementing it. This would get around hardware limits.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."