Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: fir 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: References: 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: 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 > > > >