Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-28 03:07 -0800 |
| Message-ID | <2e781ee8-e952-43d6-a386-068681b15f5c@googlegroups.com> |
| In reply to | #100401 |
David Brown wrote: > I think it would be far too easy to be inconsistent if you > allow commas as digit separators - it sounds dangerous to me. I like to live on the edge. :-) Actually, I am trying to make CAlive operate from people needs, and not machine needs. The comma issue is easily overcome by using whitespaces, and from within the GUI IDE, compilation feedback will be nearly instantaneous. And for some people, "int x = 12,345;" is easier to read than, "int x = 12_345;" or "int x = 12'345;" ... so I give them a choice. I like Ben Bacarisse's stated intent in C's preprocessor, the "biggest bite" philosophy. We'll continue that in CAlive. > Your choice, of course, and you may decide that with a gui you > can make everything clear enough. With the real-time feedback, it should be good. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 12:25 +0100 |
| Message-ID | <o407c0$d4l$1@dont-email.me> |
| In reply to | #100406 |
On 28/12/16 12:07, Rick C. Hodgin wrote: > David Brown wrote: >> I think it would be far too easy to be inconsistent if you >> allow commas as digit separators - it sounds dangerous to me. > > I like to live on the edge. :-) > > Actually, I am trying to make CAlive operate from people needs, > and not machine needs. The comma issue is easily overcome by > using whitespaces, and from within the GUI IDE, compilation feedback > will be nearly instantaneous. And for some people, "int x = 12,345;" > is easier to read than, "int x = 12_345;" or "int x = 12'345;" ... so I give > them a choice. You do realise that for a great many people around the world, decimals are shown by a comma rather than a point? So "int x = 12,345;" would cause them the same confusion that "int x = 12.345;" would cause you. Those who use a comma for decimal would usually use a point for digit grouping in normal writing. Remember, choice is not always a good thing - people may like a choice in what they write, but that also means they face multiple variants when reading other people's code. The ISO standard, to avoid such confusion, is a thin space for digit grouping. You can't make a thin space with a fixed width font and/or plain ASCII, and a space can be an awkward choice in literals anyway. An underscore is probably the best option here, with C++'s tick as a reasonable second (Switzerland traditionally uses a tick mark for grouping digits already). > > I like Ben Bacarisse's stated intent in C's preprocessor, the "biggest > bite" philosophy. We'll continue that in CAlive. > >> Your choice, of course, and you may decide that with a gui you >> can make everything clear enough. > > With the real-time feedback, it should be good. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 11:58 +0000 |
| Message-ID | <87zijggt9r.fsf@bsb.me.uk> |
| In reply to | #100406 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > I like Ben Bacarisse's stated intent in C's preprocessor, the "biggest > bite" philosophy. I don't think I've ever said that. I hope not as it sounds slightly confusing because of the identical pronunciation of "byte". I would not normally bother to mention it but you've brought it up twice now as if it's something to do with me... > We'll continue that in CAlive. ... and, worse, immediately following it with "we'll continue that" suggests that I might be involved in some way with your project. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-28 04:35 -0800 |
| Message-ID | <532ca765-1a94-4f8b-805a-5072e03f8860@googlegroups.com> |
| In reply to | #100412 |
Ben Bacarisse wrote:
> Rick C. Hodgin"
> > "biggest bite" ...
>
> I don't think I've ever said that.
You're right. It was, "maximum munch." My mistake.
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.
> > We'll continue that in CAlive.
>
> ... and, worse, immediately following it with "we'll continue that"
> suggests that I might be involved in some way with your project.
We (the people who will work on CAlive). You would be welcomed, but
so far it seems you are in all ways unwilling.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 17:31 +0000 |
| Message-ID | <874m1ogdu2.fsf@bsb.me.uk> |
| In reply to | #100421 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > Ben Bacarisse wrote: >> Rick C. Hodgin" >> > "biggest bite" ... >> >> I don't think I've ever said that. > > You're right. It was, "maximum munch." My mistake. Yes, thanks. But note that the phrase is not mine. I can't say whose it is, but it is in common use, presumably due to the pleasing alliteration. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-28 09:38 -0800 |
| Message-ID | <832bc695-b47a-41ba-bf8d-bcbf7bbb6e4d@googlegroups.com> |
| In reply to | #100443 |
On Wednesday, December 28, 2016 at 12:31:40 PM UTC-5, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > Ben Bacarisse wrote: > >> Rick C. Hodgin write: > >> > "biggest bite" ... > >> I don't think I've ever said that. > > You're right. It was, "maximum munch." My mistake. > > Yes, thanks. But note that the phrase is not mine. I can't say whose > it is, but it is in common use, presumably due to the pleasing > alliteration. You are my first source for ever hearing that phrase. I apologize for giving you improper attribution. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-28 15:12 -0600 |
| Message-ID | <1ga86cl63tkqbcli2n8kte833s7pqp8965@4ax.com> |
| In reply to | #100443 |
On Wed, 28 Dec 2016 17:31:33 +0000, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> Ben Bacarisse wrote: >>> Rick C. Hodgin" >>> > "biggest bite" ... >>> >>> I don't think I've ever said that. >> >> You're right. It was, "maximum munch." My mistake. > >Yes, thanks. But note that the phrase is not mine. I can't say whose >it is, but it is in common use, presumably due to the pleasing >alliteration. https://en.wikipedia.org/wiki/Maximal_munch "Maximal munch" being the traditional form, although I've probably heard "maximum" more often. Any that dates it back to at least R.G.G. Cattell and 1978.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 12:01 -0800 |
| Message-ID | <ln37h74ybt.fsf@kst-u.example.com> |
| In reply to | #100443 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
[...]
>> You're right. It was, "maximum munch." My mistake.
>
> Yes, thanks. But note that the phrase is not mine. I can't say whose
> it is, but it is in common use, presumably due to the pleasing
> alliteration.
<quibble>The usual phrase is "maximal munch".</quibble>
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 09:20 -0800 |
| Message-ID | <lnd1gc55tb.fsf@kst-u.example.com> |
| In reply to | #100401 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> In other languages, underscores are popular as digit separators and work
> well. C++ could not do that, because underscores count as letters and
> thus for example "_123" is a valid identifier. C++11 added user-defined
> suffixes for literals, so "123_456" parses as "123" followed by the
> user-defined literal "_456", and therefore a call to _456(123).
C++ (prior to C++11) certainly could have used underscores as digit
separators, as long as an underscore is not allowed at the beginning.
_123456 is unambiguously an identifier; 123_456 could have been an
integer literal. It's a pity IMHO that C++11 used underscore for
user-defined literals; there was already a lot of precedent for using it
as a separator (Perl, Ada, etc.).
In any case, it's too late now and mostly off-topic (except that if C
were to add digit separators, it would probably be best to be compatible
with C++).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 13:39 -0800 |
| Message-ID | <ln4m1n3f9h.fsf@kst-u.example.com> |
| In reply to | #100439 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/12/16 18:20, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> In other languages, underscores are popular as digit separators and work
>>> well. C++ could not do that, because underscores count as letters and
>>> thus for example "_123" is a valid identifier. C++11 added user-defined
>>> suffixes for literals, so "123_456" parses as "123" followed by the
>>> user-defined literal "_456", and therefore a call to _456(123).
>>
>> C++ (prior to C++11) certainly could have used underscores as digit
>> separators, as long as an underscore is not allowed at the beginning.
>> _123456 is unambiguously an identifier; 123_456 could have been an
>> integer literal. It's a pity IMHO that C++11 used underscore for
>> user-defined literals; there was already a lot of precedent for using it
>> as a separator (Perl, Ada, etc.).
>>
>
> Underscore was already effectively a letter (and thus could start an
> identifier) - when adding user-defined literal suffixes, the standards
> would have had to make a special exception to say that the suffix could
> be any identifier except one starting with an underscore. I suppose
> they could just have said that you need a space between the digits and
> the user-defined literal suffix.
My point is that they could have used some other syntax for user-defined
literals, one that would not conflict with using underscores as digit
separators.
I don't know enough about the feature to suggest an alternative syntax,
and there's not much point anyway.
>> In any case, it's too late now and mostly off-topic (except that if C
>> were to add digit separators, it would probably be best to be compatible
>> with C++).
>
> Well, yes. As a user of both languages, I am always happiest when new
> features are consistent (assuming the feature makes sense in both
> languages - and I think digit separators would be as useful in C as they
> are in C++).
>
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-29 12:29 +0100 |
| Message-ID | <o42s03$85s$2@dont-email.me> |
| In reply to | #100485 |
On 28/12/16 22:39, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 28/12/16 18:20, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> In other languages, underscores are popular as digit separators and work >>>> well. C++ could not do that, because underscores count as letters and >>>> thus for example "_123" is a valid identifier. C++11 added user-defined >>>> suffixes for literals, so "123_456" parses as "123" followed by the >>>> user-defined literal "_456", and therefore a call to _456(123). >>> >>> C++ (prior to C++11) certainly could have used underscores as digit >>> separators, as long as an underscore is not allowed at the beginning. >>> _123456 is unambiguously an identifier; 123_456 could have been an >>> integer literal. It's a pity IMHO that C++11 used underscore for >>> user-defined literals; there was already a lot of precedent for using it >>> as a separator (Perl, Ada, etc.). >>> >> >> Underscore was already effectively a letter (and thus could start an >> identifier) - when adding user-defined literal suffixes, the standards >> would have had to make a special exception to say that the suffix could >> be any identifier except one starting with an underscore. I suppose >> they could just have said that you need a space between the digits and >> the user-defined literal suffix. > > My point is that they could have used some other syntax for user-defined > literals, one that would not conflict with using underscores as digit > separators. > > I don't know enough about the feature to suggest an alternative syntax, > and there's not much point anyway. > Fair enough. Language design would be so much easier if we could peek into the future to see the long-term effects of the decisions!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 22:20 +0100 |
| Message-ID | <o41a88$404$1@dont-email.me> |
| In reply to | #100439 |
On 28/12/16 18:20, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> In other languages, underscores are popular as digit separators and work >> well. C++ could not do that, because underscores count as letters and >> thus for example "_123" is a valid identifier. C++11 added user-defined >> suffixes for literals, so "123_456" parses as "123" followed by the >> user-defined literal "_456", and therefore a call to _456(123). > > C++ (prior to C++11) certainly could have used underscores as digit > separators, as long as an underscore is not allowed at the beginning. > _123456 is unambiguously an identifier; 123_456 could have been an > integer literal. It's a pity IMHO that C++11 used underscore for > user-defined literals; there was already a lot of precedent for using it > as a separator (Perl, Ada, etc.). > Underscore was already effectively a letter (and thus could start an identifier) - when adding user-defined literal suffixes, the standards would have had to make a special exception to say that the suffix could be any identifier except one starting with an underscore. I suppose they could just have said that you need a space between the digits and the user-defined literal suffix. > In any case, it's too late now and mostly off-topic (except that if C > were to add digit separators, it would probably be best to be compatible > with C++). > Well, yes. As a user of both languages, I am always happiest when new features are consistent (assuming the feature makes sense in both languages - and I think digit separators would be as useful in C as they are in C++).
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-28 13:02 +0100 |
| Message-ID | <o409hb$j2a$2@dont-email.me> |
| In reply to | #100322 |
On 27/12/2016 15:58, BartC wrote: > C commonly uses 0b and 0B; why not just got with that? "commonly"? As in, "this is a common non-standard extension"?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 13:30 +0100 |
| Message-ID | <o40b76$omb$1@dont-email.me> |
| In reply to | #100415 |
On 28/12/16 13:02, Noob wrote: > On 27/12/2016 15:58, BartC wrote: > >> C commonly uses 0b and 0B; why not just got with that? > > "commonly"? > > As in, "this is a common non-standard extension"? > I can't answer for Bart, but yes - it is a common non-standard extension in C (and it is in the C++ standards, if you place any relevance in that).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 13:25 +0000 |
| Message-ID | <o40ed7$35o$1@dont-email.me> |
| In reply to | #100415 |
On 28/12/2016 12:02, Noob wrote: > On 27/12/2016 15:58, BartC wrote: > >> C commonly uses 0b and 0B; why not just go with that? > > "commonly"? > > As in, "this is a common non-standard extension"? > I guess so. They seem to be supported by Digital Mars' C, lccwin, gcc, Tiny C and probably clang (as that usually follows gcc). They're not supported by Pelles C or MSVC-2008. So most of the compilers I have on hand use 0B-prefix binary constants. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-27 15:19 +0100 |
| Message-ID | <o3tt94$b1h$1@gioia.aioe.org> |
| In reply to | #100318 |
On 12/27/2016 3:08 PM, BartC wrote:
> I'm doing some work on C tokenising and this amusing quirk came up.
>
> Octal literals are already an anachronism but here:
>
> printf("%d\n", 0123 );
> printf("%f\n", 0123.);
>
> a leading zero to signify an octal number apparently doesn't stretch as
> far as floating point. The output is:
>
> 83
> 123.000000
>
> It's likely to bite in scenarios like this:
>
> double A[]={123, 123., 0123, 0123.};
>
> Spot the odd one out.
>
Yet another reason for using dot-notation for floating point literals:
123.0
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 08:37 -0800 |
| Message-ID | <lnful98h1i.fsf@kst-u.example.com> |
| In reply to | #100320 |
Manfred <noname@invalid.add> writes:
> On 12/27/2016 3:08 PM, BartC wrote:
>> I'm doing some work on C tokenising and this amusing quirk came up.
>>
>> Octal literals are already an anachronism but here:
>>
>> printf("%d\n", 0123 );
>> printf("%f\n", 0123.);
>>
>> a leading zero to signify an octal number apparently doesn't stretch as
>> far as floating point. The output is:
>>
>> 83
>> 123.000000
>>
>> It's likely to bite in scenarios like this:
>>
>> double A[]={123, 123., 0123, 0123.};
>>
>> Spot the odd one out.
>>
> Yet another reason for using dot-notation for floating point literals:
> 123.0
I think what you mean is that one should use floating-point constants
(rather than integer constants like 123 or 0123) for floating-point
values -- and I agree.. Integer constants are legal, and depending
on the context will be converted to the appropriate floating-point
type, but floating-point constants are clearer. (And I don't use
FP constants with a leading or trailing '.'.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-27 18:43 +0100 |
| Message-ID | <o3u97h$11g5$1@gioia.aioe.org> |
| In reply to | #100331 |
On 12/27/2016 5:37 PM, Keith Thompson wrote: >> Yet another reason for using dot-notation for floating point literals: >> 123.0 > I think what you mean is that one should use floating-point constants Indeed. I used the term 'literal' here, but I see now that the term (actually "floating literal") is used in the C++ standard, while the C standard only refers to "Floating constants" and uses literals for strings only (language lawyering)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 12:07 -0800 |
| Message-ID | <lnr34t6sqb.fsf@kst-u.example.com> |
| In reply to | #100338 |
Manfred <noname@invalid.add> writes:
> On 12/27/2016 5:37 PM, Keith Thompson wrote:
>>> Yet another reason for using dot-notation for floating point literals:
>>> 123.0
>> I think what you mean is that one should use floating-point constants
> Indeed. I used the term 'literal' here, but I see now that the term
> (actually "floating literal") is used in the C++ standard, while the C
> standard only refers to "Floating constants" and uses literals for
> strings only (language lawyering)
Sure, but the "constants" vs. "literals" distinction wasn't my point.
The term "literal" is clear enough that it doesn't bother me;
no real ambiguity is likely.
My point (which is in agreement with yours) is that, as a matter of
style, it's better IMHO to use floating-point constants/literals,
not integer constants/literals, in a context where an integer would
be implicitly converted to floating-point. (Typically this just
means appending ".0".)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-27 18:21 +0100 |
| Message-ID | <o3u7vk$uuo$1@gioia.aioe.org> |
| In reply to | #100320 |
On 12/27/2016 4:47 PM, Stefan Ram wrote: >> Yet another reason for using dot-notation for floating point literals: >> 123.0 > This really is something the participants of my C courses > learn in the first meeting (each meeting has 3 hours). In fact I remember this being taught, during my student age, in one of my first programming classes (back in the early '90s) - although at that time it was about Fortran.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web