Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

yet another one...

Gregry2Gregry2 Posts: 607Member
This is along the lines of heap allocation...sorry, but I have no code to illustrate...

I have a function that needs a variable sized buffer, but that [red]exact[/red] size isn't known until we already are calculating using the buffer, and we run out of space. However, what I can pre-calculate is the [red]maximum[/red] size the buffer could be given some other variables, the least size that the worse case scenario can use and still work.

Well, the buffer is returned (sorta, rather the buffer in the first place wasn't the function's, but it is the buffer the result is stored in; it may be sized to fit the whole answer). So afterwards, I need to remove the excess space, and that means I wasted space...

However, if I go the other way, the algorithm would be slow...my logic is to go with the former...but me, hardly a novice, I wonder if my logic holds for you guys.

thats all, thanx all of you(or just Lundin or Niklas,it'll probably be you two to reply)
{2}rIng

Comments

  • stoberstober Posts: 9,765Member ✭✭✭
    The algorithm you use will largly depend on speed -- is your program speed-critical? If not, then you can allocate the buffer in chuncks -- allocate some memory then when it is filled up reallocate a larger amount of memory. In C you would call realloc() to increase the block of memory. And don't worry about if the final size of the buffer is a little larger than actually needed -- reducing its size to the exact amount needed may not be worth the effort and the operating system may not be able to use those extra few bytes. My rule-of-thumb is that if its less than 255 bytes then don't bother.
  • LundinLundin Posts: 3,711Member
    : The algorithm you use will largly depend on speed -- is your program speed-critical? If not, then you can allocate the buffer in chuncks -- allocate some memory then when it is filled up reallocate a larger amount of memory. In C you would call realloc() to increase the block of memory. And don't worry about if the final size of the buffer is a little larger than actually needed -- reducing its size to the exact amount needed may not be worth the effort and the operating system may not be able to use those extra few bytes. My rule-of-thumb is that if its less than 255 bytes then don't bother.
    :


    If the program needs to be fast, he shouldn't use dynamic allocation at all. It is better to estimate the largest possible size needed and allocate a static buffer. It will take more RAM but execute faster.
  • Gregry2Gregry2 Posts: 607Member
    [b][red]This message was edited by Gregry2 at 2006-7-4 8:41:22[/red][/b][hr]
    : : The algorithm you use will largly depend on speed -- is your program speed-critical? If not, then you can allocate the buffer in chuncks -- allocate some memory then when it is filled up reallocate a larger amount of memory. In C you would call realloc() to increase the block of memory. And don't worry about if the final size of the buffer is a little larger than actually needed -- reducing its size to the exact amount needed may not be worth the effort and the operating system may not be able to use those extra few bytes. My rule-of-thumb is that if its less than 255 bytes then don't bother.
    : :
    :
    :
    : If the program needs to be fast, he shouldn't use dynamic allocation at all. It is better to estimate the largest possible size needed and allocate a static buffer. It will take more RAM but execute faster.
    :

    It is a little critical, it is a buffer used in a numeric type operator, or at least its equivalent (this is in C, so no actual classes for a type or operators). However, the byte length of the "numbers" (each byte is a place in an array, thus a sorta 256-base system...) is variable length, and is only limited by the memory of the computer, therefore, the length of the buffers too are variable, and cannot be known exactly until...yeah.

    However, given their lengths, that is, of the numbers, i can calculate the least the worse case scenario can have, as I said.

    Now, I don't just have to allocate a temporary buffer, but I have to resize the buffer recieving the result of the operation...this I resize to the worse case's minimum, and then after the operation, i find the real length and shorten if neccessary :-) yes, to me it sounds sloppy, but I'd rather do this and leave the actual operating, the true purpose of the function(s) free while they operate than check if I need more space every turn of the loop (each operator has a main loop somewhere).

    The excess is only temporarily held, although, is it enough that it is held at all? This is probably where I have the biggest question, but I'd like to keep with this(I've coded it already, an im lazy to change it...lol, jk)

    Believe me, I don't wanna use dynamic allocation though, and yes, even despite the many posts I make on it. I'm trying to stay away from it in as much as possible in this program, but the circumstance needs it, and there seems to be no way around...thats efficient.
    {2}rIng




Sign In or Register to comment.