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

its list it is a resizable "array" that has a method to add new elemnt
to it -- i aslo vrite some othor method if need, depending on use case

here it is

struct Fir_List_Entry {int x, y;};

Fir_List_Entry* Fir_List = NULL;
int Fir_List_Size = 0;
void Fir_List_AddOne(Fir_List_Entry* entry)
{
Fir_List_Size++;
Fir_List = (Fir_List_Entry*) realloc(Fir_List, Fir_List_Size *
sizeof(Fir_List_Entry) );
Fir_List[Fir_List_Size-1] = *entry;
return ;
}

use it like that

void Test()
{
Fir_List_Entry f1 = {11,22};
Fir_List_Entry f2 = {33,44};

Fir_List_AddOne(&f1);
Fir_List_AddOne(&f2);

for(int i=0; i<Fir_List_Size; i++)
printf("%d %d", Fir_List[i].x, Fir_List[i].y);

}

some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside

C sadly not support a things to it be look betetr and more convenient
- it simply should be buil in in c but is not

so out of suriosity is it possible to write a macro on this? thsi macro
should rename the "Fir" part and put given name magin GivenList not FirList

macros are unconveniant and i doont use it but just out of curiosity

(bump to see this thread on narkive to see it from phone, weird narkive
dont show threads with only 1 post)

fir wrote:
> (bump to see this thread on narkive to see it from phone, weird narkive
> dont show threads with only 1 post)

there is hovever yet such weir option

its weird though convenient

struct Fir_List_Entry {int x, y;};

Fir_List_Entry* Fir_List = NULL;
int Fir_List_Size = 0;

Fir_List_Entry* Fir_List_New()
{
Fir_List = (Fir_List_Entry*) realloc(Fir_List, ++Fir_List_Size *
sizeof(Fir_List_Entry) );
return &Fir_List[Fir_List_Size-1];
}

void Test()
{
*(Fir_List_New()) = {1,2};
*(Fir_List_New()) = {3,4};
*(Fir_List_New()) = {5,6};

for(int i=0; i<Fir_List_Size; i++)
printf("\n %d %d", Fir_List[i].x, Fir_List[i].y);
}

fir wrote:
> fir wrote:
>> (bump to see this thread on narkive to see it from phone, weird narkive
>> dont show threads with only 1 post)
>
> there is hovever yet such weir option
>
> its weird though convenient
>
> struct Fir_List_Entry {int x, y;};
>
> Fir_List_Entry* Fir_List = NULL;
> int Fir_List_Size = 0;
>
> Fir_List_Entry* Fir_List_New()
> {
> Fir_List = (Fir_List_Entry*) realloc(Fir_List, ++Fir_List_Size *
> sizeof(Fir_List_Entry) );
> return &Fir_List[Fir_List_Size-1];
> }
>
>
> void Test()
> {
> *(Fir_List_New()) = {1,2};
> *(Fir_List_New()) = {3,4};
> *(Fir_List_New()) = {5,6};
>
> for(int i=0; i<Fir_List_Size; i++)
> printf("\n %d %d", Fir_List[i].x, Fir_List[i].y);
> }
>
>
handcrafted lists for int, chat* etc could also be written ...
here is soem for pack of str_list (fir str list), as you usually need
more than one

i used resizable list of resizable lists and so on back teh *wrote on
thsi here but this form with _New as above i noticed first time here

// sickle.h
struct str_list_entry { char* str;};
const int str_lists_max = 10;
str_list_entry* str_list[str_lists_max] = {NULL};
int str_list_size[str_lists_max] = {0};
str_list_entry* str_list_new(int N) {
str_list[N] = (str_list_entry*) realloc(str_list[N],
++str_list_size[N] * sizeof(str_list_entry) );
return &str_list[N][str_list_size[N]-1]; }

//main.c
#include "sickle.h"

