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

[jimjim]

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

 

[Victor Bazarov]

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

 

[davidrubin]

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]

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

 

[Victor Bazarov]

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

 

[Alf P. Steinbach]

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

 

[jimjim]

thx for the reply

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

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

 

[jimjim]

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

 

[Victor Bazarov]

Thx for the reply


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.

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

 

[John Carson]

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

 

[jimjim]

thx

 

[jimjim]

thx

 

[Ron Natalie]

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.