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

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

Winding and unwinding

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

Contents

  Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 11:46 -0800
    Re: Winding and unwinding Anton Shepelev <anton.txt@gmail.com> - 2016-12-12 23:15 +0300
      Re: Winding and unwinding Anton Shepelev <anton.txt@gmail.com> - 2016-12-12 23:21 +0300
      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 13:29 -0800
        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 14:07 -0800
          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-15 08:54 -0800
            Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-15 09:04 -0800
              Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-15 09:15 -0800
    Re: Winding and unwinding supercat@casperkitty.com - 2016-12-12 12:21 -0800
    Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-12 20:48 +0000
      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 13:28 -0800
    Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 13:14 -0800
      Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 14:26 -0800
        Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 16:13 -0800
          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 16:33 -0800
            Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 16:48 -0800
              Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:05 -0800
                Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 17:22 -0800
                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:33 -0800
                    Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 17:55 -0800
                      Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 03:11 -0800
                        Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 03:39 -0800
                          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 03:59 -0800
                            Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 04:57 -0800
                              Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-13 13:24 +0000
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:34 -0800
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:34 -0800
                                Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:01 -0800
                                Re: Winding and unwinding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 15:10 +0000
                              Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:30 -0800
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:45 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:58 -0800
                                  Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:04 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 10:24 -0800
                                    Re: Winding and unwinding Chad <cdalten@gmail.com> - 2016-12-13 21:44 -0800
                                      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:13 -0800
                                    Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-14 11:45 -0800
                                      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:09 -0800
                                        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-14 12:50 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-17 05:28 -0800
                                Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-13 14:54 +0000
                                  Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:03 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 07:09 -0800
                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:27 -0800
        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:13 -0800
    Re: Winding and unwinding Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 16:28 -0800

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

#99179

W dniu wtorek, 13 grudnia 2016 02:55:21 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Monday, December 12, 2016 at 8:33:46 PM UTC-5, fir wrote:
> > i was not talking about this wind-unwind i dont belive in this 2
> > much, one line in your example that was somewhat interesting 2 me
> > was
> > 
> >           flowout;  // Flows out of the flow {..} block 
> > 
> > as this resembles block calling or new keyword for
> > control structures (gives ma a bit to think on such topics)
> >  
> > imo your semantic ideas are not much good imo 
> >  but sometimes you can vrite a piece of invented syntax that can get
> > a bit of attention (i remember once ago you
> > gave a link to some "internal function namespaces"
> > 9functions defined in functions) and there was also some
> > somewhat interesting pieces of syntax there)
> 
> All of my published ideas are here:
> 
>     https://groups.google.com/forum/#!forum/caliveprogramminglanguage
> 
syntax it btw hell to me -> syntax hell

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

#99180

fir wrote:
> Rick C. Hodgin wrote:
> > All of my published ideas are here:
> > https://groups.google.com/forum/#!forum/caliveprogramminglanguage
>
> syntax it btw hell to me -> syntax hell

What does this mean?  CAlive also supports C-like syntax.  None of
these new features have to be used.

Best regards,
Rick C. Hodgin

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

#99181

W dniu wtorek, 13 grudnia 2016 12:39:50 UTC+1 użytkownik Rick C. Hodgin napisał:
> fir wrote:
> > Rick C. Hodgin wrote:
> > > All of my published ideas are here:
> > > https://groups.google.com/forum/#!forum/caliveprogramminglanguage
> >
> > syntax it btw hell to me -> syntax hell
> 
> What does this mean?  CAlive also supports C-like syntax.  None of
> these new features have to be used.
> 
its not about calive in general syntax (when i think on c) is hell to me (semantic questions are easier as they can be
like more separated, syntax is hellish)