void Test()
{
*str_list_new(0)={"ala"};
*str_list_new(0)={"ma"};
*str_list_new(0)={"kota"};

*str_list_new(1)={"starcrawler"};
*str_list_new(1)={"skating polly"};
*str_list_new(1)={"lil xan"};
*str_list_new(1)={"kenny mason"};

for(int i=0; i<str_list_size[0]; i++) printf("\n %s ",
str_list[0][i].str);
for(int i=0; i<str_list_size[1]; i++) printf("\n %s ",
str_list[1][i].str);

}

fir wrote:
>
> // sickle.h
> struct str_list_entry { char* str;};
> const int str_lists_max = 10;
> str_list_entry* str_list[str_lists_max] = {NULL};
> int str_list_size[str_lists_max] = {0};
> str_list_entry* str_list_new(int N) {
> str_list[N] = (str_list_entry*) realloc(str_list[N],
> ++str_list_size[N] * sizeof(str_list_entry) );
> return &str_list[N][str_list_size[N]-1]; }
>
you can use the above for example to build list from commanline

const int commandline_list_key = 0;

void BuildListOfComandline(int argc, char* argv[])
{ for(int i=0; i<argc; i++)
*str_list_new(commandline_list_key)={argv[i]};
}

int main(int argc, char* argv[])
{ BuildListOfComandline( argc, argv);
for(int i=0; i<str_list_size[commandline_list_key];i++)
printf("\n%d %s", i, str_list[commandline_list_key][i].str);
}

the names here are maybe to long as for such common use items so some
abrreviation should be used

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.

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

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

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
>
>
>
>

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
>
> 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
>
>
>
>
note i presented somewhat complicated versions of it (for structures,
longer names and indeksed a key (which is in fact dictionary)

quite useble would be tiny crafted versions of it - most simple

// "ints.h" - int list cntainer

int* ints = NULL; int ints_size = 0;
void ints_add(int val) {
ints = (int*)realloc(ints, ++ints_size*sizeof(int));
ints[ints_size-1] = val;
return ; }

//main.c

void Test()
{

ints_add(100);
ints_add(101);
ints_add(102);
ints_add(114);

for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);

ints_size=0; //reset

ints_add(200);
ints_add(221);
ints_add(202);
ints_add(214);

for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);

}

im not quite belive people use it as its such good idea if people would
use it it should be regularelly known and used and i never seen nor hear
of this (at least not before i get to use it few years ago)

people rather use c__ vectror sh*t instead of that and that is better

programming is a lot about composition and this changes composition
a lot

