Thread: Design question

  1. #1
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210

    Design question

    I'm working on a library that has at least one function that returns dynamically allocated memory.

    Since this library will most likely be abused by a bunch of people that have no idea what they are doing, I'm concerned about users ending up allocating lots of memory through the library and never free()ing it. Because of that, I'd like to try to somehow keep track of all memory that is returned this way, and make sure that it is cleaned up, at the very least, upon program exit.

    The first option is to not do anything about cleaning up the memory and say, "That's the programmer's problem." I'm willing to go with this approach if that needs to be done, but I still like the idea of being smart about memory and making sure that, as a matter of principle, it is cleaned up before termination. Also, the library will most likely be geared towards newer programmers, so even though free()ing memory is a rather simple task, I don't want to bank on them doing it.

    Another option that I see is to register a function using atexit() that will go through all memory allocated in this manner and free() it upon program termination, thus guarenteeing that memory is free()ed. I could supply an xfree() function for the user to use that would, in addition to calling free(), would also remove that pointer from the table. This seems to overcomplicate things. If I'm worried about a programmer using free(), I doubt they would deal with a non-standard function. A second problem with this is if the user decides to deallocate the memory directly using free(), because this will result in a double free, as well as a needless behind-the-scenes memory tracking system.

    So naturally complicating this beyond necessity, here are my questions:

    1. Given that my library will most likely be used by relatively newer programmers, should it keep track of memory allocated that is returned to said programmers?
    2. If memory tracking should be done, what is the best way of keeping track of memory?
    3. If memory cleanup should be done by the library, what should be the best method ensure that double free()ing is not performed?

  2. #2
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    By keeping track of memory yourself your taking control away from the user (some, more advanced users might turn away from your library because of this),

    Consider the cURL library, you MUST call cURL's free() after your done. Not sure about preventing double free()s but it's always a good idea to deinitialize the pointers to 0 after you've free'd them...
    Code:
    free(ptr)
    ptr = NULL;
    Since free(NULL); has no effect.

  3. #3
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  4. #4
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    Maybe you should just document the library API in such a way that where will be no dobt what freeing routine should be called in pair with some initialization routine...

    Like
    The CreateBrushIndirect function creates a logical brush that has the specified style, color, and pattern.

    ...
    When you no longer need the brush, call the DeleteObject function to delete it.

    I don't think library should bother "What if they use the API incorectly" rather "How to make them use it correctly"
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  5. #5
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by zacs7 View Post
    By keeping track of memory yourself your taking control away from the user (some, more advanced users might turn away from your library because of this),
    It's geared towards new programmers, not advanced users. Advanced users probably wouldn't want to use this.

    It's mainly just a collection of safe IO functions in C that greatly simplifies IO. I just wanted to group together a library that is able to perform tasks like draining the input buffer (reading until a '\n' or EOF) or reading an arbitrary length string from any file in a somewhat efficient -- but especially safe -- manner

    If you know how to use fgets(), malloc(), realloc(), free(), etc., then you could obviously write your own set of functions for this.

    Quote Originally Posted by zacs7 View Post
    Consider the cURL library, you MUST call cURL's free() after your done. Not sure about preventing double free()s but it's always a good idea to deinitialize the pointers to 0 after you've free'd them...
    Code:
    free(ptr)
    ptr = NULL;
    Since free(NULL); has no effect.
    It's a good idea. I already have a macro to do this, since last given advice on how to free() a pointer and set it to NULL.

    Quote Originally Posted by Dave_Sinkula View Post
    I'd like it to work on any O/S, depending upon only standard C library code, if possible. If I decide to write O/S specific code for this, it would attempt to support general *nix systems and Windows.

    Quote Originally Posted by vart View Post
    Maybe you should just document the library API in such a way that where will be no dobt what freeing routine should be called in pair with some initialization routine...

    Like


    I don't think library should bother "What if they use the API incorectly" rather "How to make them use it correctly"
    That is one approach I'm considering. The main concern is that I achieve safe, proper, and portable C code to perform these tasks.

  6. #6
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    Quote Originally Posted by MacGyver View Post
    I'd like it to work on any O/S, depending upon only standard C library code, if possible. If I decide to write O/S specific code for this, it would attempt to support general *nix systems and Windows.
    So doesn't any "real" OS already do what you are attempting?

    [edit]Not that I advocate programming irresponsibly.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  7. #7
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by Dave_Sinkula View Post
    So doesn't any "real" OS already do what you are attempting?

    [edit]Not that I advocate programming irresponsibly.
    If you mean that modern operating systems clean up memory, then yes.

    The people I'd like to target are the people that want to use gets(), fflush(stdin), and getch() because they are "easier", and those functions "work for them". I'd like to put together a simple library that allows them to be able to use easier functions that work better than their unsafe or unportable counterparts, but at the same time are also safe and relatively portable.

    If those type of programmers actually mature enough to want to know how everything works inside such a library, I would like it so they will see clean, proper, and safe code.

    That's why, as a matter of principle, I'd like see what my best options are for dealing with this at the library level. I don't mind telling them to free() the memory themselves if that is the best alternative, so if that's what you're telling me, I acknowledge your advice.

  8. #8
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    I don't want to burst your bubble, but is offering a library the best thing to do?

    I mean the functions already exist, fgets() rather than gets(), getchar() (blocking) rather than getch() (non-blocking) etc. It could really cause the begginer to use your library even once they become better. (If that makes sense )

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    On Windows, you have to take extreme care, because your library might be linked against a different CRT than the user's program. In that case, the user calling free() on a pointer you malloc()ed will likely lead to a crash.

    For this reason, any library that allocates memory MUST provide functions to free that memory.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #10
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by zacs7 View Post
    I don't want to burst your bubble, but is offering a library the best thing to do?
    Perhaps not.

    When people post examples with code that use gets(), we point them to the FAQ or we show them a small example on how to use fgets(). That doesn't satisfy everyone. Some insist that gets() is better for them because they have to do less work getting rid of the trailing '\n', etc. etc..

    I don't mind writing a function that gets rid of the '\n', or reads until a newline line is read if that would make a difference to that kind of person.

    Quote Originally Posted by zacs7 View Post
    I mean the functions already exist, fgets() rather than gets(), getchar() (blocking) rather than getch() (non-blocking) etc.
    Agreed, they do exist, but even with the posts here to tell them the proper alternatives, the FAQ, numerous websites, tutorials, and everything else, some people are lazy and just want code written for them.

    Quote Originally Posted by zacs7 View Post
    It could really cause the begginer to use your library even once they become better. (If that makes sense )
    True, however, the alternative of them getting themselves stuck using non-portable and/or non-safe functions concerns me more.

    Quote Originally Posted by CornedBee View Post
    On Windows, you have to take extreme care, because your library might be linked against a different CRT than the user's program. In that case, the user calling free() on a pointer you malloc()ed will likely lead to a crash.

    For this reason, any library that allocates memory MUST provide functions to free that memory.
    Hmm, odd, but good point.

    If I release the source code and let them compile it into their project, I believe that should be 100% safe.

    If I release a DLL (overkill? lol.), I'll have to beat them over the head with this point.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Game design question
    By h3ro in forum Game Programming
    Replies: 6
    Last Post: 02-28-2008, 08:20 AM
  2. Question about engine design.
    By Shamino in forum Game Programming
    Replies: 9
    Last Post: 01-29-2008, 10:53 AM
  3. question about class design and overloading
    By l2u in forum C++ Programming
    Replies: 7
    Last Post: 12-13-2007, 02:02 PM
  4. database app design question
    By MPSoutine in forum Windows Programming
    Replies: 4
    Last Post: 12-02-2003, 10:13 PM
  5. design question: opinion
    By ggs in forum C Programming
    Replies: 2
    Last Post: 01-29-2003, 11:59 AM