Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > buffer

Reply
Thread Tools

buffer

 
 
Bill Cunningham
Guest
Posts: n/a
 
      10-23-2011
I am wanting to write a text reader involving fgetc and a loop but need
to alloc memory of courses. At first I thought of malloc but would calloc
have a better use for this. This function would also need to realloc and
free memory. I've done this before but with a set buffer size and memory was
wasted. int buff[5000]; for example. I need a buffer that would grow and
then be freed. So how is calloc different than malloc. Also is valloc part
of the standard? It shows up on the online man page.

Bill


 
Reply With Quote
 
 
 
 
Richard Damon
Guest
Posts: n/a
 
      10-23-2011
On 10/23/11 4:58 PM, Bill Cunningham wrote:
> I am wanting to write a text reader involving fgetc and a loop but need
> to alloc memory of courses. At first I thought of malloc but would calloc
> have a better use for this. This function would also need to realloc and
> free memory. I've done this before but with a set buffer size and memory was
> wasted. int buff[5000]; for example. I need a buffer that would grow and
> then be freed. So how is calloc different than malloc. Also is valloc part
> of the standard? It shows up on the online man page.
>
> Bill
>
>


the difference between malloc and calloc is that calloc will clear the
allocated region, and the size it allocates is based on the product of
its two parameters. Unless you need one of these, calloc doesn't buy you
anything. Since you are going to use realloc to grow the buffer, the
clearing is probably not that useful as realloc won't clear the new memory.

valloc() is not part of the c standard.
 
Reply With Quote
 
 
 
 
Bill Cunningham
Guest
Posts: n/a
 
      10-24-2011
Richard Damon wrote:

> the difference between malloc and calloc is that calloc will clear the
> allocated region, and the size it allocates is based on the product of
> its two parameters. Unless you need one of these, calloc doesn't buy
> you anything. Since you are going to use realloc to grow the buffer,
> the clearing is probably not that useful as realloc won't clear the
> new memory.
> valloc() is not part of the c standard.


Thanks I didn't quite understand that man pages description of calloc.

Bill


 
Reply With Quote
 
henry eshbaugh
Guest
Posts: n/a
 
      10-26-2011
On Oct 23, 4:58*pm, "Bill Cunningham" <(E-Mail Removed)> wrote:

> I need a buffer that would grow and then be freed.


The most efficient way of doing this, rather than VLAs on the stack or
multiple calls to malloc(), calloc() and free() is to use a linked
list. It can grow and shrink dynamically on a node-by-node basis, and
can be manipulated freely. They're simple to write and much easier to
use.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-27-2011
On 10/27/11 10:58 AM, henry eshbaugh wrote:
> On Oct 23, 4:58 pm, "Bill Cunningham"<(E-Mail Removed)> wrote:
>
>> I need a buffer that would grow and then be freed.

>
> The most efficient way of doing this, rather than VLAs on the stack or
> multiple calls to malloc(), calloc() and free() is to use a linked
> list. It can grow and shrink dynamically on a node-by-node basis, and
> can be manipulated freely. They're simple to write and much easier to
> use.


A linked list of characters, you jest?

How do you propose growing a linked list without dynamic allocation?

--
Ian Collins
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      10-27-2011
On 2011-10-27, Ian Collins <(E-Mail Removed)> wrote:
> On 10/27/11 10:58 AM, henry eshbaugh wrote:
>> On Oct 23, 4:58 pm, "Bill Cunningham"<(E-Mail Removed)> wrote:
>>
>>> I need a buffer that would grow and then be freed.

>>
>> The most efficient way of doing this, rather than VLAs on the stack or
>> multiple calls to malloc(), calloc() and free() is to use a linked
>> list. It can grow and shrink dynamically on a node-by-node basis, and
>> can be manipulated freely. They're simple to write and much easier to
>> use.

>
> A linked list of characters, you jest?


Been there, done that.

Recently.

$ gdb ./txr
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
[ ... ]
(gdb) b build_filter_from_list
Breakpoint 1 at 0x428ee8: file filter.c, line 177.
(gdb) r -c '@(deffilter f ("aaaaaab" "aaaaaac" "aaaaaad" "e"))'
Starting program: /kaz-disk/home/kaz/txr/txr -c '@(deffilter f ("aaaaaab" "aaaaaac" "aaaaaad" "e"))'

