Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: improve that function (bytes_dig_int)
Date: Sat, 13 Apr 2024 07:44:12 -0700
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <867ch1z5j7.fsf@linuxsc.com>
References: <uukcop$3vhcj$1@i2pn2.org> <86jzl72j9v.fsf@linuxsc.com> <uvbg3i$sm6s$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 13 Apr 2024 16:44:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="44a1207aeaadfda1483c7b96a3737e57";
	logging-data="3216084"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX193jdFUPj8VDx0RkkVjr6gqxpUfOhXPkOs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:f15XOPzy2r8aP6ugitwUTtK3ZBE=
	sha1:Bfi6Ct7+uPYzyO9M1RTnR4yEgdg=
Bytes: 4160

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.