fully fast resizable arrays in c (c2)

[fir]

W dniu środa, 20 marca 2013 13:34:35 UTC+1 użytkownik Bart napisał:

W dniu poniedzia?ek, 18 marca 2013 10:28:39 UTC+1 u?ytkownik fir napisa?:

(I am working on language codenamed c2 which
is c with improvements and i would wery much like
to get it here) (!)

as to syntax probably
int tab[4000, (100000)] ;


// allloc 4000 ints physical ram
// but reserve logical space for
// 1000000 ints

this is good

Having to specify an upper limit is not good. If you're not sure what it
might be, then you might over-allocate and use up valuable virtual memory
space (if on 32-bits), or even waste page-table resources.



And suppose you don't know the likely upper limit until runtime?

then there is a need for command for resizing it
at runtime like "resize tab[20000];" or something
like that - it would be easy to use and quite
efficient in use i hope

That seems a clumsy way to increase the size of an array (reducing the size
is less common, so can work better with such an approach,, but even then,
reductions are commonly associated with deleting elements in the middle, so

'delete tab' is probably more useful).



Suppose you had an array growing from 0 to 1000000 elements: you'd have to
write this:



int tab[0,(1000000)];



for (i=0; i<1000000; ++i) {
resize tab[i+1];
tab=i*10;
}



It would be far tidier without that resize statement. And it might not
always be obvious when to apply it:

for (i=1; i<1000; ++i) {
j=random(1000000); // random index 0 to 999999;
resize tab [j+1]; // ????????
tab[j] = j*10;
}



How should this resize work? Perhaps tab is already of the same or bigger
size. Most of the calls can be redundant, if the array gets to a large size
early on, but you said you wanted it fast! Even with serial access, the
array allocation won't increase an element at a time, so most resizes will
do very little.



Don't forget also that you can have pointers to arrays, and array elements
(well unless you disallow pointers to resizable arrays):



int a[10];
int* p;

if (cond1) p=&a; else p=&tab;

if (cond2) ++p; /* This might need a resize *if* p points to the
current end of tab. */
*p=56;

as to setting limit is not good - sometimes
but maybe not so often you would like to get
unlimitely resizable array, often limit would
be good - for example if array is for reading
unknown image from disk allowing it to grow
to 1GB may not be wise becouse app hangs on it
(it is to large) - same thing with array
on particles in game or so - if it will be
too large it will hang the game - so in many
apllications some limit is reasonable to
think of - and if you reach it it is some
kind of error

as to resizing in loop - it may not be so
wise to resize every byte though it may
be not so slow - resizing is done in physical
pages granulality so if you resize less then that
it will be small check and return back in
resizing routine - so cost is such if chect
utimes loop counter -it is not to big if one
do not know pay for it, one will store actual
size fill array to that size then is need more
resize larger amount ec 1MB and so on - I think
resizing itself (id est binding physical pages
in system logic-to-physical LUT) can be possibly
be done real fast also - becouse it is only
such system LUT entries edition nothing more
so I think it all can be possibly real fast

as to second code snippet it is just wrong
coding

as to decrasing size - no this is very
important thing, when you got such kind of
applications who had separated segments
in runtime (such as level 1 ingame structures
never used when plying level 2 and vice versa)
you just could resize static-like global arrays
down to zero and give back physical ram to
level 2 arrays - it is good

as to last abut pointers i do not understood it
fully but i think id do not apply here as any
problem, if you saying about such case when you
alloced 40KB (with logical reserve to 400 MB)
and you try to write at 48KB place (without previous
resize comand) i think you should just get
general protection foult: no physical page here
and thats right

that kind of resizable arrays would be grrreat
thing in c i think - it a must to do it, hope it
can be done on windows or linux/unix it should be
done,

 

[fir]

it will be small check and return back in
resizing routine - so cost is such if chect
utimes loop counter -it is not to big if one
do not know pay for it, one will store actual
size fill array to that size then is need more
resize larger amount ec 1MB and so on - I think

sorry for mistakes, may be hard to decippher,
it should be more like:

it will be 'small check and retuurn back' in
resizing routine;
so cost is: such 'if check' times 'loop counter'
- it is not so big
If one do not want to pay for it, one will store
present size, fill array to that size, then if
there is need for more resize, resize it with
larger amount of ram for ex 1MB or so, (..)