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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-28 19:52 +0000 |
| Message-ID | <58641791.15528406@news.xs4all.nl> |
| In reply to | #100525 |
BartC <bc@freeuk.com> wrote: > On 28/12/2016 18:19, Keith Thompson wrote: > > BartC <bc@freeuk.com> writes: > > >> But there is no way my pp would generate "+++" and then "++","+" from > >> that example, no matter what the Standard says! Nor "0x123E+3" as a > >> single token.) > > > > So you're going to implement a C preprocessor, but you're not interested > > in what the Standard says. Interesting choice. > > Suppose you had a choice of two compilers. They work identically except > that one reports the 0x123e+1 as an error and other doesn't. > > The one that doesn't, that doesn't quite follow the Standard 100%, is > ten times faster than the other. Suppose I had car, and a teleportation device that made my ears itch, wouldn't I prefer the teleporter to the car and disregard the itch? Suppose I had a trillion dollars, wouldn't I prefer that to the current situation? Suppose you stopped making up idiotic scenarios? Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 09:36 -0800 |
| Message-ID | <lneg0q1vud.fsf@kst-u.example.com> |
| In reply to | #100542 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 19:52, Richard Bos wrote:
>> BartC <bc@freeuk.com> wrote:
>>> On 28/12/2016 18:19, Keith Thompson wrote:
>>>> So you're going to implement a C preprocessor, but you're not interested
>>>> in what the Standard says. Interesting choice.
>>>
>>> Suppose you had a choice of two compilers. They work identically except
>>> that one reports the 0x123e+1 as an error and other doesn't.
>>>
>>> The one that doesn't, that doesn't quite follow the Standard 100%, is
>>> ten times faster than the other.
>>
>> Suppose I had car, and a teleportation device that made my ears itch,
>> wouldn't I prefer the teleporter to the car and disregard the itch?
>>
>> Suppose I had a trillion dollars, wouldn't I prefer that to the current
>> situation?
>>
>> Suppose you stopped making up idiotic scenarios?
>
> Are you suggesting my scenario is far-fetched?
>
> If so, in what way?
When I read the above, I thought you were suggesting that one of the
compilers is ten times faster *because* it doesn't report 0x123e+1
as an error. It seems I was mistaken, but if you'll re-read what you
wrote, perhaps you'll agree that that's a plausible interpretation.
I think you were actually asking about the relative importance
of speed and conformance. But in this case I think that's a
meaningless question, since I expect that following the Standard's
requirements for handing pp-numbers and constants would have no
discernible effect on performance. If an amazingly fast compiler
doesn't report 0x123e+1 as an error, that's a conformance bug that
should be easy to fix.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 18:02 +0000 |
| Message-ID | <o43j10$u8i$1@dont-email.me> |
| In reply to | #100558 |
On 29/12/2016 17:36, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Are you suggesting my scenario is far-fetched? >> >> If so, in what way? > > When I read the above, I thought you were suggesting that one of the > compilers is ten times faster *because* it doesn't report 0x123e+1 > as an error. Yes, one would be faster than another for a variety of reasons (by cutting extra corners, or not having to check 1200 options at each step). It seems I was mistaken, but if you'll re-read what you > wrote, perhaps you'll agree that that's a plausible interpretation. > > I think you were actually asking about the relative importance > of speed and conformance. But in this case I think that's a > meaningless question, since I expect that following the Standard's > requirements for handing pp-numbers and constants would have no > discernible effect on performance. I've thought about it some more, and I think a tokeniser can be more conforming without compromising speed so much. But it would need a different approach from what I intend to use for now. Tokenising is expected to be perhaps 10% of overall compile time so there is some leeway. But I will know more in a few weeks. (This is a good way of learning more about the preprocessor actually. I rarely use #if nor macros with parameters, and I can already see they present special problems to implement. At the minute I have no idea how to do so nor fully what they can do.) > If an amazingly fast compiler > doesn't report 0x123e+1 as an error, that's a conformance bug that > should be easy to fix. That can also be bodged; if a hex number ending with e or E is immediately followed by + or -, than raise an error. It would appear silly to deliberately cripple a program like that, but the language requires it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 16:17 +0000 |
| Message-ID | <o4618c$scq$1@dont-email.me> |
| In reply to | #100569 |
On 29/12/2016 18:02, BartC wrote: > On 29/12/2016 17:36, Keith Thompson wrote: >> I think you were actually asking about the relative importance >> of speed and conformance. But in this case I think that's a >> meaningless question, since I expect that following the Standard's >> requirements for handing pp-numbers and constants would have no >> discernible effect on performance. > > I've thought about it some more, and I think a tokeniser can be more > conforming without compromising speed so much. But it would need a > different approach from what I intend to use for now. Tokenising is > expected to be perhaps 10% of overall compile time so there is some leeway. > > But I will know more in a few weeks. I've been looking some more at the C preprocessor and what it can do (since I make very little use of it myself). There's a very clear explanation here actually (compared to the usual gnu docs and certainly compared to the C standard): https://gcc.gnu.org/onlinedocs/cpp/Macros.html Go up one level for more general CPP stuff. But it's gcc-oriented. My first thought was, what evil so-and-so dreamt this lot up! My second was that I will need to start my project again... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-01 16:09 +0100 |
| Message-ID | <o4b606$mp$1@dont-email.me> |
| In reply to | #100671 |
On 30/12/16 17:17, BartC wrote: > On 29/12/2016 18:02, BartC wrote: >> On 29/12/2016 17:36, Keith Thompson wrote: > >>> I think you were actually asking about the relative importance >>> of speed and conformance. But in this case I think that's a >>> meaningless question, since I expect that following the Standard's >>> requirements for handing pp-numbers and constants would have no >>> discernible effect on performance. >> >> I've thought about it some more, and I think a tokeniser can be more >> conforming without compromising speed so much. But it would need a >> different approach from what I intend to use for now. Tokenising is >> expected to be perhaps 10% of overall compile time so there is some >> leeway. >> >> But I will know more in a few weeks. > > I've been looking some more at the C preprocessor and what it can do > (since I make very little use of it myself). > > There's a very clear explanation here actually (compared to the usual > gnu docs and certainly compared to the C standard): > > https://gcc.gnu.org/onlinedocs/cpp/Macros.html > > Go up one level for more general CPP stuff. But it's gcc-oriented. > Most of that document is pure standard C pre-processor. The gcc folks are currently discussing splitting up the document, precisely because the majority of it is a general CPP reference and very little is gcc related, and they'd rather not consider maintenance of that reference as part of a gcc release. The reason the document still exists is that it is considered one of the best general CPP references that is easily and freely available. > My first thought was, what evil so-and-so dreamt this lot up! My second > was that I will need to start my project again... >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 20:02 +0000 |
| Message-ID | <o415m0$iiq$1@dont-email.me> |
| In reply to | #100542 |
On 28/12/2016 19:52, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: > >> On 28/12/2016 18:19, Keith Thompson wrote: >>> So you're going to implement a C preprocessor, but you're not interested >>> in what the Standard says. Interesting choice. >> >> Suppose you had a choice of two compilers. They work identically except >> that one reports the 0x123e+1 as an error and other doesn't. >> >> The one that doesn't, that doesn't quite follow the Standard 100%, is >> ten times faster than the other. > > Suppose I had car, and a teleportation device that made my ears itch, > wouldn't I prefer the teleporter to the car and disregard the itch? > > Suppose I had a trillion dollars, wouldn't I prefer that to the current > situation? > > Suppose you stopped making up idiotic scenarios? Are you suggesting my scenario is far-fetched? If so, in what way? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 12:32 -0800 |
| Message-ID | <lnh95n3icl.fsf@kst-u.example.com> |
| In reply to | #100559 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 19:52, Richard Bos wrote:
>> BartC <bc@freeuk.com> wrote:
>>> On 28/12/2016 18:19, Keith Thompson wrote:
>>>> So you're going to implement a C preprocessor, but you're not interested
>>>> in what the Standard says. Interesting choice.
>>>
>>> Suppose you had a choice of two compilers. They work identically except
>>> that one reports the 0x123e+1 as an error and other doesn't.
>>>
>>> The one that doesn't, that doesn't quite follow the Standard 100%, is
>>> ten times faster than the other.
>>
>> Suppose I had car, and a teleportation device that made my ears itch,
>> wouldn't I prefer the teleporter to the car and disregard the itch?
>>
>> Suppose I had a trillion dollars, wouldn't I prefer that to the current
>> situation?
>>
>> Suppose you stopped making up idiotic scenarios?
>
> Are you suggesting my scenario is far-fetched?
>
> If so, in what way?
I don't believe you're serious.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-29 13:45 +0000 |
| Message-ID | <o433v7$38q$1@dont-email.me> |
| In reply to | #100567 |
On 28/12/16 20:32, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 28/12/2016 19:52, Richard Bos wrote: <snip> >>> >>> Suppose you stopped making up idiotic scenarios? >> >> Are you suggesting my scenario is far-fetched? >> >> If so, in what way? > > I don't believe you're serious. Then for pity's sake killfile him. Then maybe we can restore a little sanity to this newsgroup. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 17:16 +0000 |
| Message-ID | <87d1gcgeix.fsf@bsb.me.uk> |
| In reply to | #100429 |
supercat@casperkitty.com writes:
> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>> This is contrary to my understanding of how the preprocessor works,
>> which is that the output is considered to be text-based, not
>> token-based, and the next compilation phase will see the character
>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>
> Prior to the C Standard, some compilers had a preprocessor stage which ran
> through all the source files and combined them into a preprocessor-output
> text file, which was then fed to subsequent compilation stages, while others
> would have the preprocessor generate data in an internal-use format (either
> in memory or disk) which retained the results of scanning certain
> parts.
Why "prior to the C Standard"? Do think this situation has changed?
> For example, given something like:
>
> #define plusplus() ++
s/plusplus/plus/
> int main(void)
> {
> int i=0,=0;
s/,/,j/
> return i+plus()j;
> }
>
> some compilers which ran the preprocessor as a separate stage may have
> converted the return statement into "return i+++j;" which would in turn
> be parsed as "return i++ +j;", but others may have converted the first
> + to a token before expanding the macro "plus()", and thus interpreting
> the statement as "return i+ ++j;".
My recollection is that compilers generally got this right. Do you know
any that did not? It was not uncommon for compilers to generate PP
output that was not acceptable as input, but I think the compilers all
got the lexing correct internally. That might be what you are
remembering.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 10:04 -0800 |
| Message-ID | <lnshp83p7f.fsf@kst-u.example.com> |
| In reply to | #100429 |
supercat@casperkitty.com writes:
> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>> This is contrary to my understanding of how the preprocessor works,
>> which is that the output is considered to be text-based, not
>> token-based, and the next compilation phase will see the character
>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>
> Prior to the C Standard, some compilers had a preprocessor stage which ran
> through all the source files and combined them into a preprocessor-output
> text file, which was then fed to subsequent compilation stages, while others
> would have the preprocessor generate data in an internal-use format (either
> in memory or disk) which retained the results of scanning certain parts.
>
> For example, given something like:
>
> #define plusplus() ++
> int main(void)
> {
> int i=0,=0;
> return i+plus()j;
> }
>
> some compilers which ran the preprocessor as a separate stage may have
> converted the return statement into "return i+++j;" which would in turn
> be parsed as "return i++ +j;", but others may have converted the first
> + to a token before expanding the macro "plus()", and thus interpreting
> the statement as "return i+ ++j;".
And the standard made the behavior consistent.
When I fix your typo, changing plus() to plusplus(), the output of
"gcc -E" includes
return i+ ++j;
The preprocessor inserts a space so that the "+" and "++" will be parsed
as distinct tokens.
I believe the description of the preprocessing phases is specifically
designed to permit a conforming compiler to use text as the output of
the preprocessor.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:26 -0800 |
| Message-ID | <kfnzij9sqpb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100449 |
Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
>> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>>> This is contrary to my understanding of how the preprocessor works,
>>> which is that the output is considered to be text-based, not
>>> token-based, and the next compilation phase will see the character
>>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>>
>> Prior to the C Standard, some compilers had a preprocessor stage which ran
>> through all the source files and combined them into a preprocessor-output
>> text file, which was then fed to subsequent compilation stages, while others
>> would have the preprocessor generate data in an internal-use format (either
>> in memory or disk) which retained the results of scanning certain parts.
>>
>> For example, given something like:
>>
>> #define plusplus() ++
>> int main(void)
>> {
>> int i=0,=0;
>> return i+plus()j;
>> }
>>
>> some compilers which ran the preprocessor as a separate stage may have
>> converted the return statement into "return i+++j;" which would in turn
>> be parsed as "return i++ +j;", but others may have converted the first
>> + to a token before expanding the macro "plus()", and thus interpreting
>> the statement as "return i+ ++j;".
>
> And the standard made the behavior consistent.
>
> When I fix your typo, changing plus() to plusplus(), the output of
> "gcc -E" includes
>
> return i+ ++j;
>
> The preprocessor inserts a space so that the "+" and "++" will be parsed
> as distinct tokens.
>
> I believe the description of the preprocessing phases is specifically
> designed to permit a conforming compiler to use text as the output of
> the preprocessor.
Sort of. I think that is true for the _ultimate_ output
of the preprocessor, but not for intermediate outputs,
which have to preserve token boundaries without adding
extra spaces to do so (because of how stringizing has
to work).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 12:35 -0800 |
| Message-ID | <lnh95hw67n.fsf@kst-u.example.com> |
| In reply to | #100858 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> I believe the description of the preprocessing phases is specifically
>> designed to permit a conforming compiler to use text as the output of
>> the preprocessor.
>
> Sort of. I think that is true for the _ultimate_ output
> of the preprocessor, but not for intermediate outputs,
> which have to preserve token boundaries without adding
> extra spaces to do so (because of how stringizing has
> to work).
What I referred to as "the output of the preprocessor" was the output of
translation phase 5. (Phase 6 concatenates string literals; I'm
assuming that's not done by the preprocessor, though it could be.)
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-12 23:22 -0800 |
| Message-ID | <kfno9zbqvae.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100902 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> I believe the description of the preprocessing phases is specifically >>> designed to permit a conforming compiler to use text as the output of >>> the preprocessor. >> >> Sort of. I think that is true for the _ultimate_ output >> of the preprocessor, but not for intermediate outputs, >> which have to preserve token boundaries without adding >> extra spaces to do so (because of how stringizing has >> to work). > > What I referred to as "the output of the preprocessor" was the output of > translation phase 5. [...] Yes, I understood that. My point is that this result is not very meaningful, since nothing in those later phases depends on extra spacing between tokens. So the output of phase 5 could simply add a space before every token, and that has no effect on any downstream processing (except of course for making sure that two adjacent tokens are not merged into one, which is the point of the exercise). Without the ability to add extra spaces, phase 5 sometimes cannot use regular text for its output, because needed token boundaries might disappear.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 10:04 -0800 |
| Message-ID | <ln8tqen8f0.fsf@kst-u.example.com> |
| In reply to | #101583 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>
>>>> I believe the description of the preprocessing phases is specifically
>>>> designed to permit a conforming compiler to use text as the output of
>>>> the preprocessor.
>>>
>>> Sort of. I think that is true for the _ultimate_ output
>>> of the preprocessor, but not for intermediate outputs,
>>> which have to preserve token boundaries without adding
>>> extra spaces to do so (because of how stringizing has
>>> to work).
>>
>> What I referred to as "the output of the preprocessor" was the output of
>> translation phase 5. [...]
>
> Yes, I understood that. My point is that this result is not
> very meaningful, since nothing in those later phases depends on
> extra spacing between tokens. So the output of phase 5 could
> simply add a space before every token, and that has no effect
> on any downstream processing (except of course for making
> sure that two adjacent tokens are not merged into one, which
> is the point of the exercise).
>
> Without the ability to add extra spaces, phase 5 sometimes cannot
> use regular text for its output, because needed token boundaries
> might disappear.
It's likely I'm missing your point.
I said that the standard's description of the behavior of the
preprocessor is designed to permit (but of course not require) an
implementation where that output is plain text. I said nothing
about intermediate outputs. I don't see how your remarks are
relevant to what I said.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-14 00:45 -0800 |
| Message-ID | <kfnfukmni65.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101634 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>> [...]
>>>
>>>>> I believe the description of the preprocessing phases is specifically
>>>>> designed to permit a conforming compiler to use text as the output of
>>>>> the preprocessor.
>>>>
>>>> Sort of. I think that is true for the _ultimate_ output
>>>> of the preprocessor, but not for intermediate outputs,
>>>> which have to preserve token boundaries without adding
>>>> extra spaces to do so (because of how stringizing has
>>>> to work).
>>>
>>> What I referred to as "the output of the preprocessor" was the output of
>>> translation phase 5. [...]
>>
>> Yes, I understood that. My point is that this result is not
>> very meaningful, since nothing in those later phases depends on
>> extra spacing between tokens. So the output of phase 5 could
>> simply add a space before every token, and that has no effect
>> on any downstream processing (except of course for making
>> sure that two adjacent tokens are not merged into one, which
>> is the point of the exercise).
>>
>> Without the ability to add extra spaces, phase 5 sometimes cannot
>> use regular text for its output, because needed token boundaries
>> might disappear.
>
> It's likely I'm missing your point.
>
> I said that the standard's description of the behavior of the
> preprocessor is designed to permit (but of course not require) an
> implementation where that output is plain text. I said nothing
> about intermediate outputs. I don't see how your remarks are
> relevant to what I said.
Let me try again.
What you said (ie, that the output of phase 5 could be just
ordinary text) is true but it is essentially vacuously true.
The reason for this is that phases after 5 aren't affected
by adding spaces between tokens. Hence a macro that expands
to
x+++++y
where this means (using @ signs to show token boundaries)
x@++@+@++@y
could by output by phase 5 as
x ++ + ++ y
and the later phase would see the same tokens that the
preprocessor had seen, and more importantly _that would
not disturb any further processing_. Note that this
statement does not apply while the implementation is
in the midst of preprocessing: a macro that expands
as (assuming the same token boundaries as above)
x+++++y
cannot be represented as
x ++ + ++ y
because that could change the result of the preprocessor (ie,
because of stringizing). Because phase 6 and later aren't
affected by adding extra spaces like this, it's easy to see
phase 5 could simply output tokens one by one with a space
output before each token, whether there was any space there
in the orginal input or not. It's true that the output of
phase 5 could be rendered faithfully as ordinary text, but
no special effort was needed in designing the preprocessor
to make it be true. Because of what the later phases do,
the output of phase 5 could be ordinary text basically no
matter what the rules were for how the preprocessor would
work.
Does that make more sense now?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 09:59 -0800 |
| Message-ID | <lnwpek3pes.fsf@kst-u.example.com> |
| In reply to | #100410 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 01:52, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> The root of this minor glitch is that 'E' or 'e' can be either a
>> hexadecimal digit *or* it can introduce an exponent in a decimal
>> floating constant.
>
> But this is a hexadecimal one! So there is no conflict.
Yes, there is, as I've explained.
>>> And what would the value of that preprocessing number be?
>>
>> That particular pp-number has no value, either in the sense of a numeric
>> value or of it being useful. Its illegality is just a consequence of
>> the admittedly rather odd rules for handling numeric constants in the
>> preprocessor and in later translation phases, rules that were presumably
>> designed both to make the preprocessor's job easier and to maintain
>> compatibility with existing implementations.
>
> What /is/ the preprocessor's job? As I still don't understand what is
> going on.
Take a look at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf.
6.4.8 discusses preprocessing numbers, and 6.10 discusses preprocessing
directives. 5.1.1.2 describes the 8 translation phases. The
preprocessor's job is to implement phases 1 through 5 or 6 (there's no
definition of which phases are to be implemented by the "preprocessor",
and no requirement for it to be a separate application).
> Are you saying that the sequence "127.0.0.1", which might be parsed in a
> normal language as "127.0", ".0", ".1" (and very likely a syntax error),
> is treated by the pp as one token "127.0.0.1" and passed on to the
> program also as one token "127.0.0.1"?
Yes, I believe I already said that. And at least gcc actually does
that. If I compile a source file containing
double x = 127.0.0.1;
gcc's error message is
c.c:4:16: error: too many decimal points in number
double x = 127.0.0.1;
The form of the message indicates (but doesn't strictly prove) that
127.0.0.1 is treated as a single invalid token, not as a sequence of
tokens (127.0 .0 .1).
> This is contrary to my understanding of how the preprocessor works,
> which is that the output is considered to be text-based, not
> token-based, and the next compilation phase will see the character
> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
Then I guess your understanding differs from what the standard
specifies.
Particular implementations of the C preprocessor *do* commonly generate
output as textual C source code, which is then fed to the remainder of
the compiler for further processing. And that's perfectly valid, as
long as the resulting behavior is consistent with the requirements
implied by the phases of translation. But the standard says that the
source file is decomposed into preprocessing token in phase 3, each of
which is then converted into a single token in phase 7. It says nothing
about how preprocessing tokens and tokens are represented.
> (Wouldn't the output of an early, memory-constrained C preprocessor be
> to file, as text, which is read as text by the next stage?)
Probably. And as long as the behavior is consistent with the
translation phase model, that's perfectly valid.
[...]
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 09:45 -0800 |
| Message-ID | <c9e1c8ea-5d5f-4ae9-a7e1-372430573197@googlegroups.com> |
| In reply to | #100332 |
On Tuesday, December 27, 2016 at 12:11:03 PM UTC-5, supe...@casperkitty.com wrote:
> On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote:
> > (But I've only ever used it once. Note that for tokenising, the #x...
> > scheme can slow things down, especially when the base goes into double
> > figures. With C, only an initial 0 is a special case. But then that
> > advantage is offset by the preprocessor...)
>
> Is there any practical advantage to trying to distinguish the number type
> before the seeing the first period or other non-alphanumeric character,
> versus parsing the token and then examining it as a whole? The Standard-
> mandated interpretation of 0x123E+3 as a single token which will be a
> constraint violation if it survives the preprocessor may complicate things
> slightly, but I would think processing that as three tokens [0x123e + 3]
> would be more useful whether or not it is conforming.
I believe Ben Bacarisse referred to that principle as the "biggest bite."
Still, I have another solution. It may not be viable, but I think it's
worth considering:
Kim: Another direct hit. Shields are weakening, captain.
Janeway: Where's the C Standard now?
Seven: It's taken up position directly behind us, captain.
It's generating an inverse field making it difficult
to maneuver. We're also expending energy at 10x the
normal rate due to its close proximity.
Janeway: Tuvok, I'm tired of dealing with this. Aft torpedoes.
Full spread. Lock weapons and fire!
Tuvok: Firing. Multiple direct hits. The target has been
destroyed, captain.
Janeway: [sigh] Janeway to Torres?
Torres: Torres here, captain?
Janeway: That drain on our resources has been eliminated. Bring
the warp core back online and let's get out of here as
soon as possible.
Torres: Gladly, captain.
Janeway: Lt. Paris, once the warp core is back online, resume
our course ... warp factor 9. I'd like to put some
distance between us and this ... place.
Paris: Aye, captain. Warp 9.
Seven: An increase in efficiency, captain?
Janeway: A little breathing room at least. I'll be in my ready
room ... or what's left of it. Commander, you have the
bridge.
Chakotay: Aye, captain.
-----
Janeway: Captain's personal log, stardate supplemental. Well,
I tried. Navigating this area of space may have just
gotten a little less formal, but I think our journey
home will be more to everyone's liking. Our crew has
created a standard of its own, one which is a little
more appropriate to our circumstances here in the Delta
Quadrant. I for one look forward to seeing how much
further Lt. Torres can stretch our energy reserves now
that we won't have to deal with such ... antiquated
rigidity.
Dare to dream.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-27 17:14 +0100 |
| Message-ID | <o3u3uq$a2j$1@dont-email.me> |
| In reply to | #100323 |
On 27/12/16 16:07, Rick C. Hodgin wrote: > On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote: >> On 27/12/2016 14:19, Rick C. Hodgin wrote: >>> CAlive prefers prefixes: >>> >>> 0x hexadecimal, 0x123abc >>> 0y binary, 0y1000110 >> >> C commonly uses 0b and 0B; why not just got with that? > > For one VERY good reason: I didn't know C allowed that. :-) To be precise, /standard/ C does not have binary literals. But C++ has 0b0101 binary literals in current standards, and many C compilers (gcc, clang, and several embedded compilers) support them as extensions. > > In looking at it just now, I think seeing something like 0B10, it might > be easily confused with something like 0x0B10 in developer's minds. I > like the 0y because it really stands out as something unique. And when > you only see 1s and 0s after it, I think it would be clear. But, with > a "b" or "B" in there ... I can see that being interpreted as a hex > address. Remember the old DOS days with 0b0000h addresses being used > for the monochrome monitor starting data address? > I believe it is most common to use the small letter: 0b0101. > Nonetheless, now that I know of that feature's existence, CAlive will > allow both. Fair enough. Do you also allow a separator inside literals? And if so, do you allow the C++ choice 0b'0101'1101 or the clearer 0b_0101_1101 ? (C++ could not choose to use underscore here, because it was already used for user-defined suffixes.) > > Feel free to point out any other areas where CAlive is missing > something C supports. I genuinely desire to make a fully compatible > C90 + C99 compiler at some point. And I want CAlive to be nearly > 100% compatible in its native form (if you use C syntax, and not > CAlive's new syntax). And in areas where my knowledge is insufficient, > I welcome the assistance. > You might want to have a look here: <https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html> These are not standard C - they are extensions to C. But they are mostly useful features, and many of them are implemented in other C compilers too (clang certainly covers most of them).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 08:23 -0800 |
| Message-ID | <2988cfc6-bdc4-4277-948c-648eeaa1b7cf@googlegroups.com> |
| In reply to | #100327 |
On Tuesday, December 27, 2016 at 11:14:53 AM UTC-5, David Brown wrote:
> On 27/12/16 16:07, Rick C. Hodgin wrote:
> > On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote:
> >> On 27/12/2016 14:19, Rick C. Hodgin wrote:
> >>> CAlive prefers prefixes:
> >>>
> >>> 0x hexadecimal, 0x123abc
> >>> 0y binary, 0y1000110
> >>
> >> C commonly uses 0b and 0B; why not just got with that?
> >
> > For one VERY good reason: I didn't know C allowed that. :-)
>
> To be precise, /standard/ C does not have binary literals. But C++ has
> 0b0101 binary literals in current standards, and many C compilers (gcc,
> clang, and several embedded compilers) support them as extensions.
I wish I would've known about it. I could've used that many times.
> Do you also allow a separator inside literals? And if so, do you allow
> the C++ choice 0b'0101'1101 or the clearer 0b_0101_1101 ? (C++ could
> not choose to use underscore here, because it was already used for
> user-defined suffixes.)
I didn't know C++ allowed tick marks. I allow commas and tick marks:
https://groups.google.com/d/msg/caliveprogramminglanguage/gSh-eRA77nk/M9OIsTrVBwAJ
Commas will work when they successfully concatenate a value for a type,
do not have whitespaces, and the parameter count is correct when parsing
them in that way. If the parameter count is off, or if the computed
value for the type is exceeded, it will re-evaluate the syntax as though
commas were not allowed as value separators. If it fails at that point,
it will generate a diagnostic. And, in the case of re-evaluation which
then does work, it will generate a warning suggesting the use of
whitespaces.
> > Feel free to point out any other areas where CAlive is missing
> > something C supports. I genuinely desire to make a fully compatible
> > C90 + C99 compiler at some point. And I want CAlive to be nearly
> > 100% compatible in its native form (if you use C syntax, and not
> > CAlive's new syntax). And in areas where my knowledge is insufficient,
> > I welcome the assistance.
>
> You might want to have a look here:
>
> <https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html>
>
> These are not standard C - they are extensions to C. But they are
> mostly useful features, and many of them are implemented in other C
> compilers too (clang certainly covers most of them).
Thank you.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 10:37 +0100 |
| Message-ID | <o4012n$q8r$1@dont-email.me> |
| In reply to | #100328 |
On 27/12/16 17:23, Rick C. Hodgin wrote: > On Tuesday, December 27, 2016 at 11:14:53 AM UTC-5, David Brown wrote: >> On 27/12/16 16:07, Rick C. Hodgin wrote: >>> On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote: >>>> On 27/12/2016 14:19, Rick C. Hodgin wrote: >>>>> CAlive prefers prefixes: >>>>> >>>>> 0x hexadecimal, 0x123abc >>>>> 0y binary, 0y1000110 >>>> >>>> C commonly uses 0b and 0B; why not just got with that? >>> >>> For one VERY good reason: I didn't know C allowed that. :-) >> >> To be precise, /standard/ C does not have binary literals. But C++ has >> 0b0101 binary literals in current standards, and many C compilers (gcc, >> clang, and several embedded compilers) support them as extensions. > > I wish I would've known about it. I could've used that many times. > >> Do you also allow a separator inside literals? And if so, do you allow >> the C++ choice 0b'0101'1101 or the clearer 0b_0101_1101 ? (C++ could >> not choose to use underscore here, because it was already used for >> user-defined suffixes.) > > I didn't know C++ allowed tick marks. For your reference, if you are interested, it was added in C++14: <https://en.wikipedia.org/wiki/C%2B%2B14#Digit_separators> > I allow commas and tick marks: > > https://groups.google.com/d/msg/caliveprogramminglanguage/gSh-eRA77nk/M9OIsTrVBwAJ > > Commas will work when they successfully concatenate a value for a type, > do not have whitespaces, and the parameter count is correct when parsing > them in that way. If the parameter count is off, or if the computed > value for the type is exceeded, it will re-evaluate the syntax as though > commas were not allowed as value separators. If it fails at that point, > it will generate a diagnostic. And, in the case of re-evaluation which > then does work, it will generate a warning suggesting the use of > whitespaces. > I think it would be far too easy to be inconsistent if you allow commas as digit separators - it sounds dangerous to me. Your choice, of course, and you may decide that with a gui you can make everything clear enough. 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).
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web