which one requires less memory?

[khan]

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");


i want to compare the memory requirements of each version: which one
requires less memory?

 

[Ian Collins]

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");


i want to compare the memory requirements of each version: which one
requires less memory?

Did you compare strlen("hello")+1 to 6?

 

[khan]

Yes..
Both evaluates to 6 ...but does these two programs internally use same
amount of memory?

 

[Ian Collins]

Yes..
Both evaluates to 6 ...but does these two programs internally use same
amount of memory?

Please retain enough context for your post to make sense.

Of course they do, they a both malloc(6).

 

[Richard Tobin]

Both evaluates to 6 ...but does these two programs internally use same
amount of memory?

[/QUOTE]

Of course they do, they a both malloc(6).

But the one with strlen("hello") might have an extra copy of the
string literal, though one would hope not.

Using sizeof("hello") would be more natural in this case.

-- Richard

 

[santosh]

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");


i want to compare the memory requirements of each version: which one
requires less memory?

A good compiler should consume equal memory for both versions.

 

[vipvipvipvipvip.ru]

But the one with strlen("hello") might have an extra copy of the
string literal, though one would hope not.

String literals have no scope and no duplicates exist.
Use sizeof "hello", and please check the return value before you do
anything

char *p = malloc(sizeof "hello");
if(p) strcpy(p, "hello");
free(p);

You could also use asprintf or the non-standard strdup.

char *p;
if(asprintf(&p, "hello") == -1) perror("asprintf");
else free(p);

char *p = strdup("hello");
free(p);

If you simply want a mutable string, you can use this c99 feature

char *p = (char[]){ "hello" };

or enable some compiler extension that allows string literals to be
modified (not recommended)

 

[James Kuyper]

String literals have no scope and no duplicates exist.

The first part of that statement is true, though it's relevance is
unclear. The second part is desirable, but not guaranteed by the
standard. 6.4.5p6 says that "It is unspecified whether these arrays are
distinct": if you use the same string literal twice, it might or might
not result in the creation of two distinct arrays of char being created.

 

[vipvipvipvipvip.ru]

The first part of that statement is true, though it's relevance is
unclear. The second part is desirable, but not guaranteed by the
standard. 6.4.5p6 says that "It is unspecified whether these arrays are
distinct": if you use the same string literal twice, it might or might
not result in the creation of two distinct arrays of char being created.

That means "hello" != "hello" might evaluate to true, which is..
irritating.
These std commies sometimes leave too much freedom in the
implementation.

 

[Chris Dollin]

That means "hello" != "hello" might evaluate to true, which is..
irritating.

But rarely relevant; if you want to compare strings, compare them by
content, or implement your own interning machinery.

These std commies sometimes leave too much freedom in the implementation.

I find your choice of adjectives troubling, especially since in this
instance it's nowhere near "too much freedom".

 

[Kenneth Brody]

The result is always the same -- malloc() will be called with a
parameter of 6.

A good compiler should consume equal memory for both versions.

However, the first example may generate more code, as it calls
strlen() and adds one, rather than simply passing 6 to malloc().

Of course, a "good compiler" may see that you're passing a literal
to strlen() and skip the actual call, knowing that the result is
always 5.

Without optimization enabled, my compiler calls strlen(). With
the default optimization, it calls strlen(). With maximum
optimization, it hard-codes the value. With just "intrinsic
functions" optimizing enabled, it does something weird -- it
hard-codes the 5, and adds 1:

return strlen("hello") + 1; /* line 5 */

; Line 5
mov eax, 1
add eax, 5

All of these scenarios are, of course, valid.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[jameskuyper]

That means "hello" != "hello" might evaluate to true, which is..
irritating.
These std commies sometimes leave too much freedom in the
implementation.

I don't know what "commies" has to do with it. The phrase "too much
freedom" is not the stereotype that normally goes with that insult.
Would you care to explain?

I gather that this freedom was necessary, because at the time of the
original standard, there were a number of compilers which did not
bother checking whether the same string literal was used multiple
times in a program. Those implementors decided that they didn't want
to "waste" time performing such a search. Before you judge that
decision too harshly, keep in mind that computers were typically a lot
less powerful back then, and compilers were often excruciatingly
slow.

I don't know the exact politics involved, but I suspect that it would
have been harder to get the original standard approved if it had been
written in a way that would require such implementations to add string
literal merging. Since that time, there's never been a sufficiently
strong reason for declaring this feature obsolescent. Keep in mind
that nowadays memory is dirt cheap; so bothering to merge string
literals might still not be worth while, at least on some platforms.

 

[Ben Bacarisse]

If you simply want a mutable string, you can use this c99 feature

char *p = (char[]){ "hello" };

or enable some compiler extension that allows string literals to be
modified (not recommended)

or use the universally accepted:

char p[] = "hello";

No need for any C99isms or compiler extensions.

 

[Martin Wells]

khan:

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");

i want to compare the memory requirements of each version: which one
requires less memory?

Presumably the former version would take up more memory because of the
machine code required to invoke strlen.

Martin

 

[karthikbalaguru]

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");

i want to compare the memory requirements of each version: which one
requires less memory?

It is very obvious that invoking of strlen in the first version
might consume a bit more memory compared to the second version.

Also, it depends on the level of optimisation that you use
and the compiler.

Karthik Balaguru

 

[Tor Rustad]

Since we did not want to make an error in counting of bytes, we used
the code

char *p;
...
p = malloc(strlen("hello")+1);
strcpy(p,"hello");

instead of the intended

char *p;
...
p = malloc(6);
strcpy(p,"hello");


i want to compare the memory requirements of each version: which one
requires less memory?

The answer is given by measurement, why not use

char p[] = "hello";

instead?

 

[Chris Dollin]

The answer is given by measurement,

Indeed (and is implementation-specific).

why not use

char p[] = "hello";

instead?

Different semantics? The original code makes a mallocated object
that will persist until freed; your proposal makes a local array
that will evaporate when the function exits. Only the OP knows
if that's a good replacement ...

 

[vipvipvipvipvip.ru]

Different semantics? The original code makes a mallocated object
that will persist until freed; your proposal makes a local array
that will evaporate when the function exits. Only the OP knows
if that's a good replacement ...

You mean until it runs out of scope.

int foo(void) {
{ char bar[100]; strcpy(bar, "hello world");}
int bar = 3;
printf("%d \n", bar);
return 0;
}

 

[Chris Dollin]

You mean until it runs out of scope.

Good catch. Yes.

 

[Tor Rustad]

Tor Rustad wrote:
[...]

The answer is given by measurement,

Indeed (and is implementation-specific).
Yup

why not use

char p[] = "hello";

instead?

Different semantics? The original code makes a mallocated object
that will persist until freed; your proposal makes a local array
that will evaporate when the function exits.

The point is, this should be better than a memory-leak (or a free call).
I prefer using malloc() for allocating variable-size objects, not string
literals.