Re: improve that function (bytes_dig_int)

fir <fir@grunge.pl> writes:

Tim Rentsch wrote:
>

fir <fir@grunge.pl> writes:
>

it seems that this group likes such kind of topics, so
here you got
>
improve that function - i wrote it in quick and feel tired so i
dont want to improve it as for now
>
i got "list" of bytes (by list i mean pointer to ram area of
elements - loke reallocked by reallock, by aray i would rather
aybe name fully static array and heap seeds are more like lists
especially if you use them as lists - and got methods like "add"
(remove etc)
>
   unsigned char* bytes = NULL;
   int bytes_size = 0;
   int bytes_allocked = 0;
   int bytes_cursor = 0;
>
i wint to write a function DigInt that "digs" one int form that
list and returns its, then the "cursor" is set after that and you
can call it again untill all ints are "digged"
>
[code]

>
I usually prefer (and recommend) writing code that doesn't make
use of global state, as for example:
>
long
next_value( char *s0, char **next_s ){
   char *s = s0 + strcspn( s0, "0123456789" );
   return
     !*s
       ?   *next_s = s0,  0
       :   strtol(  s - (s!=s0 && s[-1]=='-'),  next_s,  10  );
}
>
Retrieving and processing successive values can be done using
this function by means of a simple for() loop, as illustrated by
the code below:
>
void
print_longs( char *s ){
   long v;
>
   printf( " input:  %s\n", s );
>
   for(  char *next;  v = next_value( s, &next ), s != next;  s = next  ){
     printf( "   value:  %12ld\n", v );
   }
>
   printf( "\n" );
}
>
Note that the local variable 'next' here takes the place of a
cursor for the next input.

>
well ok..this is kinda tricky style but thats a matter of personal
style i prefer more "strightforward" long descriptive names etc

The two aspects are related but my point was about the overall
structure of the algorithm more than about matters of syntactic
and lexical style.

two remarks here
1) people shoudl avoid imo talking a word "global" becouse in
normal desctop computing at least those variables are not global
but typically belong to library (dll) so they are library
scope/module scope not global (this is my own remark as i noticed
this) (thay may also be exe scope but thsi is also module scope
[...]

Yes the word global may have been misleading.  What I meant
was any object whose lifetime outlives the duration of the
relevant function call(s).  For example, in this function

    int
    whatever( char *s ){
        static int something;
        ...
    }

the variable 'something' continues past the point where the
function returns, even though its scope is confined to that of
the function (and so from that point of view it is not "global").
Unfortunately there isn't a common and convenient term that
conveys this meaning.  Whatever it is we call it, this "duration
past the point of function return" is the property I was meaning
to identify and that in most cases should be avoided.