G
gsingh
Hi All
char *p="str";
How much memory will be allocated for this.
char *p="str";
How much memory will be allocated for this.
R
Richard Heathfield
gsingh said:
At least four bytes for the string literal, and sizeof p bytes for the
pointer.
At least four bytes for the string literal, and sizeof p bytes for the
pointer.
J
jk
I believe that there will be 4 bytes ('s', 't', 'r', '\0') allocated
for the string, and sizeof(char*) for the pointer (that will vary on
different systems) (the size of the pointer, though, has nothing to do
with where.or how much space the thing it is pointing to is/takes)
cheers
for the string, and sizeof(char*) for the pointer (that will vary on
different systems) (the size of the pointer, though, has nothing to do
with where.or how much space the thing it is pointing to is/takes)
cheers
L
Larry__Weiss
Richard said:
Why "at least" ? Alignment constraints?
Does sizeof include any byte-count required because of alignment?
- Larry
R
Richard Heathfield
Larry__Weiss said:
Because I couldn't remember whether the Standard required the
implementation to allocate no more memory for string literals than they
actually need, so "at least" was a safe answer.
I'd have thought that unlikely in this case, but yes, perhaps.
No, sizeof yields the exact size of its operand in bytes. (For structs,
this can include some padding bytes inserted for alignment reasons.)
Because I couldn't remember whether the Standard required the
implementation to allocate no more memory for string literals than they
actually need, so "at least" was a safe answer.
I'd have thought that unlikely in this case, but yes, perhaps.
No, sizeof yields the exact size of its operand in bytes. (For structs,
this can include some padding bytes inserted for alignment reasons.)
K
Keith Thompson
Richard Heathfield said:
It depends on what you mean by "allocated". The size of the string
literal itself (more precisely, of the static array object specified
by the string literal) is exactly 4 bytes. The compiler might reserve
some additional space before or after it in memory, for whatever
reason it likes, or for no reason at all. I'd argue that any such
space is not allocated *for* the string literal, but the standard
doesn't mention this and it's not a particularly meaningful question.
[snip]
D
Default User
jk said:
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
B
Ben Bacarisse
gsingh said:
Such questions don't have simple answers. If the compiler can detect
that 'p' is not required, it may not actually allocate any memory at
all. It is even possible (depending on the context) that the compiler
might eliminate the string literal!
You can say that 'p' will require 'sizeof p' bytes to hold its value,
but even that does not say much about allocated memory. The
implementation may have to align the variable 'p' in some particular
way.
R
Richard Tobin
Richard Heathfield said:
How could you possibly tell? (So long as sizeof returns the expected
answer.)
-- Richard
R
Richard Heathfield
Richard Tobin said:
I couldn't. And here's another question, while we're in the mood: how could
I possibly care?
I couldn't. And here's another question, while we're in the mood: how could
I possibly care?
P
Philip Potter
Richard said:Richard Tobin said:
I couldn't. And here's another question, while we're in the mood: how could
I possibly care?
Well, in the extreme case you might be a bit miffed if a 3-character
(plus null terminator) string literal used all available memory to store
itself!
E
Eric Sosman
Larry__Weiss said:
It depends on what your definition of "for" is.
The implementation is always permitted to use more
memory, more registers, more CPU time, more pixie dust
than you might think is "necessary." (It usually has a
reason that the implementors thought was a good one.)
The nameless array created for the string literal above
is four bytes long, but it might be accompanied by more
memory that is not part of the array. For example, the
DECC compiler on Alpha stuffed short literals into eight-
byte slots apart from the memory used for longer strings;
eight-byte accesses were particularly favored on Alpha.
However, any such extra memory is not part of the
anonymous array object. sizeof("str") is four, exactly,
even if those four bytes wallow in the middle of a forty-
megabyte sea of wasted memory. So the question of how many
bytes are allocated for the literal depends on whether your
idea of "for" means "as a part of" or "on account of," with
the answers "four" and "at least four," respectively.
sizeof(anyThingOrType) includes any padding that the
anyThingOrType needs to ensure its own proper alignment,
but does not include uncalled-for overhead.
R
Richard Heathfield
Philip Potter said:
Oh, I dunno... it might be worth it, just to have a fresh addition to my
store of "horrible warning" anecdotes.
Oh, I dunno... it might be worth it, just to have a fresh addition to my
store of "horrible warning" anecdotes.
K
Keith Thompson
By examining the generated code.
C
CBFalconer
gsingh said:
sizeof p
C
CBFalconer
Richard said:
The literal may not be needed. For example:
char *o = "First str";
char *p = "str";
in which *p may well point to the "str" portion of "First str".
O
Old Wolf
There might not be any generated code, depending on
which optimisations the compiler is able to make.
R
Richard Tobin
[/QUOTE]
Well yes, but by "you" I mean a conforming program, which is the
arbiter of standardness (by the "as if" rule).
-- Richard
K
Keith Thompson
Old Wolf said:
If there's no generated code, then the amount of allocated space is
zero (though it's still the same in the abstract machine).
K
Keith Thompson
A conforming program can examine its own machine code. (Remember the
extremely weak defintion of "conforming program".)
If you're thinking of strictly conforming programs, the standard
doesn't limit itself to those. Correct programs must still work
correctly.