| Deutsch English Français Italiano |
|
<v513dn$2i1c3$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: realloc() - frequency, conditions, or experiences about
relocation?
Date: Thu, 20 Jun 2024 13:22:31 +0200
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <v513dn$2i1c3$2@dont-email.me>
References: <v4ojs8$gvji$1@dont-email.me> <875xu8vsen.fsf@bsb.me.uk>
<v4ovqf$j5hq$1@dont-email.me> <87zfrjvqp6.fsf@bsb.me.uk>
<v4pb4v$lhgk$1@dont-email.me>
<20240617180249.96dfaafa89392827aa162434@g{oogle}mail.com>
<v4tuvf$1qto5$1@dont-email.me> <v4u7dm$1t2pu$1@dont-email.me>
<875xu5t066.fsf@bsb.me.uk> <v4v58t$230rh$1@dont-email.me>
<87o77wsk18.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 20 Jun 2024 13:22:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="658fd1c388c737e8ccffa21e0a91fad6";
logging-data="2688387"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Nr7sG6LeAV1JUkj1cDG6ojQmZMIkKGZw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Cancel-Lock: sha1:HHh4oEy7KXMvhulUAVfhShG+I5w=
In-Reply-To: <87o77wsk18.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 3109
On 19/06/2024 23:24, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/06/2024 17:36, Ben Bacarisse wrote:
>>> Growing the buffer exponentially is simple and effective.
>>
>> Yes, that's the general way to handle buffers when you don't know what size
>> they should be.
>>
>> A better solutions for this sort of program is usually, as you say, asking
>> the OS for the file size (there is no standard library function for getting
>> the file size, but it's not hard to do for any realistic target OS). And
>> then for big files, prefer mmap to reading the file into a buffer.
>>
>> It's only really for unsized "files" such as piped input that you have no
>> way of getting the size, and then exponential growth is the way to go.
>> Personally, I'd start with a big size (perhaps 10 MB) that is bigger than
>> you are likely to need in practice, but small enough that it is negligible
>> on even vaguely modern computers. Then the realloc code is unlikely to be
>> used (but it can still be there for completeness).
>
> There are other uses that have nothing to do with files.
Of course. This comment was for the specific purposes being discussed
here. For other uses, there can be many other structures and algorithms
that fit better. Exponentially increasing the size when needed is a
good general-purpose method.
> I have a small
> dynamic array library (just a couple of function) that I use for all
> sorts of things. I can read a file or parse tokens or input a line just
> by adding characters. Because of its rather general use, I don't start
> with a large buffer (though the initial size can be set).
>