storage locations for different data types

**Mike Wahler** · Jul 22 '05, 11:38 PM

Re: storage locations for different data types

<smith4894@exci te.com> wrote in message
news:1105469158 .941016.163120@ c13g2000cwb.goo glegroups.com.. .[color=blue]
> Hello,
>
> I have a question regarding storage locations for different data types.
> For example, dynamically created objects (using "new") are created on
> the heap. local objects ( foo() {int x;} ) are on the stack.
>
> 1)Where are global non-const objects created?
>
> 2)Where are global const objects created?
>
> 3)For a function, where are local static objects created? These objects
> are not initialized until the function is called, but is storage
> allocated for them even if they are never called?
>
> 4)For a function, where are const type objects created? on the stack as
> well?
>
> 5)For a class, where are static class member objects created?[/color]

None of the above things are specified by the language,
but are implementation-specific details. C++ does not
define or require anything such as 'heap', 'stack', etc.
If you want to know how your particular implementation
handles these things, you'll need to consult its documentation
and/or any available support resources provided by its
vendor.

Anyway, why do you feel you need to know these things?

-Mike

**Maciej Sobczak** · Jul 22 '05, 11:38 PM

Re: storage locations for different data types

Hi,

smith4894@excit e.com wrote:
[color=blue]
> For example, dynamically created objects (using "new") are created on
> the heap. local objects ( foo() {int x;} ) are on the stack.[/color]

We say that these objects have the "dynamic storage duration" and the
"automatic storage duration".
[color=blue]
> 1)Where are global non-const objects created?[/color]

In some other place, which is a "static storage".
Typically, the memory for all objects with static storage duration
(collectively) is assigned to the process when the program is loaded
into memory. Alternatively, it may be even part of the program (of the
file on disk) itself, but any other strategy is allowed, as long as the
lifetimes of the objects obey the rules. It all depends on implementation.
[color=blue]
> 2)Where are global const objects created?[/color]

Same as global non-const. This is static storage.
The const qualifier affects only what you can do with them, not where
they are.
[color=blue]
> 3)For a function, where are local static objects created? These objects
> are not initialized until the function is called, but is storage
> allocated for them even if they are never called?[/color]

Again, static storage.
[color=blue]
> 4)For a function, where are const type objects created? on the stack as
> well?[/color]

If they are local, then they have automatic storage, on the stack.
Again, the const qualifier does not affect where they are.
[color=blue]
> 5)For a class, where are static class member objects created?[/color]

Static storage.

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

**Emil Kirichev** · Jul 22 '05, 11:38 PM

Re: storage locations for different data types

I'm answering the second question. One way to do this is to make your
base class abstract. That is, make it interface with pure virtual
functions only. All classes that inherit the this class, must implement
the interface (all virtual functions). That way, you declare some in
your program, a function that acepts a pointer to that base class:
some_function(B ase* pb); You can pass the address of an object of some
of the child classes, but in that function you have to use only the
interface that is declared in the base class. Every child has its own
implementation of the interface so the image work will be done
according the obejct you pass to the function (gif, jpg, etc.) . That
eliminates the need of checking what image object you are dealing with
(it's called polimorphism). Example:

class Image
{
public:
virual void proccess_image( ) = 0;
virtual void other_func() = 0;
}

class gif: public Image
{
void proccess_image( );
void other_func();
}
void f(Image* pimg)
{
pimg->proccess_imge( );
}
in your prog:

gif g;
f(&g);

Hope that's what you want.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

**kanze@gabi-soft.fr** · Jul 22 '05, 11:39 PM

Re: storage locations for different data types

Maciej Sobczak wrote:
[color=blue]
> smith4894@excit e.com wrote:[/color]
[color=blue][color=green]
> > For example, dynamically created objects (using "new") are
> > created on the heap. local objects ( foo() {int x;} ) are on
> > the stack.[/color][/color]
[color=blue]
> We say that these objects have the "dynamic storage duration"
> and the "automatic storage duration".[/color]

In the standard. In practice, heap and stack are usable
synonyms.

Let's not forget, either, that the compiler is not required to
use a contiguous area for any of these. It could very well use
different areas for operator new, operator new[] and malloc, for
example, or allocate stack frames dynamically from the same pool
that malloc uses. (I've actually used a C compiler which did
this.)
[color=blue][color=green]
> > 1)Where are global non-const objects created?[/color][/color]
[color=blue]
> In some other place, which is a "static storage". Typically,
> the memory for all objects with static storage duration
> (collectively) is assigned to the process when the program is
> loaded into memory. Alternatively, it may be even part of the
> program (of the file on disk) itself, but any other strategy
> is allowed, as long as the lifetimes of the objects obey the
> rules. It all depends on implementation.[/color]

Typically, the compiler will manage two separate "static"
areas, one of which will be write protected when your program
executes (and probably shared amongst multiple instances which
execute simutaneously).
[color=blue][color=green]
> > 2)Where are global const objects created?[/color][/color]
[color=blue]
> Same as global non-const. This is static storage. The const
> qualifier affects only what you can do with them, not where
> they are.[/color]

With the compilers I use, it depends on the type of the object.
If the object has dynamic initialization or a non-trivial
destructor, it will be allocated with the other static objects.
If it is statically initialized, it will normally be allocated
in the write protected part of the static memory. And if it is
simple enough, and its address is never taken, it might not be
allocated at all.
[color=blue][color=green]
> > 3)For a function, where are local static objects created?
> > These objects are not initialized until the function is
> > called, but is storage allocated for them even if they are
> > never called?[/color][/color]
[color=blue]
> Again, static storage.[/color]

