void expression_list(unsigned command, int i, int j)
{ struct list { int x; int y; };
static list* ram = NULL;
static int size = 0;

if(command=='add') {
ram = (list*) realloc(ram, size++ * sizeof(list) );
ram[size-1] = {i,j};
}

if(command=='reset') {
ram = (list*) realloc(ram, (size=0) * sizeof(list) );
}

if(command=='dump') {
for(int i=0; i<size; i++)
printf("\n %d: %d %d ", i, ram[i].x, ram[i].y);
}
if(command=='print sum') {
int sum_x =0 ; int sum_y =0 ;
for(int i=0; i<size; i++)
{
sum_x += ram[i].x;
sum_y += ram[i].y;
}
printf("\n sum: %d %d ", sum_x, sum_y);

}

return ;
}

this may be seen childish but for some reasons i found it as probably good and worth using as it may allow me to 'streamline' my c code and even increase productivity and code clarity

you use it obviously

expression_list('add', 1,222);
expression_list('add', 2,211);
expression_list('add', 3,22);
expression_list('add', 4,133);
expression_list('dump', 0,0);
expression_list('print sum',0,0);

there is a bug above should be ++size not size++

besides the name expresion_list is here becouse i added this experimenting with code that
will give me the boundaries of expresions like 2+ 3 b/b++ siz.a.b.c* (2 + 3) when they are not separated by commas or semicolons but just spaces

void FindExpressionsBoundaries()
{ chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");

chunks atoms = LineAtomizer4furia(txt);
int len = ChunksLength(atoms);

PrintChunks(atoms);

int expression_begin = 0;
int expression_end = -1;

expression_list('reset',-1,-1);

for(int i=0; i<len; i++)
{
if( !IsPunctuation(atoms.first[i ].end[0]) )
if( i+1<len) if(!IsPunctuation(atoms.first[i+1].beg[0]) )
{
expression_end = i;
expression_list('add', expression_begin, expression_end );
expression_begin = i+1;
}
}
expression_end = len-1;
expression_list('add', expression_begin, expression_end );
expression_list('dump', -1, -1 );

}

gives

0 a
1 *
2 b
3 +
4 c
5 *
6 (
7 f
8 +
9 +
10 )
11 /
12 size_x
13 100
14 -
15 400
16 /
17 c
18 /
19 f
20 .
21 a
22 +
23 40
24 c
25 *
26 c
27 *
28 doo
29 (
30 a
31 b
32 c
33 )
34 -
35 100
36 .
37 33
0: 0 12
1: 13 23
2: 24 30
3: 31 31
4: 32 37

the code may not look very good but its dam easy to composite use and reuse

On 4/28/2022 3:01 PM, fir wrote:
> you use it obviously

Multicharacter character constants produce implementation-defined values.

On a 32-bit-int platform a 2-4 character multicharacter character
constant is indeed viable for some uses, as long as you know what you
are doing and assuming that your compiler does what compilers "normally"
do in such cases.

But more than 4? That's just asking for trouble.

The code creates an illusion of something that isn't really there. And
it is not immediately obvious how that illusion works. E.g. even if your
compiler promises to concatenate up to 4 bytes, does it keep the first 4
or the last 4?

So no, longish multicharacter character constants are not a good
pattern. "Short" multicharacter character constants are acceptable when
you know what you are doing.

--
Best regards,
Andrey Tarasevich

piątek, 29 kwietnia 2022 o 01:24:07 UTC+2 Andrey Tarasevich napisał(a):
> On 4/28/2022 3:01 PM, fir wrote:
> > you use it obviously
>
> Multicharacter character constants produce implementation-defined values.
>
> On a 32-bit-int platform a 2-4 character multicharacter character
> constant is indeed viable for some uses, as long as you know what you
> are doing and assuming that your compiler does what compilers "normally"
> do in such cases.
>
> But more than 4? That's just asking for trouble.
>
> The code creates an illusion of something that isn't really there. And
> it is not immediately obvious how that illusion works. E.g. even if your
> compiler promises to concatenate up to 4 bytes, does it keep the first 4
> or the last 4?
>
> So no, longish multicharacter character constants are not a good
> pattern. "Short" multicharacter character constants are acceptable when
> you know what you are doing.
>
i know, there was discusiion on this here back then, i think on 64 bit there can be used 64 bit unsigned and thats nice 8 characters ..
here i dont much care as tis was side for ilustrating whole pattern and this 'command' format is a
side thing ..one could eventually use enum but i prefer this 'things' which i called ad-hoc enums and find
it great, ..i would probably prefer using it as i use and dont care being just aware when it may faiul and avoiding it using a bit of my brain

