Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > memory mgmt problem

Reply
Thread Tools

memory mgmt problem

 
 
richard
Guest
Posts: n/a
 
      09-02-2003
On Mon, 01 Sep 2003 20:19:29 -0400, Al Bowers <(E-Mail Removed)> wrote:
>richard wrote:

[snip]
>> typedef struct {
>> int entries;
>> Item **item;

>
>This is fine but you could also make thie *item.


**item means the storage space for each item is allocated and freed through this
struct, which seems cleaner than the alternative.

[snip]
>> list.entries = 0;
>> list.item = NULL;

>
>You could intialize in the declaration.
>List list = {0, NULL};


I go back and forth on that. My current worry is that it I add a new element to
the struct and forget to change the initializers.

[snip]
>> void AddItem(List *d, Item *item) {

>
>It would be good here to return a value which would indicate
>an allocation failure and remove the exit function. This gives
>a change for the calling function to take different actions if
>it choses.


Agreed. In this particular application, exiting is the best alternative, but
for more general use I should let the calling program rather than the sub make
the choice.

>Something like:
>Item *AddList(List *d, const char *s, int i);


Why return a pointer to the item rather than an integer return code?

[snip]
>void FreeList(List *d)
>{
> free(d->item);
> d->item = NULL;
> d->entries = 0;
>}


Going back to *item v. **item, I'd like to free each underlying item, and having
AddItem allocate the storage (rather than just pointing to storage that may be
allocated by the calling function) seems better, especially if you don't know
whether the call will point to static storage (such as "Hello World!") or
something malloc'd.

[snip]

thanks
 
Reply With Quote
 
 
 
 
Al Bowers
Guest
Posts: n/a
 
      09-02-2003


richard wrote:
> On Mon, 01 Sep 2003 20:19:29 -0400, Al Bowers <(E-Mail Removed)> wrote:
>
>>richard wrote:

>
> [snip]
>
>>>typedef struct {
>>> int entries;
>>> Item **item;

>>
>>This is fine but you could also make thie *item.

>
>
> **item means the storage space for each item is allocated and freed through this
> struct, which seems cleaner than the alternative.
>


Why does it seem clearer? IMO, if you are allocating a one-dimensional
array, which I interpeted was the attempt of the OP, it would
seem clearer to use *item. On the other hand, for two-dimensional
array you would use **item.

> [snip]
>
>>>list.entries = 0;
>>>list.item = NULL;

>>
>>You could intialize in the declaration.
>>List list = {0, NULL};

>
>
> I go back and forth on that. My current worry is that it I add a new element to
> the struct and forget to change the initializers.
>


Why worry? Concerns will still exist that one forgets to add the
additional assignment statement(s).


> [snip]


>>Something like:
>>Item *AddList(List *d, const char *s, int i);

>
>
> Why return a pointer to the item rather than an integer return code?
>


In this trivial example, a bool return value would be ok.
However a Item * return value can be used not just for determining
success of failure of the allocation. This appears to be
a matter of preference.

Item *tmp;
if((tmp = AddList(&data,string, number)) != NULL)
printf("Gee, space was successfully allocated for\n"
"the string \"%s\" and the int %d\n",tmp->this,tmp->that);

> [snip]
>
>>void FreeList(List *d)
>>{
>> free(d->item);
>> d->item = NULL;
>> d->entries = 0;
>>}

>
>
> Going back to *item v. **item, I'd like to free each underlying item, and having
> AddItem allocate the storage (rather than just pointing to storage that may be
> allocated by the calling function) seems better, especially if you don't know
> whether the call will point to static storage (such as "Hello World!") or
> something malloc'd.
>


I am lost in understanding this statement. Whether *item or **item all
allocations are assumed to be be "malloc'd", ie. allocated by a call
to realloc, malloc, or calloc. And the function free will free those
dynamic allocations.

--
Al Bowers
Tampa, Fl USA
mailto: http://www.velocityreviews.com/forums/(E-Mail Removed) (remove the x)
http://www.geocities.com/abowers822/

 
Reply With Quote
 
 
 
 
richard
Guest
Posts: n/a
 
      09-02-2003
On Tue, 02 Sep 2003 12:26:16 -0400, Al Bowers <(E-Mail Removed)> wrote:

[snip]
>> Going back to *item v. **item, I'd like to free each underlying item, and having
>> AddItem allocate the storage (rather than just pointing to storage that may be
>> allocated by the calling function) seems better, especially if you don't know
>> whether the call will point to static storage (such as "Hello World!") or
>> something malloc'd.
>>

>
>I am lost in understanding this statement. Whether *item or **item all
>allocations are assumed to be be "malloc'd", ie. allocated by a call
>to realloc, malloc, or calloc. And the function free will free those
>dynamic allocations.


I fear I'm being unclear. The issue is storage space for the underlying data
objects pointed to by our item list and how to free that space. In the prior
examples, the underlying data was a char[] and an int.

List contains either *item or **item

*item is a list of pointers to objects that are stored outside List

**item is a list of pointers to objects that are stored in List. AddItem
allocates space for the objects and copies the data into that space.

After creating List and doing whatever we want with it, we'd like to free all
associated storage space, both pointers to data and the underlying data.

In the *item approach, we don't know if the data objects are still being used,
so we can't free that space.

In the **item approach, we know that the List structure owns the space for the
underlying data, so we can feel comfortable freeing it.

hope this makes a bit more sense
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
650x + multiple VLANs + l2trace on non-mgmt VLAN papi Cisco 7 05-16-2005 02:30 AM
Re: MGMT-4-OUTOFNVRAM - Catalyst 6513 NVRAM is full Mark Cisco 0 04-07-2004 02:11 PM
ASP .Net pages - instance mgmt Krishnan ASP .Net 0 04-05-2004 06:10 AM
Memory Mgmt Using C and Perl Mark Shelor Perl Misc 7 01-22-2004 05:49 PM
Clarification related to memory mgmt of char * inside a function ... Karthik D C Programming 3 07-02-2003 04:21 PM



Advertisments