tricky pointer and string storage question

[david wolf]

I have a function called
void f(){
char * tmp = "abc";
static * tmp1 = "abcd";
}

Can anyone tell me
1)whether pointer tmp is stored in stack or heap?
2)whether string "abc" of length 4 bytes is stored in stack or help?
3)whether pointer tmp1 is stored in stack or heap?
4)whether string "abcd" of length 5 bytes is stored in stack or help?

Thanks,

David

[red floyd]

david wolf wrote:

I have a function called
void f(){
char * tmp = "abc";
static * tmp1 = "abcd";
}

Can anyone tell me
1)whether pointer tmp is stored in stack or heap?
2)whether string "abc" of length 4 bytes is stored in stack or help?
3)whether pointer tmp1 is stored in stack or heap?
4)whether string "abcd" of length 5 bytes is stored in stack or help?

Looks like homework, and the declaration of tmp1 is invalid.

[Victor Bazarov]

david wolf wrote:

I have a function called
void f(){
char * tmp = "abc";
While this is syntactically correct and semantically allowed, it is
a bad idea to initialise a pointer to non-const char with a literal.
static * tmp1 = "abcd";
The type is missing here. Syntax error.
}

Can anyone tell me
1)whether pointer tmp is stored in stack or heap?
That is unspecified. 'tmp' is _automatic_ and has _automatic_ storage
duration.
2)whether string "abc" of length 4 bytes is stored in stack or help?
Again, this is unspecified.
3)whether pointer tmp1 is stored in stack or heap?
The code doesn't compile, however, corrected to

static char const * tmp1 = "abcd";

it gives 'tmp1' _static_ storage duration. Where it is allocated is,
again, unspecified.
4)whether string "abcd" of length 5 bytes is stored in stack or help?

That's unspecified.

Things like "stack" or "heap" do not really exist in the language. They
are _implementation _details_ and should be talked about in a newsgroup
dedicated to your implementation.

V

[Alf P. Steinbach]

* Victor Bazarov:

Things like "stack" or "heap" do not really exist in the language. They
are _implementation _details_ and should be talked about in a newsgroup
dedicated to your implementation.

Do you know of a C++ implementation that where 'auto' is not equivalent
to stack-based, or where ordinary 'new' doesn't allocate from a heap?

Literally you're probably correct, I don't bother checking.

As a matter of practice it is, however, a meaningless distinction.

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

[Victor Bazarov]

Alf P. Steinbach wrote:

* Victor Bazarov:

Things like "stack" or "heap" do not really exist in the language. They
are _implementation _details_ and should be talked about in a newsgroup
dedicated to your implementation.

Do you know of a C++ implementation that where 'auto' is not equivalent
to stack-based, or where ordinary 'new' doesn't allocate from a heap?

Literally you're probably correct, I don't bother checking.

As a matter of practice it is, however, a meaningless distinction.

"Meaningles s distinction" between what ant what? Between stack and heap?
In the language Standard the two places where you should find 'stack' and
'heap' are the library templates and functions (namely, 'std::stack' and
'std::make_heap '). There are no other places. Whether or not there exist
implementations that do something different is irrelevant.

BTW, on some operating systems I've encountered, "stack" was actually
allocated on the "heap" [at program loading]. Now, how you attach heap
(where "ordinary 'new'" allocates), to the OP's question, I am not sure.
And how do you answer the question about the literals in terms of stack
and heap I am not sure either because on some systems they can be on the
stack and on some they will be in a constant data segment (not stack or
heap at all). Also, the location of static data and what you call "heap"
(C++ uses the term "free store") are not necessarily the same either.

So, whatever they teach to those kids in the school the OP attends, has
nothing to do with the language itself and everything to do with their
specific implementation of the language on their specific platform. And
we cannot help the OP, he would have to look in the textbooks his teacher
recommended. The validity of those textbooks is beyond the limits of this
thread.

IMNSHO.

V

[Alf P. Steinbach]

* Victor Bazarov:

Alf P. Steinbach wrote:

* Victor Bazarov:

Things like "stack" or "heap" do not really exist in the language. They
are _implementation _details_ and should be talked about in a newsgroup
dedicated to your implementation.

Do you know of a C++ implementation that where 'auto' is not equivalent
to stack-based, or where ordinary 'new' doesn't allocate from a heap?

Literally you're probably correct, I don't bother checking.

As a matter of practice it is, however, a meaningless distinction.

"Meaningles s distinction" between what ant what? Between stack and heap?

Between 'auto' and "stack-based", and between the area allocated by 'new'
and "heap-based".

In the language Standard the two places where you should find 'stack' and
'heap' are the library templates and functions (namely, 'std::stack' and
'std::make_heap '). There are no other places. Whether or not there exist
implementations that do something different is irrelevant.
There are even more meanings of the words, and nearly all of them as
irrelevant as the two you chose here.

BTW, on some operating systems I've encountered, "stack" was actually
allocated on the "heap" [at program loading].
That, if true, would also be irrelevant. From the program's point of
view there is a stack and how it was allocated isn't an issue at all.

Now, how you attach heap
(where "ordinary 'new'" allocates), to the OP's question, I am not sure.
To refresh your memory: it was mentioned by the OP and by you.

And how do you answer the question about the literals in terms of stack
and heap I am not sure either because on some systems they can be on the
stack and on some they will be in a constant data segment (not stack or
heap at all).
Questions 2, 3 and 4 are meaningless.

Also, the location of static data and what you call "heap"
(C++ uses the term "free store") are not necessarily the same either.
?

First of all, the heap is not a location, it is a set of locations accessed
via a set of functions. Second, static data are not heap-allocated. That's
part of the meaning of "static" (not the C++ keyword).

So, whatever they teach to those kids in the school the OP attends, has
nothing to do with the language itself and everything to do with their
specific implementation of the language on their specific platform. And
we cannot help the OP, he would have to look in the textbooks his teacher
recommended. The validity of those textbooks is beyond the limits of this
thread.

I would be surprised if this turned out to be directly quoted homework.

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

[Victor Bazarov]

Alf P. Steinbach wrote:

[..]
I would be surprised if this turned out to be directly quoted homework.

Really? I wouldn't.

[David White]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:ZS******** ***********@new sread1.mlpsca01 .us.to.verio.ne t...

Things like "stack" or "heap" do not really exist in the language. They
are _implementation _details_ and should be talked about in a newsgroup
dedicated to your implementation.

Although you are right, I really think you're swimming against the tide on
this. There are numerous references to "stack" and "heap" in the C++ FAQ.
And Stroustrup's TC++PL describes "heap" as a synonym for "free store" and
"on the stack" as a synonym for "auto". Not to mention all the people here
who use "stack" and "heap" in their answers. For better or worse, these
terms are entrenched.

DW

[david wolf]

Victor Bazarov wrote:

Alf P. Steinbach wrote:

[..]
I would be surprised if this turned out to be directly quoted

homework.
Really? I wouldn't.

Thanks for your reply. BTW, it's not homework.