fir wrote:
> 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
>>
>> 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
>>
>>
>>
>>
> note i presented somewhat complicated versions of it (for structures,
> longer names and indeksed a key (which is in fact dictionary)
>
> quite useble would be tiny crafted versions of it - most simple
>
>
> // "ints.h" - int list cntainer
>
> int* ints = NULL; int ints_size = 0;
> void ints_add(int val) {
> ints = (int*)realloc(ints, ++ints_size*sizeof(int));
> ints[ints_size-1] = val;
> return ; }
>

(btw i consider such containers to be a part of my sickle.c library )

one could also write a one line add version, i hope its right

int* ints = NULL; int ints_size = 0;

void ints_add(int
val){(ints=(int*)realloc(ints,++ints_size*sizeof(int)))[ints_size-1]=val;}

if that would be so common people wouldnt talk about crap c++ vector so much

> //main.c
>
> void Test()
> {
>
>
> ints_add(100);
> ints_add(101);
> ints_add(102);
> ints_add(114);
>
> for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
>
> ints_size=0; //reset
>
> ints_add(200);
> ints_add(221);
> ints_add(202);
> ints_add(214);
>
> for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
>
> }
>
> im not quite belive people use it as its such good idea if people would
> use it it should be regularelly known and used and i never seen nor hear
> of this (at least not before i get to use it few years ago)
>
> people rather use c__ vectror sh*t instead of that and that is better
>
> programming is a lot about composition and this changes composition
> a lot
>

fir wrote:
> fir wrote:
>> 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
>>>
>>> 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
>>>
>>>
>>>
>>>
>> note i presented somewhat complicated versions of it (for structures,
>> longer names and indeksed a key (which is in fact dictionary)
>>
>> quite useble would be tiny crafted versions of it - most simple
>>
>>
>> // "ints.h" - int list cntainer
>>
>> int* ints = NULL; int ints_size = 0;
>> void ints_add(int val) {
>> ints = (int*)realloc(ints, ++ints_size*sizeof(int));
>> ints[ints_size-1] = val;
>> return ; }
>>
>
> (btw i consider such containers to be a part of my sickle.c library )
>
> one could also write a one line add version, i hope its right
>
> int* ints = NULL; int ints_size = 0;
>
> void ints_add(int
> val){(ints=(int*)realloc(ints,++ints_size*sizeof(int)))[ints_size-1]=val;}
>
> if that would be so common people wouldnt talk about crap c++ vector so
> much
>
>
>> //main.c
>>
>> void Test()
>> {
>>
>>
>> ints_add(100);
>> ints_add(101);
>> ints_add(102);
>> ints_add(114);
>>
>> for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
>>
>> ints_size=0; //reset
>>
>> ints_add(200);
>> ints_add(221);
>> ints_add(202);
>> ints_add(214);
>>
>> for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
>>
>> }
>>
>> im not quite belive people use it as its such good idea if people would
>> use it it should be regularelly known and used and i never seen nor hear
>> of this (at least not before i get to use it few years ago)
>>
>> people rather use c__ vectror sh*t instead of that and that is better
>>
>> programming is a lot about composition and this changes composition
>> a lot
>>
>
yet other example

//bytes container
char* bytes = NULL; int bytes_size = 0;
void bytes_add(char val) {
(bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
}
void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int c;
while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
void bytes_save(char* name) { FILE* f =fopen(name, "wb"); fwrite
(bytes , 1, bytes_size, f); fclose (f); }

this piece of code has generally quite big usega of being ablo to quick
work on files, like for example

void Test()
{

bytes_load("text.txt");

for(int i=0; i<bytes_size; i++)
if(bytes[i]>='a'&bytes[i]<='z')
bytes[i]+='A'-'a';

bytes_save("text_uppercased.txt");
}

fir wrote:
>
> one could also write a one line add version, i hope its right
>
> int* ints = NULL; int ints_size = 0;
>
> void ints_add(int
> val){(ints=(int*)realloc(ints,++ints_size*sizeof(int)))[ints_size-1]=val;}
>

i think teh above can be seen somewhat as something like my own e=mc2 ;c
saying something as joke , i found some of my other statements on c also
quite interesting - call queue ide is not bad escp there is a hope it
could help in multithreading..improvements to c also

sad im feelin terribly old and almost nothing done in some fields, and
feeling old im not in a form

On 30/03/2024 09:56, fir wrote:

>>
> yet other example
>
> //bytes container
>   char* bytes = NULL; int bytes_size = 0;
>   void bytes_add(char val) {
> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;  }
>   void bytes_load(char* name)  {    FILE *f = fopen(name, "rb"); int c;
> while((c=getc(f))!=EOF) bytes_add(c);   fclose(f);  }

This is pretty inefficient. Loading an 8MB file this way takes 3
seconds, vs. 50ms to load it in one go.

Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
seconds even using a scripting language.

80% of the inefficiency is growing the buffer one byte at a time. The
other 20% is reading the file one byte at a time.

bart wrote:
> On 30/03/2024 09:56, fir wrote:
>
>>>
>> yet other example
>>
>> //bytes container
>> char* bytes = NULL; int bytes_size = 0;
>> void bytes_add(char val) {
>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>> }
>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>
> This is pretty inefficient. Loading an 8MB file this way takes 3
> seconds, vs. 50ms to load it in one go.
>
> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
> seconds even using a scripting language.
>
> 80% of the inefficiency is growing the buffer one byte at a time. The
> other 20% is reading the file one byte at a time.
>
>
i know its inneficient but that was not the point - the point was more
about composition and utility

i may revrite but the example would be much longer

char* bytes = NULL; int bytes_size = 0;
char* bytes_resize(char size) {return
bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
void bytes_add(char val) {
(bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
}
void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }

int GetFileSize2(char *filename)
{
struct stat st;
if (stat(filename, &st)==0) return (int) st.st_size;
// ERROR_EXIT("error obtaining file size for &s", filename);
return -1;
}

void bytes_load(char* name)
{
int flen = GetFileSize2(name);
FILE *f = fopen(name, "rb");
int loaded = fread(bytes_resize(flen), 1, flen, f);
fclose(f);
}

generally if some uses this bytes microcintainer (i call it also list,
though it is also resizable array) one may use thie add method which
callst reallock or call resize(1000) and use it by bytes[i] so its not
inefficient

//@include "bytes.c"
for(int i=0;i<1000;i++) bytes_add(rand()&0xff);

bytes_resize(1000);
for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;

fir wrote:
> bart wrote:
>> On 30/03/2024 09:56, fir wrote:
>>
>>>>
>>> yet other example
>>>
>>> //bytes container
>>> char* bytes = NULL; int bytes_size = 0;
>>> void bytes_add(char val) {
>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>
>>> }
>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>
>> This is pretty inefficient. Loading an 8MB file this way takes 3
>> seconds, vs. 50ms to load it in one go.
>>
>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>> seconds even using a scripting language.
>>
>> 80% of the inefficiency is growing the buffer one byte at a time. The
>> other 20% is reading the file one byte at a time.
>>
>>
> i know its inneficient but that was not the point - the point was more
> about composition and utility
>
> i may revrite but the example would be much longer
>
> char* bytes = NULL; int bytes_size = 0;
> char* bytes_resize(char size) {return
> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
> void bytes_add(char val) {
> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
> }
> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>
>
> int GetFileSize2(char *filename)
> {
> struct stat st;
> if (stat(filename, &st)==0) return (int) st.st_size;
> // ERROR_EXIT("error obtaining file size for &s", filename);
> return -1;
> }
>
> void bytes_load(char* name)
> {
> int flen = GetFileSize2(name);
> FILE *f = fopen(name, "rb");
> int loaded = fread(bytes_resize(flen), 1, flen, f);
> fclose(f);
> }
>
> generally if some uses this bytes microcintainer (i call it also list,
> though it is also resizable array) one may use thie add method which
> callst reallock or call resize(1000) and use it by bytes[i] so its not
> inefficient
>
> //@include "bytes.c"
> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>
> bytes_resize(1000);
> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>

yoy may check how much it last to say insert 1M of bytes by add compared
to resize and put it normall way - thic could measure overhead of this
reallock... i may add this variable say _cached_size or what to name it,
its a line of code ot wo and that will speed up but there still be a
cost of if

fir wrote:
> fir wrote:
>> bart wrote:
>>> On 30/03/2024 09:56, fir wrote:
>>>
>>>>>
>>>> yet other example
>>>>
>>>> //bytes container
>>>> char* bytes = NULL; int bytes_size = 0;
>>>> void bytes_add(char val) {
>>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>>
>>>>
>>>> }
>>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>>
>>> This is pretty inefficient. Loading an 8MB file this way takes 3
>>> seconds, vs. 50ms to load it in one go.
>>>
>>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>>> seconds even using a scripting language.
>>>
>>> 80% of the inefficiency is growing the buffer one byte at a time. The
>>> other 20% is reading the file one byte at a time.
>>>
>>>
>> i know its inneficient but that was not the point - the point was more
>> about composition and utility
>>
>> i may revrite but the example would be much longer
>>
>> char* bytes = NULL; int bytes_size = 0;
>> char* bytes_resize(char size) {return
>> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
>> void bytes_add(char val) {
>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>
>> }
>> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
>> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>>
>>
>> int GetFileSize2(char *filename)
>> {
>> struct stat st;
>> if (stat(filename, &st)==0) return (int) st.st_size;
>> // ERROR_EXIT("error obtaining file size for &s", filename);
>> return -1;
>> }
>>
>> void bytes_load(char* name)
>> {
>> int flen = GetFileSize2(name);
>> FILE *f = fopen(name, "rb");
>> int loaded = fread(bytes_resize(flen), 1, flen, f);
>> fclose(f);
>> }
>>
>> generally if some uses this bytes microcintainer (i call it also list,
>> though it is also resizable array) one may use thie add method which
>> callst reallock or call resize(1000) and use it by bytes[i] so its not
>> inefficient
>>
>> //@include "bytes.c"
>> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>>
>> bytes_resize(1000);
>> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>>
>
> yoy may check how much it last to say insert 1M of bytes by add compared
> to resize and put it normall way - thic could measure overhead of this
> reallock... i may add this variable say _cached_size or what to name it,
> its a line of code ot wo and that will speed up but there still be a
> cost of if

i made some test with putting 1M by add it takes 160 ms
10M by cahced add 45 ms and 10M stright 7 ms, 10M by firs approch may
take more than 10x 160 ms becouse i drwa a plot and if its plots so slow
i dont wait,

if so it seems that this reallock is badly designed or what becouse
it shouldnt be so much slow imo - i vaguelly remember there was
iek already talko on this here..meybe becouse some multithreading
things or what (calling across dll barrier shouldnt be so slow per
se - it also seems i got some slight bug in the test

if(_1_pressed) { bytes_size=0; for(int i=0; i<1*1024*1024; i++)
bytes_add(0x55); }
if(_2_pressed) { bytes_size=0; for(int i=0; i<10*1024*1024; i++)
bytes_add_cached(0x55); }
if(_3_pressed) { bytes_resize(10*1024*1024); for(int i=0;
i<10*1024*1024; i++) bytes[i]=0x55; }

becouse all is okai untill i press 1 2 1 2 and now its segfault
but my head hurts today a bot and im not sure i even want to search fr
that bug now

char* bytes = NULL; int bytes_size = 0;

char* bytes_resize(int size)
{
return bytes=(char*) realloc(bytes, (bytes_size=size)*sizeof(char));
}

void bytes_add(char val) {
(bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
}

void bytes_add_cached(char val) {
static int cached_size = 0;
bytes_size++;
if(bytes_size<=cached_size);
else
bytes=(char*)realloc(bytes,(cached_size=(bytes_size+100)*10)*sizeof(char));

bytes[bytes_size-1]=val; return;

}

fir wrote:
> fir wrote:
>> fir wrote:
>>> bart wrote:
>>>> On 30/03/2024 09:56, fir wrote:
>>>>
>>>>>>
>>>>> yet other example
>>>>>
>>>>> //bytes container
>>>>> char* bytes = NULL; int bytes_size = 0;
>>>>> void bytes_add(char val) {
>>>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>>>
>>>> This is pretty inefficient. Loading an 8MB file this way takes 3
>>>> seconds, vs. 50ms to load it in one go.
>>>>
>>>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>>>> seconds even using a scripting language.
>>>>
>>>> 80% of the inefficiency is growing the buffer one byte at a time. The
>>>> other 20% is reading the file one byte at a time.
>>>>
>>>>
>>> i know its inneficient but that was not the point - the point was more
>>> about composition and utility
>>>
>>> i may revrite but the example would be much longer
>>>
>>> char* bytes = NULL; int bytes_size = 0;
>>> char* bytes_resize(char size) {return
>>> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
>>> void bytes_add(char val) {
>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>
>>>
>>> }
>>> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
>>> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>>>
>>>
>>> int GetFileSize2(char *filename)
>>> {
>>> struct stat st;
>>> if (stat(filename, &st)==0) return (int) st.st_size;
>>> // ERROR_EXIT("error obtaining file size for &s", filename);
>>> return -1;
>>> }
>>>
>>> void bytes_load(char* name)
>>> {
>>> int flen = GetFileSize2(name);
>>> FILE *f = fopen(name, "rb");
>>> int loaded = fread(bytes_resize(flen), 1, flen, f);
>>> fclose(f);
>>> }
>>>
>>> generally if some uses this bytes microcintainer (i call it also list,
>>> though it is also resizable array) one may use thie add method which
>>> callst reallock or call resize(1000) and use it by bytes[i] so its not
>>> inefficient
>>>
>>> //@include "bytes.c"
>>> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>>>
>>> bytes_resize(1000);
>>> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>>>
>>
>> yoy may check how much it last to say insert 1M of bytes by add compared
>> to resize and put it normall way - thic could measure overhead of this
>> reallock... i may add this variable say _cached_size or what to name it,
>> its a line of code ot wo and that will speed up but there still be a
>> cost of if
>
>
> i made some test with putting 1M by add it takes 160 ms
> 10M by cahced add 45 ms and 10M stright 7 ms, 10M by firs approch may
> take more than 10x 160 ms becouse i drwa a plot and if its plots so slow
> i dont wait,
>
> if so it seems that this reallock is badly designed or what becouse
> it shouldnt be so much slow imo - i vaguelly remember there was
> iek already talko on this here..meybe becouse some multithreading
> things or what (calling across dll barrier shouldnt be so slow per
> se - it also seems i got some slight bug in the test
>
> if(_1_pressed) { bytes_size=0; for(int i=0; i<1*1024*1024; i++)
> bytes_add(0x55); }
> if(_2_pressed) { bytes_size=0; for(int i=0; i<10*1024*1024; i++)
> bytes_add_cached(0x55); }
> if(_3_pressed) { bytes_resize(10*1024*1024); for(int i=0;
> i<10*1024*1024; i++) bytes[i]=0x55; }
>
> becouse all is okai untill i press 1 2 1 2 and now its segfault
> but my head hurts today a bot and im not sure i even want to search fr
> that bug now
>

the bug is removed if

if(_1_pressed) { bytes_size=0; for(int i=0; i<1*1024*1024; i++)
bytes_add(0x55); }
if(_2_pressed) { bytes_size=0; cached_size=0; for(int i=0;
i<10*1024*1024; i++) bytes_add_cached(0x55); }
if(_3_pressed) { bytes_resize(10*1024*1024); for(int i=0;
i<10*1024*1024; i++) bytes[i]=0x55; }

and i gett the acces to chached to set to zero so this is something from
that head pains to much to investigat ethat as its side thing

wierd hovever as i said this reallock is such slow - from some reason i
thought it is faster..maybe bceosue of my experiments when i
observed it caches the ram and do reall reallock rarely, like few tims
on milions upsizes..but mayeb i not measured the times for this and
assumed if it caches it work fast and it seem not to be case

bad becouse this should (and could) be faster imo

>
> char* bytes = NULL; int bytes_size = 0;
>
> char* bytes_resize(int size)
> {
> return bytes=(char*) realloc(bytes, (bytes_size=size)*sizeof(char));
> }
>
> void bytes_add(char val) {
> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
> }
>
> void bytes_add_cached(char val) {
> static int cached_size = 0;
> bytes_size++;
> if(bytes_size<=cached_size);
> else
> bytes=(char*)realloc(bytes,(cached_size=(bytes_size+100)*10)*sizeof(char));
>
> bytes[bytes_size-1]=val; return;
>
> }
>
>
>

bart wrote:
> On 30/03/2024 09:56, fir wrote:
>
>>>
>> yet other example
>>
>> //bytes container
>> char* bytes = NULL; int bytes_size = 0;
>> void bytes_add(char val) {
>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>> }
>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>
> This is pretty inefficient. Loading an 8MB file this way takes 3
> seconds, vs. 50ms to load it in one go.
>
> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
> seconds even using a scripting language.
>
> 80% of the inefficiency is growing the buffer one byte at a time. The
> other 20% is reading the file one byte at a time.
>
>

according to what its said its a fault of reallock designers imo
(unles maybe there is faster reallock to use) as it could be
much faster imo

i vaguelly remember some code of mmclean when he uset fgets it
was pointed out its slow - but i dont remember if it was
ponted reallock is yet 3 times slower than fgets if your measurings are
right and representative

fir wrote:
> fir wrote:
>> fir wrote:
>>> bart wrote:
>>>> On 30/03/2024 09:56, fir wrote:
>>>>
>>>>>>
>>>>> yet other example
>>>>>
>>>>> //bytes container
>>>>> char* bytes = NULL; int bytes_size = 0;
>>>>> void bytes_add(char val) {
>>>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>>>
>>>> This is pretty inefficient. Loading an 8MB file this way takes 3
>>>> seconds, vs. 50ms to load it in one go.
>>>>
>>>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>>>> seconds even using a scripting language.
>>>>
>>>> 80% of the inefficiency is growing the buffer one byte at a time. The
>>>> other 20% is reading the file one byte at a time.
>>>>
>>>>
>>> i know its inneficient but that was not the point - the point was more
>>> about composition and utility
>>>
>>> i may revrite but the example would be much longer
>>>
>>> char* bytes = NULL; int bytes_size = 0;
>>> char* bytes_resize(char size) {return
>>> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
>>> void bytes_add(char val) {
>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>
>>>
>>> }
>>> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
>>> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>>>
>>>
>>> int GetFileSize2(char *filename)
>>> {
>>> struct stat st;
>>> if (stat(filename, &st)==0) return (int) st.st_size;
>>> // ERROR_EXIT("error obtaining file size for &s", filename);
>>> return -1;
>>> }
>>>
>>> void bytes_load(char* name)
>>> {
>>> int flen = GetFileSize2(name);
>>> FILE *f = fopen(name, "rb");
>>> int loaded = fread(bytes_resize(flen), 1, flen, f);
>>> fclose(f);
>>> }
>>>
>>> generally if some uses this bytes microcintainer (i call it also list,
>>> though it is also resizable array) one may use thie add method which
>>> callst reallock or call resize(1000) and use it by bytes[i] so its not
>>> inefficient
>>>
>>> //@include "bytes.c"
>>> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>>>
>>> bytes_resize(1000);
>>> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>>>
>>
>> yoy may check how much it last to say insert 1M of bytes by add compared
>> to resize and put it normall way - thic could measure overhead of this
>> reallock... i may add this variable say _cached_size or what to name it,
>> its a line of code ot wo and that will speed up but there still be a
>> cost of if
>
>
> i made some test with putting 1M by add it takes 160 ms
> 10M by cahced add 45 ms and 10M stright 7 ms, 10M by firs approch may
> take more than 10x 160 ms becouse i drwa a plot and if its plots so slow
> i dont wait,
>

so it would be 160 ns for add() 4.5 ns for cached add() and 0.7 ns for
"=" (but as i said it can be longer for reallock bassed add if yet loop
is bigger

- this is hovever all side question as it was more on compositiion
and utility of such "fir list" in comparision for example to c++ vector
bloat

fir wrote:
> fir wrote:
>> fir wrote:
>>> bart wrote:
>>>> On 30/03/2024 09:56, fir wrote:
>>>>
>>>>>>
>>>>> yet other example
>>>>>
>>>>> //bytes container
>>>>> char* bytes = NULL; int bytes_size = 0;
>>>>> void bytes_add(char val) {
>>>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>>>
>>>> This is pretty inefficient. Loading an 8MB file this way takes 3
>>>> seconds, vs. 50ms to load it in one go.
>>>>
>>>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>>>> seconds even using a scripting language.
>>>>
>>>> 80% of the inefficiency is growing the buffer one byte at a time. The
>>>> other 20% is reading the file one byte at a time.
>>>>
>>>>
>>> i know its inneficient but that was not the point - the point was more
>>> about composition and utility
>>>
>>> i may revrite but the example would be much longer
>>>
>>> char* bytes = NULL; int bytes_size = 0;
>>> char* bytes_resize(char size) {return
>>> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
>>> void bytes_add(char val) {
>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>
>>>
>>> }
>>> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
>>> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>>>
>>>
>>> int GetFileSize2(char *filename)
>>> {
>>> struct stat st;
>>> if (stat(filename, &st)==0) return (int) st.st_size;
>>> // ERROR_EXIT("error obtaining file size for &s", filename);
>>> return -1;
>>> }
>>>
>>> void bytes_load(char* name)
>>> {
>>> int flen = GetFileSize2(name);
>>> FILE *f = fopen(name, "rb");
>>> int loaded = fread(bytes_resize(flen), 1, flen, f);
>>> fclose(f);
>>> }
>>>
>>> generally if some uses this bytes microcintainer (i call it also list,
>>> though it is also resizable array) one may use thie add method which
>>> callst reallock or call resize(1000) and use it by bytes[i] so its not
>>> inefficient
>>>
>>> //@include "bytes.c"
>>> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>>>
>>> bytes_resize(1000);
>>> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>>>
>>
>> yoy may check how much it last to say insert 1M of bytes by add compared
>> to resize and put it normall way - thic could measure overhead of this
>> reallock... i may add this variable say _cached_size or what to name it,
>> its a line of code ot wo and that will speed up but there still be a
>> cost of if
>
>
> i made some test with putting 1M by add it takes 160 ms
> 10M by cahced add 45 ms and 10M stright 7 ms, 10M by firs approch may
> take more than 10x 160 ms becouse i drwa a plot and if its plots so slow
> i dont wait,
>
> if so it seems that this reallock is badly designed or what becouse
> it shouldnt be so much slow imo - i vaguelly remember there was
> iek already talko on this here..meybe becouse some multithreading
> things or what (calling across dll barrier shouldnt be so slow per
> se - it also seems i got some slight bug in the test
>
> if(_1_pressed) { bytes_size=0; for(int i=0; i<1*1024*1024; i++)
> bytes_add(0x55); }
> if(_2_pressed) { bytes_size=0; for(int i=0; i<10*1024*1024; i++)
> bytes_add_cached(0x55); }
> if(_3_pressed) { bytes_resize(10*1024*1024); for(int i=0;
> i<10*1024*1024; i++) bytes[i]=0x55; }
>
> becouse all is okai untill i press 1 2 1 2 and now its segfault
> but my head hurts today a bot and im not sure i even want to search fr
> that bug now
>

ah, i know its obvious..i should use two separete seens as when i ussed
thich cached one i may assume i reallocked cached amount and when i
press 1 i reallock the same sid and i guess it reallocks it down so then
cached one accesses above the limit

>
> char* bytes = NULL; int bytes_size = 0;
>
> char* bytes_resize(int size)
> {
> return bytes=(char*) realloc(bytes, (bytes_size=size)*sizeof(char));
> }
>
> void bytes_add(char val) {
> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
> }
>
> void bytes_add_cached(char val) {
> static int cached_size = 0;
> bytes_size++;
> if(bytes_size<=cached_size);
> else
> bytes=(char*)realloc(bytes,(cached_size=(bytes_size+100)*10)*sizeof(char));
>
> bytes[bytes_size-1]=val; return;
>
> }
>
>
>