Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #143131 > unrolled thread

for ... else blocks

Back to article view | Back to comp.lang.c

Contents

  for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 14:57 -0400
    Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 15:06 -0400
      Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-16 20:35 +0100
        Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 17:02 -0400
          Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-16 23:36 +0200
            Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 00:45 +0200
              Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-17 01:06 +0100
                Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 04:45 +0200
                  Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 09:32 +0200
                    Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 11:38 +0100
                      Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 14:05 +0200
                        Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 13:57 +0100
                          Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 15:36 +0200
                            Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 15:16 +0100
                              Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 17:51 +0200
                          Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 16:15 +0200
                            Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 16:24 +0200
                            Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 17:55 +0200
                            Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 17:44 +0100
                              Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 17:48 +0100
                                Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:18 -0700
                                  Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:32 -0700
                                    Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:38 -0700
                                    Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:12 -0700
                                      Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:25 -0700
                                        Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:39 -0700
                                          Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 15:52 -0700
                                            Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 16:50 -0700
                                      Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 13:58 -0700
                              Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-18 12:21 +0200
                                Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-18 18:54 +0100
                                  Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 20:36 +0100
                                    Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-18 21:15 +0100
                                      Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 21:46 +0100
                        Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 15:05 +0100
                          Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-17 10:55 -0400
                        Re: for ... else blocks Ike Naar <ike@iceland.freeshell.org> - 2019-04-18 05:57 +0000
                  Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-17 20:43 +0100
    Re: for ... else blocks Chad <cdalten@gmail.com> - 2019-04-16 12:15 -0700
    Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-16 20:27 +0100
    Re: for ... else blocks Christian Gollwitzer <auriocus@gmx.de> - 2019-04-16 21:34 +0200
      Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 16:54 -0400
      Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-16 23:32 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#143182