yhe thread is more n this pattern...i didnt seem it used i think its generally unused and i also
never used it (though once or twice i thinked on it)...i think people find it unnefective and thus stoped
them for thinking on it (also as nobody thinking on this then nobody thinking on this too) but doing some thinking shows to me that is in fact so good it just most probably should be in wide use..it simplifies codes a lot (and im happy with that at least some new idea in my head at least)

fir <profesor.fir@gmail.com> writes:

> void FindExpressionsBoundaries()
> {
> chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
>
> chunks atoms = LineAtomizer4furia(txt);
> int len = ChunksLength(atoms);
>
> PrintChunks(atoms);
<cut>
> gives
>
> 0 a
> 1 *
> 2 b
> 3 +
> 4 c
> 5 *
> 6 (
> 7 f
> 8 +
> 9 +

How will you distinguish between "++x" and "+ +x"?

--
Ben.

piątek, 29 kwietnia 2022 o 02:11:02 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > void FindExpressionsBoundaries()
> > {
> > chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
> >
> > chunks atoms = LineAtomizer4furia(txt);
> > int len = ChunksLength(atoms);
> >
> > PrintChunks(atoms);
> <cut>
> > gives
> >
> > 0 a
> > 1 *
> > 2 b
> > 3 +
> > 4 c
> > 5 *
> > 6 (
> > 7 f
> > 8 +
> > 9 +
> How will you distinguish between "++x" and "+ +x"?
>
i not thinked on this yet..this code is not finished (as it seen it works bad as it broke on args of nested function )... i need to invent some rule but the pattern i said simplify coding this a lot

piątek, 29 kwietnia 2022 o 01:34:03 UTC+2 fir napisał(a):
> a lot (and im happy with that at least some new idea in my head at least)

i dont know how to name this pattern, temporarely maybe i will name it functoid (functolist?) pattern

i made some test of efficiency out of curiiosity

inline void int_list(unsigned long long command, int i)
{ // printf("\n size of %d", sizeof(command));

struct list { int x; };
static list* ram = NULL;
static int storage = 1000;
static int size = 0;

if(command=='quick add')
{
size++;
ram[size-1].x = i;
return;

}

if(command=='prealoc')
{
storage=i;
size = 0;
ram = (list*) realloc(ram, storage * sizeof(list) );
return;
}

if(command=='add') {
size++;
if(size>=storage) storage*=4;
ram = (list*) realloc(ram, storage * sizeof(list) );
ram[size-1].x = i;
return;

}

if(command=='reset') {
storage=size=0;
ram = (list*) realloc(ram, storage * sizeof(list) );
return;

}

if(command=='dump') {
for(int i=0; i<size; i++)
printf("\n %d: %d ", i, ram[i].x);
return;

}
if(command=='print sum') {
int sum_x =0 ;
for(int i=0; i<size; i++) {
sum_x += ram[i].x;
}
printf("\n sum: %d ", sum_x);
return;

}

return ;
}

//////////

and such tests

TakeDeltaTimeNS(1);

for(int i=0; i<1000000; i++)
int_list('add', i);

int_list('print sum',-1);

double x = TakeDeltaTimeNS(1);

printf("(executed in %4.6f s)", x/1000/1000/1000);

TakeDeltaTimeNS(1);

int_list('prealoc',1000100);

for(int i=0; i<1000000; i++)
int_list('quick add', i);

int_list('print sum',-1);

x = TakeDeltaTimeNS(1);

printf("(executed in %4.6f s)", x/1000/1000/1000);

int list[1000000];

TakeDeltaTimeNS(1);

for(int i=0; i<1000000; i++)
list[i]=i;

int sum = 0;
for(int i=0; i<1000000; i++)
sum+=i;

printf("\n sum: %d", sum);

x = TakeDeltaTimeNS(1);

printf("(executed in %4.6f s)", x/1000/1000/1000);

gives :
um: 1783293664 (executed in 0.091765 s)
sum: 1783293664 (executed in 0.003252 s)
sum: 1783293664(executed in 0.000219 s)

this version that resizes on the run is slow 450x slower than native, that if is costly probably,
this with presetting size 15x slower which is sorta standable (depending how someone see things)

piątek, 29 kwietnia 2022 o 02:30:48 UTC+2 fir napisał(a):
> piątek, 29 kwietnia 2022 o 02:11:02 UTC+2 Ben napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > void FindExpressionsBoundaries()
> > > {
> > > chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
> > >
> > > chunks atoms = LineAtomizer4furia(txt);
> > > int len = ChunksLength(atoms);
> > >
> > > PrintChunks(atoms);
> > <cut>
> > > gives
> > >
> > > 0 a
> > > 1 *
> > > 2 b
> > > 3 +
> > > 4 c
> > > 5 *
> > > 6 (
> > > 7 f
> > > 8 +
> > > 9 +
> > How will you distinguish between "++x" and "+ +x"?
> >
> i not thinked on this yet..this code is not finished (as it seen it works bad as it broke on args of nested function )... i need to invent some rule but the pattern i said simplify coding this a lot

you may propose some rule or code if you want... i stopped thinking on this when coding this as i began to study this mentioned pattern more than the extracting expressions task

fir <profesor.fir@gmail.com> writes:

> piątek, 29 kwietnia 2022 o 02:11:02 UTC+2 Ben napisał(a):
>> fir <profes...@gmail.com> writes:
>>
>> > void FindExpressionsBoundaries()
>> > {
>> > chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
>> >
>> > chunks atoms = LineAtomizer4furia(txt);
>> > int len = ChunksLength(atoms);
>> >
>> > PrintChunks(atoms);
>> <cut>
>> > gives
>> >
>> > 0 a
>> > 1 *
>> > 2 b
>> > 3 +
>> > 4 c
>> > 5 *
>> > 6 (
>> > 7 f
>> > 8 +
>> > 9 +
>> How will you distinguish between "++x" and "+ +x"?
>>
> i not thinked on this yet..this code is not finished (as it seen it
> works bad as it broke on args of nested function )... i need to invent
> some rule but the pattern i said simplify coding this a lot

Sometimes it helps to think about things before you code too much. Once
you have only the three 'atoms' +, + and x it's too late to be able to
tell what the expression should be.

--
Ben.

piątek, 29 kwietnia 2022 o 03:28:51 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > piątek, 29 kwietnia 2022 o 02:11:02 UTC+2 Ben napisał(a):
> >> fir <profes...@gmail.com> writes:
> >>
> >> > void FindExpressionsBoundaries()
> >> > {
> >> > chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
> >> >
> >> > chunks atoms = LineAtomizer4furia(txt);
> >> > int len = ChunksLength(atoms);
> >> >
> >> > PrintChunks(atoms);
> >> <cut>
> >> > gives
> >> >
> >> > 0 a
> >> > 1 *
> >> > 2 b
> >> > 3 +
> >> > 4 c
> >> > 5 *
> >> > 6 (
> >> > 7 f
> >> > 8 +
> >> > 9 +
> >> How will you distinguish between "++x" and "+ +x"?
> >>
> > i not thinked on this yet..this code is not finished (as it seen it
> > works bad as it broke on args of nested function )... i need to invent
> > some rule but the pattern i said simplify coding this a lot
> Sometimes it helps to think about things before you code too much. Once
> you have only the three 'atoms' +, + and x it's too late to be able to
> tell what the expression should be.
>
im not sure what you re talking aboput .. in c there are rules thay says
what such thing as x++++y are and if i need to check if space is before something
i may write IsWhitespace(atom[i].beg[-1]) becouse pointers in chonks point into
pointers in oryginal text so no problem to read there

piątek, 29 kwietnia 2022 o 00:01:10 UTC+2 fir napisał(a):
> void expression_list(unsigned command, int i, int j)
> {
> struct list { int x; int y; };
> static list* ram = NULL;
> static int size = 0;
>
> if(command=='add') {
> ram = (list*) realloc(ram, size++ * sizeof(list) );
> ram[size-1] = {i,j};
> }
>
> if(command=='reset') {
> ram = (list*) realloc(ram, (size=0) * sizeof(list) );
> }
>
> if(command=='dump') {
> for(int i=0; i<size; i++)
> printf("\n %d: %d %d ", i, ram[i].x, ram[i].y);
> }
> if(command=='print sum') {
> int sum_x =0 ; int sum_y =0 ;
> for(int i=0; i<size; i++)
> {
> sum_x += ram[i].x;
> sum_y += ram[i].y;
> }
> printf("\n sum: %d %d ", sum_x, sum_y);
>
> }
>
> return ;
> }
>
> this may be seen childish but for some reasons i found it as probably good and worth using as it may allow me to 'streamline' my c code and even increase productivity and code clarity
>
> you use it obviously
>
> expression_list('add', 1,222);
> expression_list('add', 2,211);
> expression_list('add', 3,22);
> expression_list('add', 4,133);
> expression_list('dump', 0,0);
> expression_list('print sum',0,0);

one could ask why not use (c way)

expression_list_add(1,222);
expression_list_add'(2,211);
expression_list_add( 3,22);
expression_list_add'( 4,133);
expression_list_dump();
expression_list_print_sum();

which is faster (at least on cost of one to few if each time and also dont need to pass those unused
values and also is more general, or some c++ way like (probably as i dont use c++)

Expression_list expression_list();
expression_list.add(1,222);
expression_list.add'(2,211);
expression_list.add( 3,22);
expression_list.add'( 4,133);
expression_list.dump();
expression_list.print_sum();
~expression_list();

or micromodular c way
Expression_list expression_list
expression_list.add(1,222);
expression_list.add'(2,211);
expression_list.add( 3,22);
expression_list.add'( 4,133);
expression_list.dump();
expression_list.print_sum();

but there are some differences (and sad i feel like my head is weaker than back then is i guess i could name most important of them back then in a few seconds, now its hard to concentrate on this)

mostly in this is not only this interface form but whole pattern physically - and that whole pattern was
on static reallocked seed inside..and that is some difference, becouse that oryginal pattern is
n aturally 'narrow' ('streamlined') to be contained in one function

the minimal form was
void expression_list_collect(int i, int j)
{
struct list { int x; int y; };
static list* ram = NULL;
static int size = 0;

ram = (list*) realloc(ram, ++size * sizeof(list) );
ram[size-1] = {i,j};
}
and that was mostly what i needed just to collect data in compiler code
in improved c one can acces to static data of other functions (my invention from old times like 2005) so if i would like to print it i could

void expression_list_print()
{
for(int i=0; i<expression_list_collect.size; i++)
printf("\n %d: %d %d", i, expression_list_collect.ram[i].x, expression_list_collect.ram[i].y );
}

in c as in other languages too it is important to have consciousnes what is what
(and this what i cal 'streamlining' is aloso about that) and this consciousnes help
so whan i use expression_list('add', 1,222); and c++ expression_list.add(1,222)
the consciousnes is imo ona a side of the first.. it also beats expression_list_add(1,222);
form as here the fact of keeping this static seed in global (semiglobal, space of whole big module)
space is annoying ..it even beats conceptually micromodular way (though less) becouse its simpler,
more rooted than micromodular way (do this mean that there is more wild, more rooted c under micromodular c?) ..the shared static way i like (which is extension of oryginal) but the oryginal example is the best here (this inner pattern and this consciousness wins here, i guess)

rooted c, you see the drums?

piątek, 29 kwietnia 2022 o 09:58:23 UTC+2 fir napisał(a):
> piątek, 29 kwietnia 2022 o 00:01:10 UTC+2 fir napisał(a):
> > void expression_list(unsigned command, int i, int j)
> > {
> > struct list { int x; int y; };
> > static list* ram = NULL;
> > static int size = 0;
> >
> > if(command=='add') {
> > ram = (list*) realloc(ram, size++ * sizeof(list) );
> > ram[size-1] = {i,j};
> > }
> >
> > if(command=='reset') {
> > ram = (list*) realloc(ram, (size=0) * sizeof(list) );
> > }
> >
> > if(command=='dump') {
> > for(int i=0; i<size; i++)
> > printf("\n %d: %d %d ", i, ram[i].x, ram[i].y);
> > }
> > if(command=='print sum') {
> > int sum_x =0 ; int sum_y =0 ;
> > for(int i=0; i<size; i++)
> > {
> > sum_x += ram[i].x;
> > sum_y += ram[i].y;
> > }
> > printf("\n sum: %d %d ", sum_x, sum_y);
> >
> > }
> >
> > return ;
> > }
> >
> > this may be seen childish but for some reasons i found it as probably good and worth using as it may allow me to 'streamline' my c code and even increase productivity and code clarity
> >
> > you use it obviously
> >
> > expression_list('add', 1,222);
> > expression_list('add', 2,211);
> > expression_list('add', 3,22);
> > expression_list('add', 4,133);
> > expression_list('dump', 0,0);
> > expression_list('print sum',0,0);
> one could ask why not use (c way)
>
> expression_list_add(1,222);
> expression_list_add'(2,211);
> expression_list_add( 3,22);
> expression_list_add'( 4,133);
> expression_list_dump();
> expression_list_print_sum();
>
>
> which is faster (at least on cost of one to few if each time and also dont need to pass those unused
> values and also is more general, or some c++ way like (probably as i dont use c++)
>
> Expression_list expression_list();
> expression_list.add(1,222);
> expression_list.add'(2,211);
> expression_list.add( 3,22);
> expression_list.add'( 4,133);
> expression_list.dump();
> expression_list.print_sum();
> ~expression_list();
>
> or micromodular c way
> Expression_list expression_list
> expression_list.add(1,222);
> expression_list.add'(2,211);
> expression_list.add( 3,22);
> expression_list.add'( 4,133);
> expression_list.dump();
> expression_list.print_sum();
>
> but there are some differences (and sad i feel like my head is weaker than back then is i guess i could name most important of them back then in a few seconds, now its hard to concentrate on this)
>
> mostly in this is not only this interface form but whole pattern physically - and that whole pattern was
> on static reallocked seed inside..and that is some difference, becouse that oryginal pattern is
> n aturally 'narrow' ('streamlined') to be contained in one function
>
> the minimal form was
> void expression_list_collect(int i, int j)
> {
> struct list { int x; int y; };
> static list* ram = NULL;
> static int size = 0;
> ram = (list*) realloc(ram, ++size * sizeof(list) );
> ram[size-1] = {i,j};
> }
> and that was mostly what i needed just to collect data in compiler code
> in improved c one can acces to static data of other functions (my invention from old times like 2005) so if i would like to print it i could
>
> void expression_list_print()
> {
> for(int i=0; i<expression_list_collect.size; i++)
> printf("\n %d: %d %d", i, expression_list_collect.ram[i].x, expression_list_collect.ram[i].y );
> }
>
> in c as in other languages too it is important to have consciousnes what is what
> (and this what i cal 'streamlining' is aloso about that) and this consciousnes help
> so whan i use expression_list('add', 1,222); and c++ expression_list.add(1,222)
> the consciousnes is imo ona a side of the first.. it also beats expression_list_add(1,222);
> form as here the fact of keeping this static seed in global (semiglobal, space of whole big module)
> space is annoying ..it even beats conceptually micromodular way (though less) becouse its simpler,
> more rooted than micromodular way (do this mean that there is more wild, more rooted c under micromodular c?) ..the shared static way i like (which is extension of oryginal) but the oryginal example is the best here (this inner pattern and this consciousness wins here, i guess)
>
> rooted c, you see the drums?

its also reminder how this cross acces to static is needed.. i will write my own extended c compiler giving that and the rest , but just having it in C would make this language notably stronger

the second thing of this measure (this level) is that static seeds that are not global but tied to place of call, this above example dont show this becouse if i would put
expression_list.add(1,222);
expression_list.add'(2,211);
each one would produce its own static seed seed, but there are cases when this populating static seed
is needed...like say
chunks atoms = atomize("ala ma kota");
chunks atoms2 = atomize("the mouse is climbing up the leg of the chair");
shouldnt reuse the same static internally, maybe there should be the keyword to put before atomize() im not sure (or maybe even atomize[1]("ala ma cota") ..this last seem intresting becouse the lack of cloning function in c is breaking the fractal symmetry of it which are finding by me when making micromodules, so finding the real case when its needed seem ok...though as i once said im not convinced if my rectangle seeing on c is not at all wack as oryginal c is as i said more rooted, and this impresses me , sorta gives to think if its not better than what i got (not saying micromodules are useless)

piątek, 29 kwietnia 2022 o 03:28:51 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > piątek, 29 kwietnia 2022 o 02:11:02 UTC+2 Ben napisał(a):
> >> fir <profes...@gmail.com> writes:
> >>
> >> > void FindExpressionsBoundaries()
> >> > {
> >> > chunk txt = Chunk(" a*b + c*(f++)/size_x 100-400/c/f.a + 40 c * c * doo(a b c) -100.33");
> >> >
> >> > chunks atoms = LineAtomizer4furia(txt);
> >> > int len = ChunksLength(atoms);
> >> >
> >> > PrintChunks(atoms);
> >> <cut>
> >> > gives
> >> >
> >> > 0 a
> >> > 1 *
> >> > 2 b
> >> > 3 +
> >> > 4 c
> >> > 5 *
> >> > 6 (
> >> > 7 f
> >> > 8 +
> >> > 9 +
> >> How will you distinguish between "++x" and "+ +x"?
> >>
> > i not thinked on this yet..this code is not finished (as it seen it
> > works bad as it broke on args of nested function )... i need to invent
> > some rule but the pattern i said simplify coding this a lot
> Sometimes it helps to think about things before you code too much. Once
> you have only the three 'atoms' +, + and x it's too late to be able to
> tell what the expression should be.
>

this is recognized on level below atomizer and its not so hard, often the small if three suffice

if(atoms_len >= 6) // double a = 23.45
if( CCS(a0, "double") || CCS(a0, "%") )
if( CCL(a1) )
if( CCS(a2, "=") )
if( CCI(a3) )
if( CCS(a4, ".") )
if( CCI(a5) )
{
FlushOutAsmChunkPE("\n\n// compiling expression ", all.first[i], " ");
FlushOutAsm("\n ?? %.*s: %.*s.%.*sd ", ChunkLength(a1) , a1.beg, ChunkLength(a3) , a3.beg, ChunkLength(a5) , a5.beg );

}
where CCS means "compare chunk string" CCI "check chunk integer" CCL "check chunk label"
i should hovever produce tagged output in atomizer and replace it by if(a4.tag=='int') i didnt do
that becouse thoise function seemd to me looked simpler but im not sure probably tags are even simpler
and without tags its kinda runtime nonsense (though some may say not becouse if i tag whole line
i call say 40 functions, to tag it and in if i may go out after first failed...though in real case probably seems tags are more practical)

piątek, 29 kwietnia 2022 o 01:24:07 UTC+2 Andrey Tarasevich napisał(a):
> On 4/28/2022 3:01 PM, fir wrote:
> > you use it obviously
>
> Multicharacter character constants produce implementation-defined values.
>
> On a 32-bit-int platform a 2-4 character multicharacter character
> constant is indeed viable for some uses, as long as you know what you
> are doing and assuming that your compiler does what compilers "normally"
> do in such cases.
>
> But more than 4? That's just asking for trouble.
>
> The code creates an illusion of something that isn't really there. And
> it is not immediately obvious how that illusion works. E.g. even if your
> compiler promises to concatenate up to 4 bytes, does it keep the first 4
> or the last 4?
>
> So no, longish multicharacter character constants are not a good
> pattern. "Short" multicharacter character constants are acceptable when
> you know what you are doing.
>
and what with using long long int command; and limit self to 8-character long comands at most? do this have serious disadvantages?

note im using gcc/mingw in 32 bit mode (i even work on 32 bit old comp becouse writing assembler
i decided to use 32 bit in 32 bit pe-environment) i do not much care from automatic compatibility
when compiling to 64-bit /other oses ..becouse i would need to revrite asembler at all (its system dependant).. i prefer binary compatibility overally

piątek, 29 kwietnia 2022 o 12:39:59 UTC+2 fir napisał(a):
> piątek, 29 kwietnia 2022 o 01:24:07 UTC+2 Andrey Tarasevich napisał(a):
> > On 4/28/2022 3:01 PM, fir wrote:
> > > you use it obviously
> >
> > Multicharacter character constants produce implementation-defined values.
> >
> > On a 32-bit-int platform a 2-4 character multicharacter character
> > constant is indeed viable for some uses, as long as you know what you
> > are doing and assuming that your compiler does what compilers "normally"
> > do in such cases.
> >
> > But more than 4? That's just asking for trouble.
> >
> > The code creates an illusion of something that isn't really there. And
> > it is not immediately obvious how that illusion works. E.g. even if your
> > compiler promises to concatenate up to 4 bytes, does it keep the first 4
> > or the last 4?
> >
> > So no, longish multicharacter character constants are not a good
> > pattern. "Short" multicharacter character constants are acceptable when
> > you know what you are doing.
> >
> and what with using long long int command; and limit self to 8-character long comands at most? do this have serious disadvantages?
>
> note im using gcc/mingw in 32 bit mode (i even work on 32 bit old comp becouse writing assembler
> i decided to use 32 bit in 32 bit pe-environment) i do not much care from automatic compatibility
> when compiling to 64-bit /other oses ..becouse i would need to revrite asembler at all (its system dependant).. i prefer binary compatibility overally

btw why bartc is so inactive here?
i once was writing he do weird thing fighting the same battles 200+ times instead of say 5 or 10
(becouse inded not much sense in this, hovever 'side effects' of that repeating could (and did) give some value) but on other side cuting activity to such low makes this group less active, and bartc generally was ablle to 'carry' some topics

piątek, 29 kwietnia 2022 o 09:58:23 UTC+2 fir napisał(a):
>
> or micromodular c way
> Expression_list expression_list
> expression_list.add(1,222);
> expression_list.add'(2,211);
> expression_list.add( 3,22);
> expression_list.add'( 4,133);
> expression_list.dump();
> expression_list.print_sum();
>
hovever i might omit dots here in micromodular/C2 way

Expression_list expression_list
expression_list add(1,222);
expression_list add'(2,211);
expression_list add( 3,22);
expression_list add'( 4,133);
expression_list dump();
expression_list print_sum();

i could also mention that in micromodular schemes one could also not instantiate expression_list
and treat those fields as a field of function (function/module), so

expression_list.add(1,222);
expression_list.add'(2,211);
expression_list.add( 3,22);
expression_list.add'( 4,133);
expression_list.dump();
expression_list.print_sum();

as to present practice i may say that writing it old c way like

struct Expression_list { int x; int y; };
static Expression_list* expression_list = NULL;
static int expression_list_size = 0;

void expression_list_AddBoundary(int i, int j)
{
expression_list_size++;
expression_list = (Expression_list*) realloc(expression_list, expression_list_size * sizeof(Expression_list)
expression_list[expression_list_size-1] = {i,j};
return ;
}
is in fact tiring - it also polutes this semiglobal space with not needed symbols

in this command attempt there are also those mentioned problems yet also there is a problem of
somethink like reading the colected list out ... some may code it this way that this collected list is passed down the tree but reading it out is also needed
standable seems to use semiglobal filds like

void* ret_list = NULL;
int ret_list_size = -1;

add comand ret

if(command=='ret')
{
ret_list = ram;
ret_list_size = size;
}

and use it something like

void TranslateCollectedExpressions(chunks arg_atoms)
{ expression_list('ret', -1, -1 );

for(int i=0; i<ret_list_size; i++)
{
struct list { int x; int y; };

int x = ((list*)ret_list)[i].x;
int y = ((list*)ret_list)[i].y;

chunks atoms = { &arg_atoms.first[x], &arg_atoms.first[y] } ;

int len = ChunksLength(atoms);
if(len==0) continue;
if(len==1) continue;
if(len==2) continue;

compile_expression(atoms);

}
}