are the objects created in the stack guarranted to have been created?

Discussion in 'C++' started by jimjim, Jun 2, 2005.

  1. jimjim

    jimjim Guest

    Hello,

    1. As the subject sugests, are the objects created in the stack guarranted
    to have been created?
    2. How can I verify this? (e.g. for objects created in the heap A *a = new A
    one can check as: if ( a == NULL), or try to catch the bad_alloc exception)

    TIA
    jimjim, Jun 2, 2005
    #1
    1. Advertising

  2. Re: are the objects created in the stack guarranted to have beencreated?

    jimjim wrote:
    > 1. As the subject sugests, are the objects created in the stack guarranted
    > to have been created?


    What does this question mean? Are black stones black?

    > 2. How can I verify this? (e.g. for objects created in the heap A *a = new A
    > one can check as: if ( a == NULL), or try to catch the bad_alloc exception)


    Right. But that doesn't mean they are created, does it? If no exception
    occurs, you only can be sure that the memory was allocated, at least if
    I follow your logic about "created in the stack"...

    V
    Victor Bazarov, Jun 2, 2005
    #2
    1. Advertising

  3. jimjim

    Guest

    jimjim wrote:
    > Hello,
    >
    > 1. As the subject sugests, are the objects created in the stack guarranted
    > to have been created?


    The applicable constructor is guaranteed to be called. Whether or not
    this leaves your object in a well-defined state is up to you, if you
    are the implementor.

    > 2. How can I verify this? (e.g. for objects created in the heap A *a = new A
    > one can check as: if ( a == NULL), or try to catch the bad_alloc exception)


    Presumably, your question is really about dynamically allocated data
    members. You must throw (or catch) an exception, or provide an
    'isValid' method.

    /david
    , Jun 2, 2005
    #3
  4. jimjim

    jimjim Guest

    Sorry guys I did not explain myself well.

    Once again:

    When you create objects dynamically (A *a = new A), there is the case that
    the heap may become exhausted and therefore any effort to create objects
    will "fail" (memory wont be allocated). For this reason, you ought to check
    whether a == NULL, or try to catch the bad_alloc exception that is thrown
    by the new operator.

    When you create objects on the stack should I assume that the memory
    allocated to the stack segment may become exhausted as well? If the anwer to
    the question is positive, how can I check if the objects I tried to create
    are indeed created (i.e. just like I did for dynamic allocation of memory
    b4)?

    TIA

    <> wrote in message
    news:...
    >
    >
    > jimjim wrote:
    >> Hello,
    >>
    >> 1. As the subject sugests, are the objects created in the stack
    >> guarranted
    >> to have been created?

    >
    > The applicable constructor is guaranteed to be called. Whether or not
    > this leaves your object in a well-defined state is up to you, if you
    > are the implementor.
    >
    >> 2. How can I verify this? (e.g. for objects created in the heap A *a =
    >> new A
    >> one can check as: if ( a == NULL), or try to catch the bad_alloc
    >> exception)

    >
    > Presumably, your question is really about dynamically allocated data
    > members. You must throw (or catch) an exception, or provide an
    > 'isValid' method.
    >
    > /david
    >
    jimjim, Jun 2, 2005
    #4
  5. Re: are the objects created in the stack guarranted to have beencreated?

    jimjim wrote:
    > Once again:
    >
    > When you create objects dynamically (A *a = new A), there is the case that
    > the heap may become exhausted and therefore any effort to create objects
    > will "fail" (memory wont be allocated). For this reason, you ought to check
    > whether a == NULL, or try to catch the bad_alloc exception that is thrown
    > by the new operator.
    >
    > When you create objects on the stack should I assume that the memory
    > allocated to the stack segment may become exhausted as well? If the anwer to
    > the question is positive, how can I check if the objects I tried to create
    > are indeed created (i.e. just like I did for dynamic allocation of memory
    > b4)?
    >


    Please try not to top-post. If the message you're replying to is
    irrelevant (and no need to read it before seeing your comments), please
    consider trimming it away.

    Yes, stack can become exhausted. That's where you get "stack overflow"
    problems, like with too deep a recursion. However, those problems only
    exists on the systems where there is a stack, and if such condition
    arises, any further execution of the program is usually impossible and
    some kind of exception is "thrown".

    C++ does not have any mechanisms to check how close the "stack" is to
    its exhaustion, since the virtual machine on which C++ programs execute
    does not have any particular "stack" implementation. We only know that
    automatic variables (objects too) are created somewhere and fully
    constructed by the time we need them. There is no additional check
    necessary (or possible) to verify that when you reached a point in your
    program _after_ an automatic object is defined and initialised, that
    object is OK. IOW, it is OK since your program reached that point.

    I guess you need to read a decent book that explains the difference
    between objects with static storage duration, automatic storage duration
    and dynamic storage duration. What book are you currently reading, BTW?

    V
    Victor Bazarov, Jun 2, 2005
    #5
  6. * jimjim:
    > [top-posting, extranous quoting]


    Please don't top post in this group.

    Please don't quote irrelevant material.

    Corrected.

    > Sorry guys I did not explain myself well.
    >
    > Once again:
    >
    > When you create objects dynamically (A *a = new A), there is the case that
    > the heap may become exhausted and therefore any effort to create objects
    > will "fail" (memory wont be allocated). For this reason, you ought to check
    > whether a == NULL, or try to catch the bad_alloc exception that is thrown
    > by the new operator.


    To be precise, in standard C++ you're guaranteed a bad_alloc exception,
    but some older compilers erronously return NULL instead.


    > When you create objects on the stack should I assume that the memory
    > allocated to the stack segment may become exhausted as well?


    Yes. Don't put large things on the stack. Ensure there's enough stack
    space.


    > If the anwer to
    > the question is positive, how can I check if the objects I tried to create
    > are indeed created (i.e. just like I did for dynamic allocation of memory
    > b4)?


    You can't, in any portable way.

    If you get stack overflow you (or rather, your program ;-) ) is doomed,
    because the stack may then be corrupted so that recovery is impossible.

    Modern compilers can help out by including stack checking code in debug
    builds, and the OS can help out by only committing memory pages as needed
    so that you in principle can specify a very large stack.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Jun 2, 2005
    #6
  7. jimjim

    jimjim Guest

    thx for the reply

    >> When you create objects on the stack should I assume that the memory
    >> allocated to the stack segment may become exhausted as well?

    >
    > Yes. Don't put large things on the stack. Ensure there's enough stack
    > space.
    >

    Why shouldnt I place large things on the stack? Do you imply that I should
    create them in the heap for some reason (e.g. heap_memory >> stack_memory) ?

    > If you get stack overflow you (or rather, your program ;-) ) is doomed,
    > because the stack may then be corrupted so that recovery is impossible.
    >

    Where does this "stack overflow" appears?

    TIA

    P.S: I am used to reading posts on the usenet as follows, which makes quite
    a lot of sense to me. Which news client are you using? Is what you are
    asking documented in the C++_faq?

    Q: What is the most annoying thing on usenet and in e-mail?

    A: Top-posting.
    > Q: What is the most annoying thing on usenet and in e-mail?


    Q: Why is it such a bad thing?
    >A: Top-posting
    >>Q: What is the most annoying thing on usenet and in e-mail?


    A: Because it messes up the order in which people normally read text.

    >Q: Why is it such a bad thing?
    >>A: Top-posting
    >>>Q: What is the most annoying thing on usenet and in e-mail?
    jimjim, Jun 3, 2005
    #7
  8. jimjim

    jimjim Guest

    Thx for the reply

    > C++ does not have any mechanisms to check how close the "stack" is to
    > its exhaustion, since the virtual machine on which C++ programs execute
    > does not have any particular "stack" implementation.


    This phrazing suggests that on certain hardware platforms there may be no
    stack segment on which automatic variables are allocated to (unlike x86
    perhaps?) Can you elaborate on this, plz?

    > We only know that automatic variables (objects too) are created somewhere
    > and fully
    > constructed by the time we need them. There is no additional check
    > necessary (or possible) to verify that when you reached a point in your
    > program _after_ an automatic object is defined and initialised, that
    > object is OK. IOW, it is OK since your program reached that point.


    Why is it that C++ enables you to verify whether dynamic memory has been
    allocated properly but not about the memory allocated for automatic
    variables? (Given that such a decision is determined by certain requirements
    or restrictions).

    TIA
    jimjim, Jun 3, 2005
    #8
  9. jimjim wrote:
    > Thx for the reply
    >
    >> C++ does not have any mechanisms to check how close the "stack" is to
    >> its exhaustion, since the virtual machine on which C++ programs
    >> execute does not have any particular "stack" implementation.

    >
    > This phrazing suggests that on certain hardware platforms there may
    > be no stack segment on which automatic variables are allocated to
    > (unlike x86 perhaps?) Can you elaborate on this, plz?


    No, I can't elaborate on that. It is unspecified in the language as
    to where automatic variables are allocated and how.

    Perhaps if you ask in several hardware-specific newsgroups, you might
    be able to identify one (or more) that don't have "segments" at all
    in their memory.

    >> We only know that automatic variables (objects too) are created
    >> somewhere and fully
    >> constructed by the time we need them. There is no additional check
    >> necessary (or possible) to verify that when you reached a point in
    >> your program _after_ an automatic object is defined and initialised,
    >> that object is OK. IOW, it is OK since your program reached that
    >> point.

    >
    > Why is it that C++ enables you to verify whether dynamic memory has
    > been allocated properly but not about the memory allocated for
    > automatic variables? (Given that such a decision is determined by
    > certain requirements or restrictions).


    You will have to ask the creators and current keepers of the language
    Standard in comp.std.c++. We here talk "how", they there talk "why".

    V
    Victor Bazarov, Jun 3, 2005
    #9
  10. jimjim

    John Carson Guest

    "jimjim" <> wrote in message
    news:94Nne.44310$
    >>

    > Why shouldnt I place large things on the stack? Do you imply that I
    > should create them in the heap for some reason (e.g. heap_memory >>
    > stack_memory) ?


    By way of example, the default stack memory on a program compiled with VC++
    is 1 Mb (this can be increased with a compiler switch, but the default is an
    indication of a "normal" size). The available heap memory on a Windows box
    can be up to 2 Gb (assuming your hardware supports this). Thus with a
    typical program running on a typical desktop, the available heap memory is
    very many times larger than the available stack memory. Personally, I rarely
    allocate more than a few Kb within a function's scope. Recursive functions
    are the only ones where I might come close to the stack limit.

    Basically, if you insist on pushing up close to what is a small limit, you
    will waste a lot of your time making sure you don't go over that limit. Only
    allocate small amounts on the stack within a function and restrict your
    worrying to recursive functions.

    > Where does this "stack overflow" appears?


    That is operating system specific. Under Windows, you can use "Structured
    Exception Handling" (which is different from C++ exception handling) to
    catch it.

    >
    > TIA
    >
    > P.S: I am used to reading posts on the usenet as follows, which makes
    > quite a lot of sense to me. Which news client are you using? Is what
    > you are asking documented in the C++_faq?


    One way to find this out would be to look (there is a search facility if the
    table of contents seems daunting). As it happens, the answer is yes.

    http://www.parashift.com/c -faq-lite/how-to-post.html#faq-5.4

    --
    John Carson
    John Carson, Jun 3, 2005
    #10
  11. jimjim

    jimjim Guest

    thx
    jimjim, Jun 3, 2005
    #11
  12. jimjim

    jimjim Guest

    thx
    jimjim, Jun 3, 2005
    #12
  13. jimjim

    Ron Natalie Guest

    Re: are the objects created in the stack guarranted to have beencreated?

    jimjim wrote:
    > Hello,
    >
    > 1. As the subject sugests, are the objects created in the stack guarranted
    > to have been created?


    Yes, you'll get an exception or you'll have a created (perhaps unusable)
    object.

    > 2. How can I verify this? (e.g. for objects created in the heap A *a = new A
    > one can check as: if ( a == NULL), or try to catch the bad_alloc exception)
    >

    You can't check it that way in either case in a legitimate compiler.
    The new expression you wrote will never legally return NULL.
    Ron Natalie, Jun 3, 2005
    #13
    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. okaminer
    Replies:
    3
    Views:
    297
    okaminer
    Aug 1, 2005
  2. =?Utf-8?B?cml2YWxAbmV3c2dyb3Vwcy5ub3NwYW0=?=

    Linking events from controls, when the controls have been created

    =?Utf-8?B?cml2YWxAbmV3c2dyb3Vwcy5ub3NwYW0=?=, Jul 16, 2007, in forum: ASP .Net
    Replies:
    3
    Views:
    577
    =?Utf-8?B?cml2YWxAbmV3c2dyb3Vwcy5ub3NwYW0=?=
    Jul 16, 2007
  3. Surinder Singh
    Replies:
    1
    Views:
    1,180
    Richard Bos
    Dec 20, 2007
  4. Yan
    Replies:
    3
    Views:
    268
    Andrey Tarasevich
    Nov 19, 2008
  5. Casey Hawthorne
    Replies:
    3
    Views:
    1,070
    Flash Gordon
    Nov 1, 2009
Loading...

Share This Page