W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> On 17/04/2019 17:44, Bart wrote:
> 
> > As a reminder, here's my original for-else example in a bigger context:
> > 
> >    https://pastebin.com/Yv6xQg92
> 
> (That guest paste doesn't seem to work. Try:
> 
>   https://pastebin.com/raw/bNUNjk4K)

this doesnt look good to be honest
(may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)

as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .

overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way

just turn code into micromodules (may it be loop parts too) and this could grant something

[toc] | [prev] | [next] | [standalone]

#143183

W dniu środa, 17 kwietnia 2019 19:18:59 UTC+2 użytkownik fir napisał:
> W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> > On 17/04/2019 17:44, Bart wrote:
> > 
> > > As a reminder, here's my original for-else example in a bigger context:
> > > 
> > >    https://pastebin.com/Yv6xQg92
> > 
> > (That guest paste doesn't seem to work. Try:
> > 
> >   https://pastebin.com/raw/bNUNjk4K)
> 
> this doesnt look good to be honest
> (may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)
> 
> as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .
> 
> overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way
> 
> just turn code into micromodules (may it be loop parts too) and this could grant something

micromodules hovever seem heavy topic that i just simply opened (once ago)

look for example (somy maybe bad exampe but im not in a mood for longer thinking)

loop(10,10) print loop.x loop.y  

loop is a micromodule that you could initiate with two parameters and it works like 'loop generator'  on its rightside 

someone could say that flat

10y 10x print z y.

looks much simpler (and thats true) but generators could be very much more generalized

components could communiate in very complex ways and thsi could grant the power of easy and fast programming only if you get them loaded/already written

[toc] | [prev] | [next] | [standalone]

#143184

W dniu środa, 17 kwietnia 2019 19:34:37 UTC+2 użytkownik fir napisał:
> W dniu środa, 17 kwietnia 2019 19:18:59 UTC+2 użytkownik fir napisał:
> > W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> > > On 17/04/2019 17:44, Bart wrote:
> > > 
> > > > As a reminder, here's my original for-else example in a bigger context:
> > > > 
> > > >    https://pastebin.com/Yv6xQg92
> > > 
> > > (That guest paste doesn't seem to work. Try:
> > > 
> > >   https://pastebin.com/raw/bNUNjk4K)
> > 
> > this doesnt look good to be honest
> > (may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)
> > 
> > as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .
> > 
> > overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way
> > 
> > just turn code into micromodules (may it be loop parts too) and this could grant something
> 
> micromodules hovever seem heavy topic that i just simply opened (once ago)
> 
> look for example (somy maybe bad exampe but im not in a mood for longer thinking)
> 
> loop(10,10) print loop.x loop.y  
> 
> loop is a micromodule that you could initiate with two parameters and it works like 'loop generator'  on its rightside 
> 
> someone could say that flat
> 
> 10y 10x print z y.
> 

sorry should be

10y 10x print x y ..

or id someone likes 
(10y (10x (print x y)))
etc


> looks much simpler (and thats true) but generators could be very much more generalized
> 
> components could communiate in very complex ways and thsi could grant the power of easy and fast programming only if you get them loaded/already written

[toc] | [prev] | [next] | [standalone]

#143185

W dniu środa, 17 kwietnia 2019 19:34:37 UTC+2 użytkownik fir napisał:
> W dniu środa, 17 kwietnia 2019 19:18:59 UTC+2 użytkownik fir napisał:
> > W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> > > On 17/04/2019 17:44, Bart wrote:
> > > 
> > > > As a reminder, here's my original for-else example in a bigger context:
> > > > 
> > > >    https://pastebin.com/Yv6xQg92
> > > 
> > > (That guest paste doesn't seem to work. Try:
> > > 
> > >   https://pastebin.com/raw/bNUNjk4K)
> > 
> > this doesnt look good to be honest
> > (may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)
> > 
> > as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .
> > 
> > overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way
> > 
> > just turn code into micromodules (may it be loop parts too) and this could grant something
> 
> micromodules hovever seem heavy topic that i just simply opened (once ago)
> 
> look for example (somy maybe bad exampe but im not in a mood for longer thinking)
> 
> loop(10,10) print loop.x loop.y  
> 
> loop is a micromodule that you could initiate with two parameters and it works like 'loop generator'  on its rightside 
> 
> someone could say that flat
> 
> 10y 10x print z y.
> 
> looks much simpler (and thats true) but generators could be very much more generalized
> 
> components could communiate in very complex ways and thsi could grant the power of easy and fast programming only if you get them loaded/already written

i could say that imo normal c i could say level-1 c, raw c, where micromodules could name as level-2 c (hovever it is picture naming only as in this prospect functions and modules (dll's, people still dont udnerstand how dlls are important part of c) would be level 1.5
or something

and i somewhat doubt if many could be done to loops in raw c (except syntax and so on)


i can generally say also that once ago i was in some doubt if various 'automiatisations' (and micromodules are such kind of automatisations) should be part of c but now im close to think thet they should (old c will stay untouched anyway, and level-1 c still'llbe avaliable)

as to other automatisation. thought from today:

some people thinked if such think as 
rectangle or line segment should be 
writen as start+length or rather stert+end

if use micromodule you could define line segment that stores this binary information in internal form and got all fields you want

segment.start +=10
segment.length +=10
segment.end +=10

same with rectangle (as micromodule it stores internally and provides all kind of fields you want so you dont more bother, and to function you just pass segment or rectangle and dont bother by the fact you 'break the symetry')

same it is with complex number like
"complex float x" where you could acces
x.module, x.angle, x.re, x.im
(i once remember, i was writing on it
and how it could help in 2d drawing, but today i realized it a but more (as a cure for tis kind of 'symetry' (if to name it unprecisely) problems)

also i kno that naming it as a micromodule may be a bit to much in this case at it is quite simple micromodule that only has some virtual fields added, but in fact this is some simple type of micromodule so it fits (micromodules just offer more)

will eat an apple i guess

[toc] | [prev] | [next] | [standalone]

#143186

W dniu środa, 17 kwietnia 2019 21:13:00 UTC+2 użytkownik fir napisał:
> W dniu środa, 17 kwietnia 2019 19:34:37 UTC+2 użytkownik fir napisał:
> > W dniu środa, 17 kwietnia 2019 19:18:59 UTC+2 użytkownik fir napisał:
> > > W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> > > > On 17/04/2019 17:44, Bart wrote:
> > > > 
> > > > > As a reminder, here's my original for-else example in a bigger context:
> > > > > 
> > > > >    https://pastebin.com/Yv6xQg92
> > > > 
> > > > (That guest paste doesn't seem to work. Try:
> > > > 
> > > >   https://pastebin.com/raw/bNUNjk4K)
> > > 
> > > this doesnt look good to be honest
> > > (may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)
> > > 
> > > as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .
> > > 
> > > overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way
> > > 
> > > just turn code into micromodules (may it be loop parts too) and this could grant something
> > 
> > micromodules hovever seem heavy topic that i just simply opened (once ago)
> > 
> > look for example (somy maybe bad exampe but im not in a mood for longer thinking)
> > 
> > loop(10,10) print loop.x loop.y  
> > 
> > loop is a micromodule that you could initiate with two parameters and it works like 'loop generator'  on its rightside 
> > 
> > someone could say that flat
> > 
> > 10y 10x print z y.
> > 
> > looks much simpler (and thats true) but generators could be very much more generalized
> > 
> > components could communiate in very complex ways and thsi could grant the power of easy and fast programming only if you get them loaded/already written
> 
> i could say that imo normal c i could say level-1 c, raw c, where micromodules could name as level-2 c (hovever it is picture naming only as in this prospect functions and modules (dll's, people still dont udnerstand how dlls are important part of c) would be level 1.5
> or something
> 
> and i somewhat doubt if many could be done to loops in raw c (except syntax and so on)
> 
> 
> i can generally say also that once ago i was in some doubt if various 'automiatisations' (and micromodules are such kind of automatisations) should be part of c but now im close to think thet they should (old c will stay untouched anyway, and level-1 c still'llbe avaliable)
> 
> as to other automatisation. thought from today:
> 
> some people thinked if such think as 
> rectangle or line segment should be 
> writen as start+length or rather stert+end
> 
> if use micromodule you could define line segment that stores this binary information in internal form and got all fields you want
> 
> segment.start +=10
> segment.length +=10
> segment.end +=10
> 
> same with rectangle (as micromodule it stores internally and provides all kind of fields you want so you dont more bother, and to function you just pass segment or rectangle and dont bother by the fact you 'break the symetry')
> 
> same it is with complex number like
> "complex float x" where you could acces
> x.module, x.angle, x.re, x.im
> (i once remember, i was writing on it
> and how it could help in 2d drawing, but today i realized it a but more (as a cure for tis kind of 'symetry' (if to name it unprecisely) problems)
> 
> also i kno that naming it as a micromodule may be a bit to much in this case at it is quite simple micromodule that only has some virtual fields added, but in fact this is some simple type of micromodule so it fits (micromodules just offer more)
> 
> will eat an apple i guess

i also know that this idea to have more fields (in a form of properties/getters/setters or sh*t like that) than real 'storage fields' is not new, as you may write such think in c++ probably, and probably people was writing this (which was probably considered as a sorta cr*p)

buit this is a difference of seing it like in c++ or other class-baset oop sh*t and seeing it as a right way in another context (like my improved c context im talking about)

(so this is not the same, really there is drastic difference... some part of this difference is that it is not only some proposition on idea, which ona can see somewhere or state, but also a cost 
of "logical proof" attached (the proof that says if it is good or wrong, and i personally work in the area of that kind
of proofs not just 'results' )

[toc] | [prev] | [next] | [standalone]

#143187

W dniu środa, 17 kwietnia 2019 21:25:48 UTC+2 użytkownik fir napisał:
> W dniu środa, 17 kwietnia 2019 21:13:00 UTC+2 użytkownik fir napisał:
> > W dniu środa, 17 kwietnia 2019 19:34:37 UTC+2 użytkownik fir napisał:
> > > W dniu środa, 17 kwietnia 2019 19:18:59 UTC+2 użytkownik fir napisał:
> > > > W dniu środa, 17 kwietnia 2019 18:48:40 UTC+2 użytkownik Bart napisał:
> > > > > On 17/04/2019 17:44, Bart wrote:
> > > > > 
> > > > > > As a reminder, here's my original for-else example in a bigger context:
> > > > > > 
> > > > > >    https://pastebin.com/Yv6xQg92
> > > > > 
> > > > > (That guest paste doesn't seem to work. Try:
> > > > > 
> > > > >   https://pastebin.com/raw/bNUNjk4K)
> > > > 
> > > > this doesnt look good to be honest
> > > > (may be ok for some fans on oldschool typewriters who are alergic on operators -  c in some part heaily 'stands' on operators, c is operators)
> > > > 
> > > > as to how if (and alike blocks) should like the most simple as i found (over many thinking) is that closing dot -> .
> > > > 
> > > > overally if someone want to improve c construct he shoudnt go that imbeclie route liek hodgin level anty-ideas or mass-medicores-way like lambdas/closures but rather the micromodules way
> > > > 
> > > > just turn code into micromodules (may it be loop parts too) and this could grant something
> > > 
> > > micromodules hovever seem heavy topic that i just simply opened (once ago)
> > > 
> > > look for example (somy maybe bad exampe but im not in a mood for longer thinking)
> > > 
> > > loop(10,10) print loop.x loop.y  
> > > 
> > > loop is a micromodule that you could initiate with two parameters and it works like 'loop generator'  on its rightside 
> > > 
> > > someone could say that flat
> > > 
> > > 10y 10x print z y.
> > > 
> > > looks much simpler (and thats true) but generators could be very much more generalized
> > > 
> > > components could communiate in very complex ways and thsi could grant the power of easy and fast programming only if you get them loaded/already written
> > 
> > i could say that imo normal c i could say level-1 c, raw c, where micromodules could name as level-2 c (hovever it is picture naming only as in this prospect functions and modules (dll's, people still dont udnerstand how dlls are important part of c) would be level 1.5
> > or something
> > 
> > and i somewhat doubt if many could be done to loops in raw c (except syntax and so on)
> > 
> > 
> > i can generally say also that once ago i was in some doubt if various 'automiatisations' (and micromodules are such kind of automatisations) should be part of c but now im close to think thet they should (old c will stay untouched anyway, and level-1 c still'llbe avaliable)
> > 
> > as to other automatisation. thought from today:
> > 
> > some people thinked if such think as 
> > rectangle or line segment should be 
> > writen as start+length or rather stert+end
> > 
> > if use micromodule you could define line segment that stores this binary information in internal form and got all fields you want
> > 
> > segment.start +=10
> > segment.length +=10
> > segment.end +=10
> > 
> > same with rectangle (as micromodule it stores internally and provides all kind of fields you want so you dont more bother, and to function you just pass segment or rectangle and dont bother by the fact you 'break the symetry')
> > 
> > same it is with complex number like
> > "complex float x" where you could acces
> > x.module, x.angle, x.re, x.im
> > (i once remember, i was writing on it
> > and how it could help in 2d drawing, but today i realized it a but more (as a cure for tis kind of 'symetry' (if to name it unprecisely) problems)
> > 
> > also i kno that naming it as a micromodule may be a bit to much in this case at it is quite simple micromodule that only has some virtual fields added, but in fact this is some simple type of micromodule so it fits (micromodules just offer more)
> > 
> > will eat an apple i guess
> 
> i also know that this idea to have more fields (in a form of properties/getters/setters or sh*t like that) than real 'storage fields' is not new, as you may write such think in c++ probably, and probably people was writing this (which was probably considered as a sorta cr*p)
> 
> buit this is a difference of seing it like in c++ or other class-baset oop sh*t and seeing it as a right way in another context (like my improved c context im talking about)
> 
> (so this is not the same, really there is drastic difference... some part of this difference is that it is not only some proposition on idea, which ona can see somewhere or state, but also a cost 
> of "logical proof" attached (the proof that says if it is good or wrong, and i personally work in the area of that kind
> of proofs not just 'results' )

i also know that this may be considered not so much efficient (say like you store complex float x as a pait or float re, float im internally and when operating on x.angle you translate it back and forth where you may lost some 
results in module/angle form and make some unnecessary arithmetic, but

1) it could be optimised on micromosule source level (in some way, i mamen codar kan cnow what he do)
2) there is an area for compilers to show some skills

and most important
3) i was doing heavy optimisation work in c and im not terribly lame in thit, i mean i know somewhat how to do it (got some experience) and what i found there was the pleasure when starting from some level and optimise it... also i am a coder of prototypes in turn who want to type runing code fast and dont bother of optimistation so i understand the value of easy coding... this blend to teh fact that it is nice to get a code and optymise it from some treshold into much faster code i mean for optymisers its fine to start form sane code that they coud do optimise so i men this situation is not a sin imo... just youre sometimes coder sometimes optymiser and booth kind of people are needed imo
(this is somewhat convincing view i got on optimisation  matters and for me it would just mean using this kind of micromodules is ok... though non optimised codes would be slower that c probably)

[toc] | [prev] | [next] | [standalone]

#143198

W dniu środa, 17 kwietnia 2019 21:39:44 UTC+2 użytkownik fir napisał:
> 
> i also know that this may be considered not so much efficient (say like you store complex float x as a pait or float re, float im internally and when operating on x.angle you translate it back and forth where you may lost some 
> results in module/angle form and make some unnecessary arithmetic, but
> 
> 1) it could be optimised on micromosule source level (in some way, i mamen codar kan cnow what he do)
> 2) there is an area for compilers to show some skills
> 
> and most important
> 3) i was doing heavy optimisation work in c and im not terribly lame in thit, i mean i know somewhat how to do it (got some experience) and what i found there was the pleasure when starting from some level and optimise it... also i am a coder of prototypes in turn who want to type runing code fast and dont bother of optimistation so i understand the value of easy coding... this blend to teh fact that it is nice to get a code and optymise it from some treshold into much faster code i mean for optymisers its fine to start form sane code that they coud do optimise so i men this situation is not a sin imo... just youre sometimes coder sometimes optymiser and booth kind of people are needed imo
> (this is somewhat convincing view i got on optimisation  matters and for me it would just mean using this kind of micromodules is ok... though non optimised codes would be slower that c probably)


i may also add some thing: years ago i remember i wrote some text with some remark that i see some codes in c are write this way that it transforms some data that has some physical meaning where some other uses some data whose
purpose is liek being a 'cache', to speed up things or something - and i called this second part as a 'dirty'

it may be note that most probably all
that coding that is 'technical support' but not 'physically substantional' maybe should be avooided.. and maybe in a way it is kinda bloat (it is c bloat so it is not quite a bloat like oop trash but
in some abstract plane it may be seen as a bloat.. ehen you even say write fopen fclose and all that instead of something like char[] f = raad_file("some.txt"),
i mean code that is not enough compact may be considered as a bloated (and incidentally i think that micromodules could eventually be used to remove various bloat maybe)

here in case of that virtual structures the topic of 'cache data' seems like reappears, as it seems that when use some virtual fields results could be generated in some internal cache then eventually skipped

it seems that generally when having some 
micromodule/virtual structure wiyh virtual fields it could have its cache storage logically attached.. it seem tahat this cache for example could be

1) being as a part of that virtual structure storage (oficallly, like say complex float would have 4 floats .re .im .angle (or was it called .phase?) and .module instead of two)

2) this cache could eb attached but outside the structure storage (and being attached one per type not one per entity)

3) same as above but for each entity 

(and so on, maybe something more)

i mean when using such virtual structures caching begin to be 'official' topic, and it maybe may be good (i mean at least maybe it can have good side, apart it may also have bad)
as like i said before i once thinked that separation of this caching 'dirty'/'technical support' code and 
more substantional 'physical' code might be good

but couldnt say too much on it today

(problem is what i entioned if to put all that caching into bacground it still will be used and if coder not manages it
byself it generally will probably make it working slower than if managing it
in foreground 0 though maybe todays function interfaces also do such kind of slowdown too? (as they hide details in libraries) im not sure

[toc] | [prev] | [next] | [standalone]

#143199

yet other examples could be 24/32 bit color value (birtual structure rgb/hsv) 
it could be interesting to rethink implementation of it

even simple int could and probably should be virtual like when multiplication 
c = 1000000*1000000; if(c.higher>0) ...
i mean 32 bit int could be virtually 64 bit and thiat higher part could be accesible though being this cache part (which is grounded in x86 assembly as this part is accesible)

[toc] | [prev] | [next] | [standalone]

#143197

i could add it is overally intriguing that so many things in programming are this nature that simple 'storage structure' 
not quite 'covers' them

and then addition of more virtual fields
covers them better

some examples whan i think on it are even quite elaborate or subtle like say take triangle (thsi basic one used in 3D)
as a structure it is 9 floats, but it also has some subtle virtual quality as 
orientation, i mean which side is front wchich one is back  (and thi is not in field but just order of those floats/vertices defines it) overally whole 'normal' of it is derivative/derivation information

besides if to 'bunch' some of that things together it may get more other virtual qualities (say like adding line segments together to get some wire model may have some virtual field of center of a mass or orientation of that model etc etc


overally i think turning from normal structures into that extended more virtual one (some shallow step to tyet more complex micromodules) is good move,
would simplify thinking on things in programming (as raw structures in that wiew seem very low level)

[toc] | [prev] | [next] | [standalone]

#143202

On 17/04/2019 18:44, Bart wrote:
> On 17/04/2019 15:15, Alf P. Steinbach wrote:
>> On 17.04.2019 14:57, Bart wrote:
>>> [snip] By higher level I mean something like:
>>>
>>>      do_option(name in optionnames, value)
>>>
>>> 'in' would return 1..len or 0, so do_option would have to deal with a 
>>> option code of 0, to keep it simple.
>>
>> That places responsibility for dealing with an unknown option down in 
>> `do_option`, via an `if` or `switch` or something.
> 
> Yeah, I forgot about the error message. Then do_option can just return 
> the option number (or a status), and it becomes necessary to wrap withe 
> do_option call with an 'if'.
> 
> Dealing with option 0 inside do_option is not an issue (in my code it 
> means adding one line 'when 0 then' to ignore that option number).
> 
>  > Consider also
>  >
>  >      [](){
>  >          for( const& string item: optionnames ) {
>  >              if( item == name ) {
>  >                  app::do_option( 1 + &item - &optionnames[0], value );
>  >                  return;
>  >              }
>  >          }
>  >          my::fail( ""s + __func__ + " - unknown option '" + name + 
> "'" );
>  >      }();
>  >
>  > `return` is a nice statement; here it returns to the point after the
>  > last semicolon.
> 
> So, defining an anonymous function, immediately calling it, and using 
> 'return' to provide the alternate exit path from the loop that is required.
> 
> Clever, but the kind of cleverness that obscures the mundane task that 
> we are actually trying to do [in this case].
> 
> As a reminder, here's my original for-else example in a bigger context:
> 
>    https://pastebin.com/Yv6xQg92
> 
> (This processes command-line options and filenames for a C compiler, but 
> the same pattern is used in several programs.)
> 
> This bit doesn't need to be fast, and it doesn't need to be clever.

Since it doesn't need to be fast, and doesn't need to be clever, what's 
wrong with existing C solutions - using a boolean flag, splitting things 
out into a separate function (you can give it a name, rather than using 
a lambda), or using a goto ?

If your language already has a "for/else" statement, then it's fair 
enough to use it, of course.

[toc] | [prev] | [next] | [standalone]

#143203

On 18/04/2019 11:21, David Brown wrote:
> On 17/04/2019 18:44, Bart wrote:

>> This bit doesn't need to be fast, and it doesn't need to be clever.
> 
> Since it doesn't need to be fast, and doesn't need to be clever, what's 
> wrong with existing C solutions - using a boolean flag, splitting things 
> out into a separate function (you can give it a name, rather than using 
> a lambda), or using a goto ?
> 
> If your language already has a "for/else" statement, then it's fair 
> enough to use it, of course.
>

Well, this is the point really. If a feature is reliably available, then 
you just use it because it's convenient. Instead of inventing a solution 
or rewriting a pattern you've used 100s of times before.

Same argument with the subject of multi-level loop breaks. If writing C, 
then every so often you have to stop and work around the problem of C 
having only single-level breaks. (Or zero-level breaks if you happen to 
be inside 'switch'.)

(Last time I used a multi-level break: about 15 minutes ago. I wasn't 
writing C. It's just there. What I could also have done with actually 
was 'while-else' that I haven't got. So something to ponder adding.)

[toc] | [prev] | [next] | [standalone]

#143204

Bart <bc@freeuk.com> writes:

> ... If writing C, then every so often you have to stop and work around
> the problem of C having only single-level breaks.

This is a case where what you call a work-around, I call an improvement.

I like to reason about code, and the label helps a lot.  I often ask,
particularly after loops, "what is the state of the program at this
point?" and the presence of a label is a big red flag telling me I have
to take partial execution into account.  It's not a huge advantage,
since multi-level breaks are rare and likely to be flagged by a big
comment, but the label is in just the right place for me to know I have
to think about gotos.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#143207

On 18/04/2019 20:36, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> ... If writing C, then every so often you have to stop and work around
>> the problem of C having only single-level breaks.
> 
> This is a case where what you call a work-around, I call an improvement.
> 
> I like to reason about code, and the label helps a lot.  I often ask,
> particularly after loops, "what is the state of the program at this
> point?" and the presence of a label is a big red flag telling me I have
> to take partial execution into account.  It's not a huge advantage,
> since multi-level breaks are rare and likely to be flagged by a big
> comment, but the label is in just the right place for me to know I have
> to think about gotos.

In my codebase (only compiled code not scripting), about 2.5% of all 
'breaks' are multi-level ones (and break is used very commonly in my 
code to terminate endless loops), and 2% of all 'for' loops are 'for-else'.

It doesn't sound much, but DB mentioned once that only 1.5% of his C 
for-loops were anything other simple iteration via a variable. Yet C 
loops still allow all those other possibilities, things that can make 
code harder to reason about, not easier.

[toc] | [prev] | [next] | [standalone]

#143213

(comp.lang.c++ trimmed)

Bart <bc@freeuk.com> writes:

> On 18/04/2019 20:36, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> ... If writing C, then every so often you have to stop and work around
>>> the problem of C having only single-level breaks.
>>
>> This is a case where what you call a work-around, I call an improvement.
>>
>> I like to reason about code, and the label helps a lot.  I often ask,
>> particularly after loops, "what is the state of the program at this
>> point?" and the presence of a label is a big red flag telling me I have
>> to take partial execution into account.  It's not a huge advantage,
>> since multi-level breaks are rare and likely to be flagged by a big
>> comment, but the label is in just the right place for me to know I have
>> to think about gotos.
>
> In my codebase (only compiled code not scripting), about 2.5% of all
> 'breaks' are multi-level ones (and break is used very commonly in my
> code to terminate endless loops),

That seems like a lot.  We obviously have different coding styles.

> and 2% of all 'for' loops are 'for-else'.
>
> It doesn't sound much, but DB mentioned once that only 1.5% of his C
> for-loops were anything other simple iteration via a variable. Yet C
> loops still allow all those other possibilities, things that can make
> code harder to reason about, not easier.

Is this supposed to be an argument in favour of making matters worse?  I
don't follow the logic.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#143172

On 17/04/2019 13:05, David Brown wrote:
> On 17/04/2019 12:38, Bart wrote:

> 	bool found = false;
> 	int sw;
> 	for (sw = 0; sw < len; sw++) {
> 		if (strcmp(name, options[sw]) == 0) {
> 			found = true;
> 			break;
> 		}
> 	}
> 	if (found) {
> 		do_option(sw, value);

Another point is that as written, 'sw' has to be known outside so cannot 
be local to the loop. (In my example, the code to be executed can be 
brought inside the loop body; sometimes it can't. But 'found' needs to 
be outside.)

[toc] | [prev] | [next] | [standalone]

#143176

On 4/17/2019 10:05 AM, Bart wrote:
>>     bool found = false;
>>     int sw;
>>     for (sw = 0; sw < len; sw++) {
>>         if (strcmp(name, options[sw]) == 0) {
>>             found = true;
>>             break;
>>         }
>>     }
>>     if (found) {
>>         do_option(sw, value);
> 
> Another point is that as written, 'sw' has to be known outside so cannot be 
> local to the loop. (In my example, the code to be executed can be brought 
> inside the loop body; sometimes it can't. But 'found' needs to be outside.)

In CAlive, I have setup flow control blocks for this type of logic.  It
prevents many types of temporary variables, and allows structured flow
movement without using gotos or something else complex:

     bool found = false;
     int sw;

     flow
     {
         for (sw = 0; sw < len; sw++
         {
             if (strcmp(name, options[sw]) == 0)
                 flowto found;
         }

     } found {
         do_option(sw, value);
     }

If you need to return back to where you were after "calling found," you
would use the () syntax.  You can also pass in parameters if they are
defined:

     flowto found();   // Run the code, and return

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#143200

On 2019-04-17, David Brown <david.brown@hesbynett.no> wrote:
> 	bool found = false;
> 	int sw;
> 	for (sw = 0; sw < len; sw++) {
> 		if (strcmp(name, options[sw]) == 0) {
> 			found = true;
> 			break;
> 		}
> 	}
> 	if (found) {
> 		do_option(sw, value);
> 	} else {
> 		printf("Unknown option: %s\r\n", name);
> 		stop(1);
> 	}
>
> The "for else" construct is not necessary, and the bool flag solution
> will be just as efficient.

The flag is not even necessary:

  int sw = 0;

  while (sw != len && strcmp(name, options[sw]) != 0) ++sw;

  if (sw != len)
  {
    do_option(sw, value);
  }
  else
  {
    printf("Unknown option: %s\r\n", name);
    stop(1);
  }

[toc] | [prev] | [next] | [standalone]

#143188

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
<cut>
> Going back even further historically, C's parent language BCPL had a
> construct that one can think of as “arithmetic blocks”, like a curly
> braces compound statement that could return a value.

Yes.  VALOF $( ... RESULTIS exp ... $) to be precise, with later
versions permitting { } in place of $( $).  And of course gcc has
statement expressions as an extension, though you can't "return" from
them at arbitrary points -- the last expression is the value.

> And expressing your example with an imaginary such construct it's not
> significantly more to read, and then properly constrains the scope
> where the code can change or influence the value of the boolean:
>
>     const bool loop_body_executed = BCPL_BLOCK {
>         for (INIT; COND; UPDATE) {
>              if( SOMETHING ) { return true; }
>         }
>         return false;
>     };
>     if( not loop_body_executed ) {
>         // The logical "else" part.
>     }

This is not the example I had, so the bool is not well named as it is
not always set true when the loop body executes.

I can't think of a neat way to avoid using the flag variable, even
using BCPL-style VALOF:

  IF NOT VALOF $(
            LET loop_body_executed = FALSE
            FOR N = 1 TO MAX DO $(
                code; code; loop_body_executed := TRUE
            $)
            RESULTIS loop_body_executed
  $) DO $(
        // original else part
  $)

But there's a bigger problem with both this and the lambda version:
neither abstracts over the loop code.  You write it fresh each time.
And you can't even cut and paste the loop code because 'break's have to
turn into 'return true'.

In Lisp you could write a macro for both meanings where the user simply
has to supply the loop code and the 'else' code.

> As it happens it's easy to define a macro like BCPL_BLOCK:
>
>     #define BCPL_BLOCK   ~[&]()
>
> ... where the `~` operator is defined as e.g.
>
>     namespace lambda_support
>     {
>         using std::declval;
>
>         template< class Func
>             , class Enabled_ = decltype( declval<Func>()() )
>             >
>         inline auto operator~( Func const& f )
>             -> decltype(( f() ))
>         { return f(); }
>     }  // namespace lambda_support

This seems to be getting close to what I'd call lambda abuse.  Is it
worth it to avoid the () that you'd otherwise need?  I realise I may be
missing the point, though.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#143135

On Tuesday, April 16, 2019 at 11:56:19 AM UTC-7, Rick C. Hodgin wrote:
> I'm curious what people's thought are on this idea.  It allows the initial
> test on the for {..} block to enter the block, or fall-through to the else
> clause.  Subsequent tests on the for {..} block that fail simply exit out
> past the last }.
> 
>      for (init; test; incr)
>      {
>          // for code here
> 
>      } else {
>          // else code here
>      }
> 
> It's the equivalent of:
> 
>      init;
>      if (test)
>      {
>          goto skip_first_iteration;
>          for ( ; test; incr)
>          {
> skip_first_iteration:
>              // for code here
>          }
> 
>      } else {
>          // else code here
>      }
> 
> Seems a natural progression.  One I could use quite often due to the
> need to test the conditions outside of the for {..} block today before
> entering it with then-known valid data.  If the test for a valid state
> could be incorporated into the generic iterative test, and the else
> clause added, it would be more natural methinks.
> 

Would Jesus approve of this?

[toc] | [prev] | [next] | [standalone]

#143137

On 16/04/2019 19:57, Rick C. Hodgin wrote:
> I'm curious what people's thought are on this idea.  It allows the initial
> test on the for {..} block to enter the block, or fall-through to the else
> clause.  Subsequent tests on the for {..} block that fail simply exit out
> past the last }.
> 
>      for (init; test; incr)
>      {
>          // for code here
> 
>      } else {
>          // else code here
>      }
> 
> It's the equivalent of:
> 
>      init;
>      if (test)
>      {
>          goto skip_first_iteration;
>          for ( ; test; incr)
>          {
> skip_first_iteration:
>              // for code here
>          }
> 
>      } else {
>          // else code here
>      }
> 
> Seems a natural progression.

Some languages have for-else, but that's not how it's used.

The use-cases in those other languages are more useful, and easier to 
understand, than what you have. There, a for-else loop like this:

    for (A; B; C) {
        D;
        if (X) break;
    } else {E;}

is equivalent to:

    for (A; B; C) {
        D;
        if (X) goto skipelse;
    }
    E;
skipelse:

The else-clause is executed on normal loop terminated. But not when 
terminated by 'break'.

Note that when B starts off as false, then this is equivalent to your 
version: it will just execute E. But when B starts as true, then some 
iterations are executed before E, unlike yours that will do nothing 
special when the loop ends normally after 1+ iterations.

(Note also that 'for(){} else' has some syntactic issues in C, as the 
'else' could taken to belong to the last if-block at the same block 
level. A rule change to make it belong to the last 'if' or 'for' would 
break existing code.)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web