your calive is (roughly) like on c++/c# level of ideas and 
it is not much good imo but some syntaxic pieces may get
me to think (i seen like 10 of those posts and this time "?" as a postfix operator like drawed my attention  - you use it not much good imo but there is something interesting 
releted to postfix "?" imo -  dont know what though, and syntax is to hellish to resolve it - my attempts to 
decide on something in improved c syntax mostly fail

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

#99184

i can yet say i clicked (somewhat fast) all those
posts in that calive group and found nothing i could 
find worth or good idea to use.. (it is all bad for short)

few things can be take as topics for some discussion
like you wnted to allow 1,000,000 for 1000000 -
this i must agree - many would agree and noted i think 
that to use numbers such or at least "1 000 000 " way
is something c lacks - but how to incorporate it in the 
syntax is some trouble/open question

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

#99188

On 13/12/2016 12:57, fir wrote:

> few things can be take as topics for some discussion
> like you wnted to allow 1,000,000 for 1000000 -
> this i must agree - many would agree and noted i think
> that to use numbers such or at least "1 000 000 " way
> is something c lacks - but how to incorporate it in the
> syntax is some trouble/open question

Yes, writing:

    f(1,000,000);

is a little ambiguous. Is that one parameter (1000000) or three (1,0,0)?

Even if it is known that f takes two parameters, then here:

    f(100,200,300,400);

Are they:

     100 and 200,300,400
or: 100,200 and 300,400
or: 100,200,300 and 400?

What about just:

     (100,200,300);

is this the number 100,200,300, or comma operators that evaluate 100, 
200 and return 300?

-- 
Bartc

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

#99194

W dniu wtorek, 13 grudnia 2016 14:24:47 UTC+1 użytkownik Bart napisał:
> On 13/12/2016 12:57, fir wrote:
> 
> > few things can be take as topics for some discussion
> > like you wnted to allow 1,000,000 for 1000000 -
> > this i must agree - many would agree and noted i think
> > that to use numbers such or at least "1 000 000 " way
> > is something c lacks - but how to incorporate it in the
> > syntax is some trouble/open question
> 
> Yes, writing:
> 
>     f(1,000,000);
> 
> is a little ambiguous. Is that one parameter (1000000) or three (1,0,0)?
> 
> Even if it is known that f takes two parameters, then here:
> 
>     f(100,200,300,400);
> 
> Are they:
> 
>      100 and 200,300,400
> or: 100,200 and 300,400
> or: 100,200,300 and 400?
> 
> What about just:
> 
>      (100,200,300);
> 
> is this the number 100,200,300, or comma operators that evaluate 100, 
> 200 and return 300?
> 
> -- 
> Bartc

spaces like if(1 000 000) could be easier to fit but even that probably makes some conteptual problems imo (yet looks worse at least to people who like to read formated numbers like 1,000,000 )

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

#99195

W dniu wtorek, 13 grudnia 2016 14:24:47 UTC+1 użytkownik Bart napisał:
> On 13/12/2016 12:57, fir wrote:
> 
> > few things can be take as topics for some discussion
> > like you wnted to allow 1,000,000 for 1000000 -
> > this i must agree - many would agree and noted i think
> > that to use numbers such or at least "1 000 000 " way
> > is something c lacks - but how to incorporate it in the
> > syntax is some trouble/open question
> 
> Yes, writing:
> 
>     f(1,000,000);
> 
> is a little ambiguous. Is that one parameter (1000000) or three (1,0,0)?
> 
> Even if it is known that f takes two parameters, then here:
> 
>     f(100,200,300,400);
> 
> Are they:
> 
>      100 and 200,300,400
> or: 100,200 and 300,400
> or: 100,200,300 and 400?
> 
> What about just:
> 
>      (100,200,300);
> 
> is this the number 100,200,300, or comma operators that evaluate 100, 
> 200 and return 300?
> 
> -- 
> Bartc

spaces like if(1 000 000) could be easier to fit but even that probably makes some conteptual problems imo (yet looks worse at least to people who like to read formated numbers like 1,000,000 )

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

#99202

On Tuesday, December 13, 2016 at 8:24:47 AM UTC-5, Bart wrote:
> On 13/12/2016 12:57, fir wrote:
> 
> > few things can be take as topics for some discussion
> > like you wnted to allow 1,000,000 for 1000000 -
> > this i must agree - many would agree and noted i think
> > that to use numbers such or at least "1 000 000 " way
> > is something c lacks - but how to incorporate it in the
> > syntax is some trouble/open question
> 
> Yes, writing:
> 
>     f(1,000,000);
> 
> is a little ambiguous. Is that one parameter (1000000) or three (1,0,0)?
> 
> Even if it is known that f takes two parameters, then here:
> 
>     f(100,200,300,400);
> 
> Are they:
> 
>      100 and 200,300,400
> or: 100,200 and 300,400
> or: 100,200,300 and 400?
> 
> What about just:
> 
>      (100,200,300);
> 
> is this the number 100,200,300, or comma operators that evaluate 100, 
> 200 and return 300?

There are two aspects of this:

    1)  I also support tick marks (as in f(1'000'000))
    2)  With commas it would have to be together, and not with a
        whitespace.  That would indicate they are visual delineators
        on the numeric type and not parameter markers.

