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

Discussion in 'C Programming' started by root, Aug 21, 2003.

  1. root

    root Guest

    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
    root, Aug 21, 2003
    #1
    1. Advertising

  2. root

    Mike Wahler Guest

    root <> wrote in message
    news:...
    > 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
    Mike Wahler, Aug 21, 2003
    #2
    1. Advertising

  3. root

    Eric Sosman Guest

    root wrote:
    >
    > 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).

    --
    Eric Sosman, Aug 21, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    13
    Views:
    681
  2. ravi
    Replies:
    0
    Views:
    435
  3. Peter
    Replies:
    34
    Views:
    1,895
    Richard Tobin
    Oct 22, 2004
  4. porting non-malloc code to malloc

    , Feb 18, 2005, in forum: C Programming
    Replies:
    3
    Views:
    458
    Walter Roberson
    Feb 19, 2005
  5. Johs32

    to malloc or not to malloc??

    Johs32, Mar 30, 2006, in forum: C Programming
    Replies:
    4
    Views:
    310
    Captain Winston
    Mar 30, 2006
Loading...

Share This Page