Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir <fir@grunge.pl>
Newsgroups: comp.lang.c
Subject: Re: macro for fir list?
Date: Sat, 30 Mar 2024 10:01:40 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <uu8kdo$3gre2$1@i2pn2.org>
References: <uu3s0m$3av2s$1@i2pn2.org> <uu88uo$qv85$3@dont-email.me> <uu8k48$3gr5r$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 30 Mar 2024 09:01:45 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3698114"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
In-Reply-To: <uu8k48$3gr5r$1@i2pn2.org>
X-Spam-Checker-Version: SpamAssassin 4.0.0

fir wrote:
> Opus wrote:
>> On 28/03/2024 14:40, fir wrote:
>>>
>>> you know famous fir list
>>>
>>> fir list its a list container i somewhat "invented",
>>> i write "invented" as its reasonably simple thing but i never heard
>>> anyone uses it so as for me i invented it for personal use and use it
>>
>> It's a pretty common thing though. It's just that it's not standard, so
>> everyone does it pretty much in their own way.
>>
>> In my way, I avoid to realloc the 'dynamic array' everytime a new item
>> is appended, as it can be a costly operation. I pre-allocate for a
>> certain number of items, and keep track of the current number of items
>> and the current size of the 'dynamic array'. If there is enough room
>> left, I just add the item, no realloc needed. If there isn't, then I
>> realloc, with not just room for 1 item, but a whole new block, for the
>> same reason. You get the idea.
>>
>> This is a common way of dealing with such dynamic containers. (See: bump
>> allocators, and all that...)
>>
>>> some could usually wrote a more convenient Add "method" not to pass
>>> structures but just arguments and struct assigment do inside
>>
>>  From what I get - it's not fully clear - you'd like to directly pass a
>> structure 'literal' to your function, rather than having to go via an
>> intermediate local variable.
>>
>> This is exactly what C99 has brought, among other things, for over 20
>> years. Do not hesitate to use it: compound literals.
>>
>> For instance with your code, you can do this instead:
>>
>> Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
>>
>> Yes, the 'cast' in front of the braces is mandatory for compound
>> literals.
>>
>> Note that your posted code is incorrect, you need to either refer to
>> 'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
>> I think omitting the 'struct' is allowed in C++, not so in C.
>>
>> Conversely, I'm not sure compound literals (which I find very handy) are
>> available in C++. But if you were using C++, you wouldn't need to do the
>> above anyway, so. Just mentioning it.
>>
>
> i think teh idea is rather not obvius, i agree people use dynamic
> alocation, more rarely they use reallock atc but the pure idea
> of list like here is imo not much in use imo... - if that would be in
> use it would be generally used as this is some kind of composition
> pattern and that would substitule ways people usually du such things
> in c largely...as to the line you say i may test it
>
> i coode in c++ mode and in c mode tu though in c++ more often
>
> checked seem not to work: error: taking adress of temporary
>

ok it works whan put -fpermissive, so it may be handy i didnt knew that

> as this list idea people may obviously take it uuse it and then say, oh,
> i was using it - but in facy as i know how c people code (right from
> this group etc) they dont use it, unless thay maybe begin using it in
> last few years
>
> when i started using it (see my more historic post about 'chunks' and
> 'splitter') i used the appproach with variable holding the preallocated
> value... then i dropped it becouse reallock already stores such number
> under the hood so this is kinde reapeating the same thing - but then
> later it showed that stiill doubling it may speed things becouse
> (as far as i remember becouse i dont remember exact values ) this
> call to reallock even if this do almosc nothing still may cost if this
> is in more time critical case
>
>
>
>