These features will be enabled on .ca files by default, and must be
explicitly enabled by command line option on .c or .cpp files.

Best regards,
Rick C. Hodgin

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

#99210

BartC <bc@freeuk.com> writes:

> On 13/12/2016 12:57, fir wrote:
>
>> few things can be take as topics for some discussion
>> like you wnted to allow 1,000,000 for 1000000 -
>> this i must agree - many would agree and noted i think
>> that to use numbers such or at least "1 000 000 " way
>> is something c lacks - but how to incorporate it in the
>> syntax is some trouble/open question
>
> Yes, writing:
>
>    f(1,000,000);
>
> is a little ambiguous. Is that one parameter (1000000) or three
> (1,0,0)?

In the unlikely event of ',' being added as a digit separator in C, this
should be one argument.  There is a natural interpretation based on the
"maximum munch" used by the lexer -- take the longest sequence of
character that makes a valid token.

<snip>
-- 
Ben.

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

#99191

On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> i can yet say i clicked (somewhat fast) all those
> posts in that calive group and found nothing i could 
> find worth or good idea to use.. (it is all bad for short)

Thank you for your input, fir.

> few things can be take as topics for some discussion
> like you wnted to allow 1,000,000 for 1000000 -
> this i must agree - many would agree and noted i think 
> that to use numbers such or at least "1 000 000 " way
> is something c lacks - but how to incorporate it in the 
> syntax is some trouble/open question

CAlive will allow 100,000,000.000'000'000 with commas and ticks.
In addition, leading periods can be used in hexadecimal values
to vertically align things, as in:

    0x00004000   --> can be 0x....4000
    0x00300000   --> can be 0x..300000

In that way, just the relevant portions of the hex number grab the
focus / attention.

Best regards,
Rick C. Hodgin

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

#99196

W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > i can yet say i clicked (somewhat fast) all those
> > posts in that calive group and found nothing i could 
> > find worth or good idea to use.. (it is all bad for short)
> 
> Thank you for your input, fir.
> 
> > few things can be take as topics for some discussion
> > like you wnted to allow 1,000,000 for 1000000 -
> > this i must agree - many would agree and noted i think 
> > that to use numbers such or at least "1 000 000 " way
> > is something c lacks - but how to incorporate it in the 
> > syntax is some trouble/open question
> 
> CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> In addition, leading periods can be used in hexadecimal values
> to vertically align things, as in:
> 
>     0x00004000   --> can be 0x....4000
>     0x00300000   --> can be 0x..300000
> 
> In that way, just the relevant portions of the hex number grab the
> focus / attention.
> 
in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 

so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better
 

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

#99200