Breakpoint 1, build_filter_from_list (list=0x7ffff7fb20d at filter.c:177
177 val trie = make_trie();
(gdb) n
180 for (iter = list; iter; iter = cdr(iter)) {
(gdb) n
181 val tuple = reverse(car(iter));
(gdb) n
182 mapcar(curry_123_2(func_n3(trie_add), trie, first(tuple)), rest(tuple));
(gdb) n
180 for (iter = list; iter; iter = cdr(iter)) {
(gdb) n
185 trie_compress(&trie);
(gdb) p d(trie)
#<hash: 0x8aa980>
$1 = void
(gdb) n
186 return trie;
(gdb) p d(trie)
('a' 'a' 'a' 'a' 'a' 'a' . #<hash: 0x8adbc0>)
$2 = void
(gdb) p (typeof(trie))
$3 = (obj_t *) 0x7ffff7fe6cb8
(gdb) p d(typeof(trie))
cons
$4 = void
(gdb) p d(typeof(car(trie)))
chr
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      10-27-2011
On Oct 27, 2:50*am, Ian Collins <(E-Mail Removed)> wrote:
> On 10/27/11 10:58 AM, henry eshbaugh wrote:
> > On Oct 23, 4:58 pm, "Bill Cunningham"<(E-Mail Removed)> *wrote:


> >> I need a buffer that would grow and then be freed.

>
> > The most efficient way of doing this, rather than VLAs on the stack or
> > multiple calls to malloc(), calloc() and free() is to use a linked
> > list. It can grow and shrink dynamically on a node-by-node basis,


the *nodes* change size dynamically or just the list?

> > and
> > can be manipulated freely. They're simple to write


amazing how many times I've debugged such things...

> > and much easier to use.


not really you have to be more careful not to drop off the end of the
block. Well designed primitives can mitigate this

> A linked list of characters, you jest?


a linked list of *blocks* of chars makes more sense. I've done it when
memory was very tight and it worked quite well.

> How do you propose growing a linked list without dynamic allocation?


fixed number of blocks "allocated" at start up. Could be a giant
array.

As I say, it works well on limited hardware but i can't really see the
over whelming advantage over malloc/realloc on a modern system. I
assume Bill isn't processing giga-bytes of data

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      10-27-2011
On Oct 27, 3:44*am, Kaz Kylheku <(E-Mail Removed)> wrote:
> On 2011-10-27, Ian Collins <(E-Mail Removed)> wrote:
>
> > On 10/27/11 10:58 AM, henry eshbaugh wrote:
> >> On Oct 23, 4:58 pm, "Bill Cunningham"<(E-Mail Removed)> *wrote:

>
> >>> I need a buffer that would grow and then be freed.

>
> >> The most efficient way of doing this, rather than VLAs on the stack or
> >> multiple calls to malloc(), calloc() and free() is to use a linked
> >> list. It can grow and shrink dynamically on a node-by-node basis, and
> >> can be manipulated freely. They're simple to write and much easier to
> >> use.

>
> > A linked list of characters, you jest?

>
> Been there, done that.
>
> Recently.
>
> $ gdb ./txr
> GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> [ ... ]
> (gdb) b build_filter_from_list
> Breakpoint 1 at 0x428ee8: file filter.c, line 177.
> (gdb) r -c '@(deffilter f ("aaaaaab" "aaaaaac" "aaaaaad" "e"))'
> Starting program: /kaz-disk/home/kaz/txr/txr -c '@(deffilter f ("aaaaaab""aaaaaac" "aaaaaad" "e"))'
>
> Breakpoint 1, build_filter_from_list (list=0x7ffff7fb20d at filter.c:177
> 177 * * * val trie = make_trie();
> (gdb) n
> 180 * * * for (iter = list; iter; iter = cdr(iter)) {
> (gdb) n
> 181 * * * * val tuple = reverse(car(iter));
> (gdb) n
> 182 * * * * mapcar(curry_123_2(func_n3(trie_add), trie, first(tuple)), rest(tuple));
> (gdb) n
> 180 * * * for (iter = list; iter; iter = cdr(iter)) {
> (gdb) n
> 185 * * * trie_compress(&trie);
> (gdb) p d(trie)
> #<hash: 0x8aa980>
> $1 = void
> (gdb) n
> 186 * * * return trie;
> (gdb) p d(trie)
> ('a' 'a' 'a' 'a' 'a' 'a' . #<hash: 0x8adbc0>)
> $2 = void
> (gdb) p (typeof(trie))
> $3 = (obj_t *) 0x7ffff7fe6cb8
> (gdb) p d(typeof(trie))
> cons
> $4 = void
> (gdb) p d(typeof(car(trie)))
> chr


is this an example of such a system or did the cat tread on your
keyboard?


 
Reply With Quote
 
henry eshbaugh
Guest
Posts: n/a
 
      10-28-2011
> the *nodes* change size dynamically or just the list?

The list, of course.

If you know of any data structures that can resize themselves, let me
know. That would be pretty cool.

> amazing how many times I've debugged such things...


I feel like it would be easier than to implement logic to copy arrays
over and over again. Of course, I can always be wrong, but at least to
me, a linked list would be easier.

>
> > and much easier to use.

>
> not really you have to be more careful not to drop off the end of the
> block. Well designed primitives can mitigate this


Just like you can drop off the end of any array. But at least you can
return an error code.

>
> > A linked list of characters, you jest?

>
> a linked list of *blocks* of chars makes more sense. I've done it when
> memory was very tight and it worked quite well.


Either one works.

> > How do you propose growing a linked list without dynamic allocation?


void list_add_node(list_head_t *head, char c)
{
/* parse to end of node. can be done with reference to end
from list_head_t
* or simple parsing logic. let's say node_t *current now
points to the
* end of the list. */
/* ... */
current->next = malloc(sizeof current->*next);
current->next->next = NULL;
current->next->value = c;
return ;
}

Now, pass a char to it, and have your list expand.

> As I say, it works well on limited hardware but i can't really see the
> over whelming advantage over malloc/realloc on a modern system. I
> assume Bill isn't processing giga-bytes of data


The overhead of copying blocks of memory directly is much larger than
parsing to the end of a well-designed linked list. And I'd agree with
his initial approach if he was processing gigabytes of data. So, I'd
think that it would be easier to do something like this instead of
copying everything every time you want to append 1 char (something he
expects to be repeated a few thousand times...)

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-29-2011
Please don't snip attributions, it's rude.

On 10/29/11 12:27 PM, henry eshbaugh wrote:

>> I wrote:


>>> How do you propose growing a linked list without dynamic allocation?

>
> void list_add_node(list_head_t *head, char c)
> {
> /* parse to end of node. can be done with reference to end
> from list_head_t
> * or simple parsing logic. let's say node_t *current now
> points to the
> * end of the list. */
> /* ... */
> current->next = malloc(sizeof current->*next);


Since when did malloc stop being used for dynamic allocation?

> current->next->next = NULL;
> current->next->value = c;
> return ;
> }
>
> Now, pass a char to it, and have your list expand.
>
>> As I say, it works well on limited hardware but i can't really see the
>> over whelming advantage over malloc/realloc on a modern system. I
>> assume Bill isn't processing giga-bytes of data

>
> The overhead of copying blocks of memory directly is much larger than
> parsing to the end of a well-designed linked list. And I'd agree with
> his initial approach if he was processing gigabytes of data. So, I'd
> think that it would be easier to do something like this instead of
> copying everything every time you want to append 1 char (something he
> expects to be repeated a few thousand times...)


But you don't copy everything every time you want to append 1 char. You
copy when the buffer fills.

--
Ian Collins
 
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
buffer creates only read-only buffer? Neal Becker Python 0 01-08-2009 01:58 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net 2 07-29-2008 09:50 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net Building Controls 0 07-29-2008 01:37 AM
convert M bit buffer to N bit buffer runcyclexcski@yahoo.com C++ 2 03-26-2007 09:43 AM
How to know the buffer size and increase buffer size in c++ Raja C++ 12 06-21-2004 06:21 PM



Advertisments