storage locations for different data types

Discussion in 'C++' started by smith4894@excite.com, Jan 12, 2005.

  1. Guest

    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?

    Thanks.


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    , Jan 12, 2005
    #1
    1. Advertising

  2. Mike Wahler Guest

    <> wrote in message
    news:...
    > 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?


    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
     
    Mike Wahler, Jan 12, 2005
    #2
    1. Advertising

  3. Hi,

    wrote:

    > For example, dynamically created objects (using "new") are created on
    > the heap. local objects ( foo() {int x;} ) are on the stack.


    We say that these objects have the "dynamic storage duration" and the
    "automatic storage duration".

    > 1)Where are global non-const objects created?


    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.

    > 2)Where are global const objects created?


    Same as global non-const. This is static storage.
    The const qualifier affects only what you can do with them, not where
    they are.

    > 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?


    Again, static storage.

    > 4)For a function, where are const type objects created? on the stack as
    > well?


    If they are local, then they have automatic storage, on the stack.
    Again, the const qualifier does not affect where they are.

    > 5)For a class, where are static class member objects created?


    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++.moderated. First time posters: Do this! ]
     
    Maciej Sobczak, Jan 13, 2005
    #3
  4. 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(Base* 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++.moderated. First time posters: Do this! ]
     
    Emil Kirichev, Jan 13, 2005
    #4
  5. Guest

    Maciej Sobczak wrote:

    > wrote:


    > > For example, dynamically created objects (using "new") are
    > > created on the heap. local objects ( foo() {int x;} ) are on
    > > the stack.


    > We say that these objects have the "dynamic storage duration"
    > and the "automatic storage duration".


    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.)

    > > 1)Where are global non-const objects created?


    > 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.


    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).

    > > 2)Where are global const objects created?


    > Same as global non-const. This is static storage. The const
    > qualifier affects only what you can do with them, not where
    > they are.


    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.

    > > 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?


    > Again, static storage.


    With the same caveats as above.

    > > 4)For a function, where are const type objects created? on
    > > the stack as well?


    > If they are local, then they have automatic storage, on the
    > stack. Again, the const qualifier does not affect where they
    > are.


    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.

    > > 5)For a class, where are static class member objects created?


    > Static storage.


    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 objektorientierter Datenverarbeitung
    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++.moderated. First time posters: Do this! ]
     
    , Jan 13, 2005
    #5
  6. Allan W Guest

    > wrote:
    > > 1)Where are global non-const objects created?


    Maciej Sobczak wrote:
    > 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.
    >
    > > 2)Where are global const objects created?

    >
    > Same as global non-const. This is static storage.
    > The const qualifier affects only what you can do with them, not where
    > they are.


    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++.moderated. First time posters: Do this! ]
     
    Allan W, Jan 13, 2005
    #6
  7. Hi,

    wrote:

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


    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++.moderated. First time posters: Do this! ]
     
    Maciej Sobczak, Jan 15, 2005
    #7
  8. James Kanze Guest

    Maciej Sobczak wrote:

    > wrote:


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


    > 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).


    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.

    > (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.)


    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.

    > 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.


    One doesn't exclude the other. The context is usually
    sufficient to know which one is meant.

    > 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).


    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 objektorientierter Datenverarbeitung
    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++.moderated. First time posters: Do this! ]
     
    James Kanze, Jan 16, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sam-I-Am
    Replies:
    2
    Views:
    293
    Steven Cheng[MSFT]
    May 11, 2004
  2. =?Utf-8?B?TWF0dA==?=
    Replies:
    0
    Views:
    369
    =?Utf-8?B?TWF0dA==?=
    May 20, 2004
  3. =?Utf-8?B?TWF0dA==?=
    Replies:
    3
    Views:
    511
    Mike Smith
    Jul 20, 2004
  4. =?Utf-8?B?TWF0dA==?=
    Replies:
    0
    Views:
    333
    =?Utf-8?B?TWF0dA==?=
    Jul 20, 2004
  5. sarathy
    Replies:
    2
    Views:
    678
    sarathy
    Jul 17, 2006
Loading...

Share This Page