item[LENGTH] vs. *item and malloc()

[root]

Hello,
I've been thinking about advantages and disadvantages of methods for
storing strings and the like. For instance, I could be storing
things from a configuration or filenames etc. into either char
filename[n] or char *filename, allocating space for the later with
malloc(strlen(x)) or something. What are the advntages/drawbacks of
both methods? Clearly, there's always the chance of n in the first
example not being enough or, on the other hand, much too large; this
could either crash the program or make for a larger memory
footprint. Then again, the second method, with call to malloc()
(and maybe even strlen()), would probably slow the program down a
little. However, the amount of time needed to do this is probably
very low.
Thus is there any rule one should follow in such situations?

Thanks,
andrej

 

[Mike Wahler]

Hello,
I've been thinking about advantages and disadvantages of methods for
storing strings and the like. For instance, I could be storing
things from a configuration or filenames etc. into either char
filename[n] or char *filename, allocating space for the later with
malloc(strlen(x)) or something. What are the advntages/drawbacks of
both methods? Clearly, there's always the chance of n in the first
example not being enough or, on the other hand, much too large;

Yes, that's a possible 'drawback' of fixed sized arrays.

this
could either crash the program

No it would not.

or make for a larger memory
footprint.

Yes, the 'footprint' might be larger than necessary in
some cases. I'd only be concerned about this if 'footprint'
is really a legitimate concern (e.g. with embedded systems).

Then again, the second method, with call to malloc()
(and maybe even strlen()), would probably slow the program down a
little.

It might. But the difference in speed may or may not
be noticable or significant.

However, the amount of time needed to do this is probably
very low.

Might be, might not. This depends upon several factors,
e.g. how often you do it, your operating system, the
quality of your standard library, etc.

Thus is there any rule one should follow in such situations?

There are no 'hard and fast' rules. I think a good 'guideline'
is to use a fixed size array if you know your data will always
fit and the 'wasted space' can be kept to a minimum (if that's
a concern at all); and use dynamic allocation when you don't
know what the size will be beforehand, or cannot tolerate any
'waste' which a fixed sized array might entail.

As for your performance concerns, the only way to know for
sure is to measure.

Remember: "Premature optimization is the root of all evil".

-Mike

 

[Eric Sosman]

Hello,
I've been thinking about advantages and disadvantages of methods for
storing strings and the like. For instance, I could be storing
things from a configuration or filenames etc. into either char
filename[n] or char *filename, allocating space for the later with
malloc(strlen(x)) or something.

"Or something," indeed. malloc(strlen(x)) is almost always
wrong; malloc(strlen(x)+1) is almost always the cure.

What are the advntages/drawbacks of
both methods? Clearly, there's always the chance of n in the first
example not being enough or, on the other hand, much too large; this
could either crash the program or make for a larger memory
footprint. Then again, the second method, with call to malloc()
(and maybe even strlen()), would probably slow the program down a
little. However, the amount of time needed to do this is probably
very low.

How many strings are there, and how big are they? If there
are only a few dozen and they're guaranteed to be shorter than
500 characters each, say, a fixed-size array is just fine. If
there are potentially thousands of them and/or you have no idea
how big a string might be, dynamic memory is pretty much forced
upon you.

Where are the strings coming from? If you're reading them
from a file or some such, the I/O time will most likely dwarf
the time taking to call malloc() and strlen(). And you may
be able to avoid the strlen() altogether: if you're reading
the characters yourself, you may just be able to count them
as you go.

The Standard makes no promises about what's fast and what's
slow, but I/O is typically about a million times slower than
in-memory access, give or take a factor of ten.

Thus is there any rule one should follow in such situations?

Yes, there are Jackson's Laws of Program Optimization:

First Law of Program Optimization:
Don't do it.

Second Law of Program Optimization (for experts only):
Don't do it yet.

In other words, choose your allocation method to suit the
nature of the problem at hand, not to satisfy some notion of
what's more or less efficient. As always, be prepared to
measure the performance, and if the performance is inadequate
*and* your measurements show that the allocation scheme is to
blame, *then* start optimizing. "Premature optimization is
the root of all evil," writes Knuth, and he's enough smarter
than I am that I'm willing to take his word for it (besides,
it bears out my own experience).