Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Avoiding malloc

Reply
Thread Tools

Avoiding malloc

 
 
Joe Smith
Guest
Posts: n/a
 
      05-12-2006

"John Devereux":
> Ben Hetland :
>> Ivan Vecerina wrote:
>>> "John Devereux" :

>> If the point is to be flexible about the amount of RAM used, or only
>> allocate or reserve the memory at startup time, then it is possible to
>> encapsulate the library's definitions as follows:
>>
>> 1. Let the application query each library in turn about how much memory
>> they need, providing as input the various parameters (P) that the
>> library needs to determine this.
>>
>> 2. The main application sums up the total amount of memory, and
>> allocates (or by other means reserves from its pool of available memory)
>> this memory, so it has a starting address (a) and a size (s).
>>
>> 3. Complete the initialization of each library in turn, something like
>> the following pseudo-code:
>>
>> char *q = a;
>> for (each library L) {
>> init-L( P, q, &n); // (A)
>> q = n;
>> }
>>
>> At (A), the library can reserve its memory and set any pointers into
>> that memory block, starting at the starting address 'q' given. As memory
>> is "grabbed", the pointer is increased accordingly to the next available
>> address. (Essentially a no-overhead allocation.)
>>
>> Of course the library should not "allocate" more memory during the
>> "init" than it initially indicated in step (1). One may or may not
>> bother to check that...
>>
>>
>> Gained:
>> - The main application knows nothing about the private data used by the
>> libraries.
>> - Application can be flexible regarding memory usage.
>> - No "malloc overhead" (except possibly for 1 allocation).
>>
>> Loss:
>> - Somewhat more complex ("two-stage") initialization process.
>> - The "size" of the objects is still known to the application, but it
>> doesn't have to be static (known at compile time), so it is of
>> relatively little use to the application.

>
>
> Interesting, thanks!
>
> Thinking about this, it seems to me that I could just as well use the
> existing scheme, replacing malloc itself by a trivial "allocate-only"
> version. (My implementation should let me do this, but I could use a
> different named function for clc purposes).
>
> --
>
> John Devereux

What a good question! I think to have read a few ways to re-think the
problem, with the easiest for your implementation downthread. If one
queried the libraries with an eye to making
>> char *q = a;
>> for (each library L) {
>> init-L( P, q, &n); // (A)
>> q = n;

eventually more meaningful than a string of zeros and ones, how would one do
it? Joe


 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      05-12-2006
"John Devereux" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Flash Gordon <(E-Mail Removed)> writes:
>
>>
>> What might work is to have:
>>
>> /* foo.c */
>> #include "app_config.h"
>> #include "foo.h"
>>
>> /* define type foo_t */
>>
>> static foo_t foo_private_data[APP_FOOS_REQUIRED];
>> ...
>>
>> /* app_config.h */
>> #define APP_FOOS_REQUIRED 10
>> ...
>>
>> Then foo_t can still be an opaque type for the application. The
>> downside is the library has to be rebuilt for each application against
>> a new app_config.h. Life is full of compromises.

>
> That is *amazingly* close to what I just posted as a reply to Ian
> Collins suggestion of the same thing. It sent it before reading your
> post, honest!
>
> I already #include an app.h for some libraries that need fine-tuning
> for the particular application, so the infrastructure is there to do
> what you suggest.


I was mentally writing the exact same code (well, I used a different macro
name) so I'd say it's the idiomatic way of doing what you want portably.

That said, if your implementation allows you to replace malloc(), that's
probably a better choice. Just don't forget to replace free() and realloc()
as well or you'll get bitten when your library (or another one added later)
tries to dispose of objects.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin


*** Posted via a free Usenet account from http://www.teranews.com ***
 
Reply With Quote
 
 
 
 
John Devereux
Guest
Posts: n/a
 
      05-12-2006
"Stephen Sprunk" <(E-Mail Removed)> writes:

> "John Devereux" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Flash Gordon <(E-Mail Removed)> writes:
>>
>>>
>>> What might work is to have:
>>>
>>> /* foo.c */
>>> #include "app_config.h"
>>> #include "foo.h"
>>>
>>> /* define type foo_t */
>>>
>>> static foo_t foo_private_data[APP_FOOS_REQUIRED];
>>> ...
>>>
>>> /* app_config.h */
>>> #define APP_FOOS_REQUIRED 10
>>> ...

>
> I was mentally writing the exact same code (well, I used a different
> macro name) so I'd say it's the idiomatic way of doing what you want
> portably.
>
> That said, if your implementation allows you to replace malloc(),
> that's probably a better choice. Just don't forget to replace free()
> and realloc() as well or you'll get bitten when your library (or
> another one added later) tries to dispose of objects.


Actually I was planning to replace them alright - with assert(0). I
don't want to have dynamic allocation/free activity during the main
program execution. I would be worried about fragmentation and running
out of heap space. The idea is that library modules get just once
chance to allocate the memory they need, during startup of the
program.

--

John Devereux
 
Reply With Quote
 
Ben Hetland
Guest
Posts: n/a
 
      05-12-2006
John Devereux wrote:
> Actually I was planning to replace them alright - with assert(0). I
> don't want to have dynamic allocation/free activity during the main
> program execution.


In that case maybe you should consider "replacing" you malloc
implementation with an assert(0) as well? That way you're sure that none
of your libraries have a hidden malloc somewhere in there. Then you
could "hide" your real allocation in a routine called something
different, like malloc_once or whatever...


> The idea is that library modules get just once
> chance to allocate the memory they need, during startup of the
> program.


....and that would also assure that you don't silently "grow" your
allocated space during runtime (after init), causing the program to
exhaust its resources eventually if left to run long enough.

--
-+-Ben-+-
 
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
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
porting non-malloc code to malloc micromysore@gmail.com C Programming 3 02-19-2005 05:39 AM
Malloc/Free - freeing memory allocated by malloc Peter C Programming 34 10-22-2004 10:23 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM



Advertisments