With the same caveats as above.
[color=blue][color=green]
> > 4)For a function, where are const type objects created? on
> > the stack as well?[/color][/color]
[color=blue]
> If they are local, then they have automatic storage, on the
> stack. Again, the const qualifier does not affect where they
> are.[/color]

If the type is simple enough, and the address of the object is
never taken, the object probably will not be allocated at all.
Otherwise, if the object is initialized with a constant
expression, and has a trivial constructor and destructor, it
will most likely be allocated in the write protected static
memory -- most likely, because if the address of the object is
taken, and the function is called recursively, this cannot be
done, since the addresses have to differ.
[color=blue][color=green]
> > 5)For a class, where are static class member objects created?[/color][/color]
[color=blue]
> Static storage.[/color]

With all of the above caveats, of course.

And of course, we're only considering single threaded programs
without dynamically loaded objects here.

In fact, of course, the correct answer for all of the above
questions is really: where ever the compiler wants:-).

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

**Allan W** · Jul 22 '05, 11:39 PM

Re: storage locations for different data types

> smith4894@excit e.com wrote:[color=blue][color=green]
> > 1)Where are global non-const objects created?[/color][/color]

Maciej Sobczak wrote:[color=blue]
> In some other place, which is a "static storage".
> Typically, the memory for all objects with static storage duration
> (collectively) is assigned to the process when the program is loaded
> into memory. Alternatively, it may be even part of the program (of[/color]
the[color=blue]
> file on disk) itself, but any other strategy is allowed, as long as[/color]
the[color=blue]
> lifetimes of the objects obey the rules. It all depends on[/color]
implementation.[color=blue]
>[color=green]
> > 2)Where are global const objects created?[/color]
>
> Same as global non-const. This is static storage.
> The const qualifier affects only what you can do with them, not where
> they are.[/color]

I realize that you're answering a beginner's question, so you don't
want to get too technical. But I think it's important to point out
that const statics CAN be treated differently from non-const statics.
The definitive example is that embedded systems, where const statics
can be put into read-only memory, along with the program code. But it
isn't just embedded systems. A system with protected memory could
put a const object (even a const auto object) into a section of
memory, and then write-lock that section of memory until it's time
to run the destructor.

That's the main reason for the limitations on const_cast: If you cast
a pointer-to-const into a pointer-to-non-const, and the object truely
was a const object, you get undefined behavior.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

**Maciej Sobczak** · Jul 22 '05, 11:41 PM

Re: storage locations for different data types

Hi,

kanze@gabi-soft.fr wrote:
[color=blue]
> In fact, of course, the correct answer for all of the above
> questions is really: where ever the compiler wants:-).[/color]

Yes, and that's why it should be preferred to talk about storage
duration (static / dynamic / automatic) instead of storage "place" (text
or global / heap / stack).

(Interestingly, temporary objects have automatic storage duration, but
they need not be on the "stack" - this applies especially to exception
objects - so there is no clear correspondence between these concepts.)

I remember extensive discussions (on clcm) about the name "heap". Some
use it to mean the storage place (where new and malloc operate), some
others to mean a data structure - and this is how it is used in the
standard.
Similarly, a "stack" is used to usually mean a *continuous*, growing or
shrinking array of function frames, but it may be a hidden linked list
on the "heap" instead (and I guess that this is how it was implemented
in the C compiler that you mentioned).

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

**James Kanze** · Jul 22 '05, 11:42 PM

Re: storage locations for different data types

Maciej Sobczak wrote:
[color=blue]
> kanze@gabi-soft.fr wrote:[/color]
[color=blue][color=green]
>>In fact, of course, the correct answer for all of the above
>>questions is really: where ever the compiler wants:-).[/color][/color]
[color=blue]
> Yes, and that's why it should be preferred to talk about
> storage duration (static / dynamic / automatic) instead of
> storage "place" (text or global / heap / stack).[/color]

To which we might add that we are talking about a guaranteed
minimum storage duration. Since a legal program cannot
determine when the memory is really freed, the implementation
has total freedom.
[color=blue]
> (Interestingly, temporary objects have automatic storage
> duration, but they need not be on the "stack" - this applies
> especially to exception objects - so there is no clear
> correspondence between these concepts.)[/color]

Glad you mentionned that. Althought the standard speaks of
three durations (static, dynamic and automatic), there are a
couple of more which pop up from time to time. Temporary is
one -- the lifetime of a temporary ends at the end of the full
expression in which it occurs (modulo a couple of exceptions),
not at the end of the scope in which it was declared (which is
the case for automatic). And of course, exceptions have a
lifetime of their own.
[color=blue]
> I remember extensive discussions (on clcm) about the name
> "heap". Some use it to mean the storage place (where new and
> malloc operate), some others to mean a data structure - and
> this is how it is used in the standard.[/color]

One doesn't exclude the other. The context is usually
sufficient to know which one is meant.
[color=blue]
> Similarly, a "stack" is used to usually mean a *continuous*,
> growing or shrinking array of function frames, but it may be a
> hidden linked list on the "heap" instead (and I guess that
> this is how it was implemented in the C compiler that you
> mentioned).[/color]

Yep. Can't say that it did much for performance, though.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

storage locations for different data types

storage locations for different data types

Comment

Comment

Comment

Comment

Comment

Comment

Comment