W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > i can yet say i clicked (somewhat fast) all those
> > > posts in that calive group and found nothing i could 
> > > find worth or good idea to use.. (it is all bad for short)
> > 
> > Thank you for your input, fir.
> > 
> > > few things can be take as topics for some discussion
> > > like you wnted to allow 1,000,000 for 1000000 -
> > > this i must agree - many would agree and noted i think 
> > > that to use numbers such or at least "1 000 000 " way
> > > is something c lacks - but how to incorporate it in the 
> > > syntax is some trouble/open question
> > 
> > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > In addition, leading periods can be used in hexadecimal values
> > to vertically align things, as in:
> > 
> >     0x00004000   --> can be 0x....4000
> >     0x00300000   --> can be 0x..300000
> > 
> > In that way, just the relevant portions of the hex number grab the
> > focus / attention.
> > 
> in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> 
> so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better

c lacks some operator btw to work (like compare) and other integers with chars and so on (for example to check if third char in some integer x is char c one would need
maybe shifts and masks and it is unconvenient, some
should be done like   casting  

 ( (char[4]) x )[2] == c  //cast int to char[4] compare char[2] with char y

or something buildin making work on bytes more handy,
right now this rgb pasking and unpacking is weak 

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

#99203

On Tuesday, December 13, 2016 at 8:45:37 AM UTC-5, fir wrote:
> W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > i can yet say i clicked (somewhat fast) all those
> > > posts in that calive group and found nothing i could 
> > > find worth or good idea to use.. (it is all bad for short)
> > 
> > Thank you for your input, fir.
> > 
> > > few things can be take as topics for some discussion
> > > like you wnted to allow 1,000,000 for 1000000 -
> > > this i must agree - many would agree and noted i think 
> > > that to use numbers such or at least "1 000 000 " way
> > > is something c lacks - but how to incorporate it in the 
> > > syntax is some trouble/open question
> > 
> > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > In addition, leading periods can be used in hexadecimal values
> > to vertically align things, as in:
> > 
> >     0x00004000   --> can be 0x....4000
> >     0x00300000   --> can be 0x..300000
> > 
> > In that way, just the relevant portions of the hex number grab the
> > focus / attention.
> > 
> in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 

There is no collision as you indicate.  A potential collision exists as
Bart indicated, which is that if a person does not uses spaces to
separate parameters it could be interpreted as a single value.  But,
that's easily identified because the parameter count will be off.

> so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better

I appreciate your opinion.  You should write your language to operate as
you feel is best.

Best regards,
Rick C. Hodgin

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

#99222

W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > i can yet say i clicked (somewhat fast) all those
> > > posts in that calive group and found nothing i could 
> > > find worth or good idea to use.. (it is all bad for short)
> > 
> > Thank you for your input, fir.
> > 
> > > few things can be take as topics for some discussion
> > > like you wnted to allow 1,000,000 for 1000000 -
> > > this i must agree - many would agree and noted i think 
> > > that to use numbers such or at least "1 000 000 " way
> > > is something c lacks - but how to incorporate it in the 
> > > syntax is some trouble/open question
> > 
> > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > In addition, leading periods can be used in hexadecimal values
> > to vertically align things, as in:
> > 
> >     0x00004000   --> can be 0x....4000
> >     0x00300000   --> can be 0x..300000
> > 
> > In that way, just the relevant portions of the hex number grab the
> > focus / attention.
> > 
> in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> 
> so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better

there seems to be btw strong confusion how to store such things like "abc" in numbers

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

#99312

Wait, is CAlive now an actual thing? Or is it still vaporware?

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

#99321

Chad wrote:
> Wait, is CAlive now an actual thing? Or is it still vaporware?

There is no binary you can download.  It's still under development.

Best regards,
Rick C. Hodgin

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

#99384

W dniu wtorek, 13 grudnia 2016 19:24:56 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> > W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > > i can yet say i clicked (somewhat fast) all those
> > > > posts in that calive group and found nothing i could 
> > > > find worth or good idea to use.. (it is all bad for short)
> > > 
> > > Thank you for your input, fir.
> > > 
> > > > few things can be take as topics for some discussion
> > > > like you wnted to allow 1,000,000 for 1000000 -
> > > > this i must agree - many would agree and noted i think 
> > > > that to use numbers such or at least "1 000 000 " way
> > > > is something c lacks - but how to incorporate it in the 
> > > > syntax is some trouble/open question
> > > 
> > > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > > In addition, leading periods can be used in hexadecimal values
> > > to vertically align things, as in:
> > > 
> > >     0x00004000   --> can be 0x....4000
> > >     0x00300000   --> can be 0x..300000
> > > 
> > > In that way, just the relevant portions of the hex number grab the
> > > focus / attention.
> > > 
> > in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> > 
> > so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better
> 
> there seems to be btw strong confusion how to store such things like "abc" in numbers

it seemt to me that there is confusion in such things,

imagine

 int x = (int) "abc" ;

//how the x value should be? (we cast "abc" treated as value not any kind of adresses involved)

i began to think on this and after 1 or 2 hour long 
thinking it appeared to me that it should be MAYBE 0x00636261  but im still not sure

anyway c afaik has no such cast and it could be probably handy imo

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

#99396

On Wednesday, December 14, 2016 at 2:46:02 PM UTC-5, fir wrote:
> W dniu wtorek, 13 grudnia 2016 19:24:56 UTC+1 użytkownik fir napisał:
> > W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> > > W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > > > i can yet say i clicked (somewhat fast) all those
> > > > > posts in that calive group and found nothing i could 
> > > > > find worth or good idea to use.. (it is all bad for short)
> > > > 
> > > > Thank you for your input, fir.
> > > > 
> > > > > few things can be take as topics for some discussion
> > > > > like you wnted to allow 1,000,000 for 1000000 -
> > > > > this i must agree - many would agree and noted i think 
> > > > > that to use numbers such or at least "1 000 000 " way
> > > > > is something c lacks - but how to incorporate it in the 
> > > > > syntax is some trouble/open question
> > > > 
> > > > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > > > In addition, leading periods can be used in hexadecimal values
> > > > to vertically align things, as in:
> > > > 
> > > >     0x00004000   --> can be 0x....4000
> > > >     0x00300000   --> can be 0x..300000
> > > > 
> > > > In that way, just the relevant portions of the hex number grab the
> > > > focus / attention.
> > > > 
> > > in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> > > 
> > > so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better
> > 
> > there seems to be btw strong confusion how to store such things like "abc" in numbers
> 
> it seemt to me that there is confusion in such things,
> 
> imagine
> 
>  int x = (int) "abc" ;
> 
> //how the x value should be? (we cast "abc" treated as value not any kind of adresses involved)
> 
> i began to think on this and after 1 or 2 hour long 
> thinking it appeared to me that it should be MAYBE 0x00636261  but im still not sure
> 
> anyway c afaik has no such cast and it could be probably handy imo

It's very simple, fir.  Microsoft's Macro Assembler used to interpret
that very string as basically a base-256 integer.  Every byte occupied
8 bits in the value it created.  The hexadecimal values for a, b, c,
are placed in bits 0..7, 8..15, 9..23, and the value is created in
that way, though it must also account for endian.

Best regards,
Rick C. Hodgin

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

#99411

W dniu środa, 14 grudnia 2016 21:09:17 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Wednesday, December 14, 2016 at 2:46:02 PM UTC-5, fir wrote:
> > W dniu wtorek, 13 grudnia 2016 19:24:56 UTC+1 użytkownik fir napisał:
> > > W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> > > > W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > > > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > > > > i can yet say i clicked (somewhat fast) all those
> > > > > > posts in that calive group and found nothing i could 
> > > > > > find worth or good idea to use.. (it is all bad for short)
> > > > > 
> > > > > Thank you for your input, fir.
> > > > > 
> > > > > > few things can be take as topics for some discussion
> > > > > > like you wnted to allow 1,000,000 for 1000000 -
> > > > > > this i must agree - many would agree and noted i think 
> > > > > > that to use numbers such or at least "1 000 000 " way
> > > > > > is something c lacks - but how to incorporate it in the 
> > > > > > syntax is some trouble/open question
> > > > > 
> > > > > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > > > > In addition, leading periods can be used in hexadecimal values
> > > > > to vertically align things, as in:
> > > > > 
> > > > >     0x00004000   --> can be 0x....4000
> > > > >     0x00300000   --> can be 0x..300000
> > > > > 
> > > > > In that way, just the relevant portions of the hex number grab the
> > > > > focus / attention.
> > > > > 
> > > > in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> > > > 
> > > > so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better
> > > 
> > > there seems to be btw strong confusion how to store such things like "abc" in numbers
> > 
> > it seemt to me that there is confusion in such things,
> > 
> > imagine
> > 
> >  int x = (int) "abc" ;
> > 
> > //how the x value should be? (we cast "abc" treated as value not any kind of adresses involved)
> > 
> > i began to think on this and after 1 or 2 hour long 
> > thinking it appeared to me that it should be MAYBE 0x00636261  but im still not sure
> > 
> > anyway c afaik has no such cast and it could be probably handy imo
> 
> It's very simple, fir.  Microsoft's Macro Assembler used to interpret
> that very string as basically a base-256 integer.  Every byte occupied
> 8 bits in the value it created.  The hexadecimal values for a, b, c,
> are placed in bits 0..7, 8..15, 9..23, and the value is created in
> that way, though it must also account for endian.
> 
not so simple, it would be for example nice if those conversion would fit to some rules, for example when sorting strings one usualy compare by left string chatacters and this way not totally conforms to that 
maybe, also when adding characters when typing it would be nice not to add some value not touching the number 
- and so on... this convention not quite conforms to 
that 

anyway it would be fine to get such conversion/casting in
both ways really not only char[] to int but also int to char[] by simple casting - it should be full 256-asci
based but some variants for hex and decimals could be also
defined 

int x = (decimal) "1234";
int x = (hexadecimal) "123f"; 

char x[8] = (decimal) 1234 ;
char x[8] = (hexadecimal) 1024; 

(maybe not this names as seem not fit but something like that only improved)

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

#99734

W dniu wtorek, 13 grudnia 2016 14:45:37 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 14:30:09 UTC+1 użytkownik Rick C. Hodgin napisał:
> > On Tuesday, December 13, 2016 at 7:57:36 AM UTC-5, fir wrote:
> > > i can yet say i clicked (somewhat fast) all those
> > > posts in that calive group and found nothing i could 
> > > find worth or good idea to use.. (it is all bad for short)
> > 
> > Thank you for your input, fir.
> > 
> > > few things can be take as topics for some discussion
> > > like you wnted to allow 1,000,000 for 1000000 -
> > > this i must agree - many would agree and noted i think 
> > > that to use numbers such or at least "1 000 000 " way
> > > is something c lacks - but how to incorporate it in the 
> > > syntax is some trouble/open question
> > 
> > CAlive will allow 100,000,000.000'000'000 with commas and ticks.
> > In addition, leading periods can be used in hexadecimal values
> > to vertically align things, as in:
> > 
> >     0x00004000   --> can be 0x....4000
> >     0x00300000   --> can be 0x..300000
> > 
> > In that way, just the relevant portions of the hex number grab the
> > focus / attention.
> > 
> in c '000' means ascii chars (or at least '0' means char, not sure what '00' mean, afaik it mean 2-chars in a way it is 16 bit value filled with two chars (0x3030) like '0000' is 32 bit value of 0x30303030 - but im not sure if it is in standard esp in more holy old ones) 
> 
> so yu got a collision - btw this c usage of '' is damn syntax wastefull, they just should use "0" for chars but probably the ending zero convention for literals stopped them , still it is wastefull and i would like to repair those conventions and reserve ' for something better

if could be use for example for ad hoc enums (like i was said on this many time ago), 

foo('fast');

void foo(enum ex)
{
  if(ex=='slow') {}
  if(ex=='fast') {}
}

[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