Can anyone explain what a "dynamic buffer" is in C and how i could create one?
Can anyone explain what a "dynamic buffer" is in C and how i could create one?
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
malloc();
realloc();
calloc();
You can use them to create a space in memory of your choice dynamically when the program is ran. I believe they all return void * so you will have to cast it to your type. For an array of n ints at runtime you could write something like.
int * myInts = (int *)malloc(n * sizeof(int));
realloc will reallocate the memory(shrink/expand), and calloc is used specifically for arrays. Well at least thats what I used them for =-P
A dynamic buffer is just another word for some space allocated on the heap instead of the stack. You should get a text book and read up on these concepts, as they are crucial to C (and C++). The heap is a vast area of memory that you can request chunks from through the mentioned *alloc() functions. You then get a pointer to the amount of space you requested.
Because you can request as much memory as you want, it's a buffer (as opposed to a basic type), because you can request-free-rerequest the buffer continuously at run time, it's dynamic. Hence dynamic buffer.
QuantumPete
"No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
"Have you tried turning it off and on again?" - The IT Crowd
Actually, only realloc() is truly dynamic - as it allows growing and shrinking of allocated memory and it can replace both malloc() and free(). Malloc() and calloc() give you fixed size memory block (that is dynamicly allocated), but that memory itself would not be "truly dynamic" without realloc().
Last edited by rasta_freak; 08-05-2008 at 04:40 AM.
If you had to choose to use only one function among the memory management functions provided by the C standard library, then indeed realloc() would be the most flexible choice. On the other hand, it is a stretch to say that "memory itself would not be "truly dynamic" without realloc()", since realloc() can be implemented using malloc() and free(). Perhaps the idea that you were trying to put across is that in this context dynamic involves being able to change the amount of memory allocated at runtime, but QuantumPete has already described this idea.Actually, only realloc() is truly dynamic - as it allows growing and shrinking of allocated memory and it can replace both malloc() and free(). Malloc() and calloc() give you fixed size memory block (that is dynamicly allocated - at runtime), but that memory itself would not be "truly dynamic" without realloc().
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes but consider:
* You have a large array x of size N (fixed at compile time)
* You request a chunk of this array (say t with size I)
* You want to increase the size of t from I by Z, you you take Z bytes from N
I would consider that t is a dynamic buffer, no realloc(), malloc() or anything. Although I could be wrong
Maybe i wasn't clear enough or my english is not so good, but i think we understand each other. What i thought as "truly dynamic" was 1) abilty to allocate memory dynamicly, and 2) allow easy & simple way to change it's size. This is just my expression, and sorry if I cause misunderstanding. Of course you are right about what you said, i just meant to "theorize" some more...
I agree, since the idea is the same, except that the "large array x of size N" is now a portion of the memory available to the process instead of being all the memory available to the process. One could write versions of realloc(), malloc() and free() that deals with x instead of the heap.I would consider that t is a dynamic buffer, no realloc(), malloc() or anything. Although I could be wrong
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Not without knowing something about the internals of those functions, because realloc() is guaranteed to move the contents of the existing block to the new location, if the location of the memory block has changed. I can't see any way to do that without knowing how large the existing block of memory is, and of course you can't know that in standard C from just a pointer.realloc() can be implemented using malloc() and free().
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Yes, I overlooked that (for standard library users), but that does not detract from the idea that realloc() can be implemented in terms of malloc() and free(), even if a standard library user has to change its function signature to include the current size.Not without knowing something about the internals of those functions, because realloc() is guaranteed to move the contents of the existing block to the new location, if the location of the memory block has changed. I can't see any way to do that without knowing how large the existing block of memory is, and of course you can't know that in standard C from just a pointer.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Correct.I believe they all return void *
Not in C. In C, a void * can be converted to any object pointer (and vice versa) with no casting. The cast is generally considered a bad idea because:so you will have to cast it to your type.
1) It is superfluous
2) It can hide another problem, i.e., forgetting to include stdlib.h
The rule of thumb for casting in C is: don't do it.
There are times when casts are necessary, but they are few and far between.
Also, I think the argument of casting comes from a while back when it was needed (before ANSI/ISO). You would want to cast if you had changed your datatype from say: "double * d" to "struct s * d" so your compiler catches it. But otherwise you typically can circumvent this headache by doing:
An important thing to keep in mind is if the code is going to be used in a C++ application, then you would want to do the cast ( not ideal but i've seen it many times ).Code:/* could be */ double * d; /* or */ struct s * d; /* and this would cover both */ d = malloc(sizeof(*d));
And, I have never had this happen but I believe casting can cause alignment issues on certain machines and crash the program.
if the code will be used in the C++ you will need to replace malloc with newif the code is going to be used in a C++ application
otherwise - just compile code as C and you can still call these functions from C++ code...
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
I think this would be a common scenario where someone would combine C into C++: http://www.libsdl.org/
And combining code compiled with a C compiler with a C++ compiler... can you do that? Or am I misunderstanding what you're saying?
You can, assuming it's the compilers agree on how things should be done when calling functions from one piece of code to the next. This is quite obviously the case if the compiler is produced by the same company. Usually, it also works when the compiler is intended for the same OS, but not always.
If you call C code from a C++ source, make sure the prototypes of C functions are enclosed byA single function can be done like this:Code:extern "C" { ... // functions declared here }
If you do not do that, then the C++ compiler will "decorate" the functions in a way that won't match what the C compiler did [C++ allows several functions with the same name but different parameters, C doesn't. To solve this, the C++ compiler will add "extra stuff" to the function name to make sure that the function that takes one integer is different from the one that take two integers, and that both of those are different from the function that takes a string, etc, etc].Code:extern "C" func(...);
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.