Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101543 > unrolled thread
| Started by | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| First post | 2017-01-12 11:48 -0800 |
| Last post | 2017-01-13 23:46 +0800 |
| Articles | 20 on this page of 190 — 24 participants |
Back to article view | Back to comp.lang.c
Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 11:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 11:58 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 01:35 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 17:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 02:19 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:26 -0800
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 00:28 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:56 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:23 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:49 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 05:03 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 16:00 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 18:28 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 18:58 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:07 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:31 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 09:20 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:47 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 10:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 21:42 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 12:55 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 13:09 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:01 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 17:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 19:45 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:51 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 21:12 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:53 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-13 08:59 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:48 +0100
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 18:03 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:05 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:30 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:00 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:52 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 12:56 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:54 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-13 22:00 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 11:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 00:59 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 17:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:47 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 01:36 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:26 +0000
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:33 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-15 02:52 -0800
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 14:48 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:07 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:40 +1300
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 11:28 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:48 +0000
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-14 13:17 +0100
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:21 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:27 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 14:00 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 16:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 16:31 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:50 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 19:48 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:15 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 23:31 +0100
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 10:28 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:52 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:49 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 23:03 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:41 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-16 20:01 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 00:19 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 00:29 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 09:12 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 11:59 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 13:16 +0000
OT: Bash tab completion (was: Naming convention for structs and types) Andreas Perstinger <andipersti@gmail.com> - 2017-01-17 13:27 +0000
Re: OT: Bash tab completion BartC <bc@freeuk.com> - 2017-01-17 13:59 +0000
Re: OT: Bash tab completion David Brown <david.brown@hesbynett.no> - 2017-01-17 15:49 +0100
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:06 -0800
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:43 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 15:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:53 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-17 20:56 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:38 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-17 14:22 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-17 23:43 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 00:33 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 11:03 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:59 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 15:45 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:28 +0100
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-18 09:30 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 23:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:22 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:47 +0100
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 08:11 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 17:17 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 09:47 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:20 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 22:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 00:31 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-18 15:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 23:58 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 11:49 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:56 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 13:18 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:50 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 07:51 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:50 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:59 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:51 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:52 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:09 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:26 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 08:10 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 12:28 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:17 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 15:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:31 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 16:03 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 15:57 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 13:29 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:45 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:19 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 15:22 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 16:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-17 17:02 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-17 20:57 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-17 08:47 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:03 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 07:04 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:01 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 11:47 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 22:16 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 15:44 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:59 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 04:42 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:57 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 11:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:36 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 05:07 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 16:09 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 07:36 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:32 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:55 +1300
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-19 22:28 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 08:36 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-20 04:27 -0800
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 12:01 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:11 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 12:50 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:02 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:26 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:35 +0000
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 16:37 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:57 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-13 16:38 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 17:52 +0100
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:07 +0000
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-12 12:45 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:01 -0800
Re: Naming convention for structs and types jadill33@gmail.com - 2017-01-12 13:57 -0800
Re: Naming convention for structs and types John Bode <jfbode1029@gmail.com> - 2017-01-12 13:59 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 15:08 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 10:33 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 15:20 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:31 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:43 +1300
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 01:00 -0800
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 13:03 -0500
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 16:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 13:36 +0100
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-14 05:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 17:27 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:05 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 09:48 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-19 13:31 -0500
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 21:18 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-22 17:10 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-22 18:27 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 12:49 -0500
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 09:55 -0800
Re: Naming convention for structs and types "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-01-13 23:46 +0800
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-13 12:55 -0800 |
| Message-ID | <9f443dc8-b50c-4b6b-b062-aa4f7baf0787@googlegroups.com> |
| In reply to | #101658 |
On Friday, January 13, 2017 at 3:42:22 PM UTC-5, David Brown wrote:
> On 13/01/17 19:02, Rick C. Hodgin wrote:
> > I intend to introduce these features into CAlive, and be done with
> > it. And my offering here to Fernando D. Bozzo is an offering to
> > simplify his programming life in C by using these few features of
> > a C++ compiler, and by switching to a C++ compiler to use them.
>
> For the umpteenth time, it is not an "offering"...
By definition it is an offering, David:
http://www.dictionary.com/browse/offering
noun
4. something presented for inspection or sale.
verb
2. to propose or put forward for consideration
I have offered this option / alternative to Fernando D. Bozzo for his
inspection. He can look it over and decide if the advice is good or
not.
I continue to pray for you, David.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-13 13:09 -0800 |
| Message-ID | <10de8e0d-528b-43aa-8b90-bc2f496677cd@googlegroups.com> |
| In reply to | #101658 |
On Friday, January 13, 2017 at 2:42:22 PM UTC-6, David Brown wrote:
> C /is/ defined by the standards. That is what C is.
By that definition, are there any programs for freestanding implementations
which are not semantically equivalent to one of the following:
int main(void) { while(1); } // Guaranteed not to do anything
int main(void) { int x; x++; } // Allowed by the Standard to do anything
The second program might qualify as conforming (an implementation could
defines the effects of incrementing an uninitialized variable and
returning from main) but would certainly not be strictly conforming. The
former program would be strictly conforming, but not terribly useful.
Anything useful that could be done on freestanding implementations would
require the use of features not defined by the Standard. If the term C
does not include anything beyond the Standard, what would be the point of
defining freestanding implementations at all?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-15 21:01 -0800 |
| Message-ID | <kfnshojk37t.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101665 |
supercat@casperkitty.com writes:
> On Friday, January 13, 2017 at 2:42:22 PM UTC-6, David Brown wrote:
>> C /is/ defined by the standards. That is what C is.
>
> By that definition, are there any programs for freestanding implementations
> which are not semantically equivalent to one of the following:
>
> int main(void) { while(1); } // Guaranteed not to do anything
>
> int main(void) { int x; x++; } // Allowed by the Standard to do anything
Yes, lots of them, because the Standard allows programs that
depend on implementation-defined behavior, and that is also
part of the definition of C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-12 17:48 -0800 |
| Message-ID | <o59bhv$arq$1@dont-email.me> |
| In reply to | #101545 |
On 1/12/2017 11:58 AM, Rick C. Hodgin wrote:
> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>> Hi:
>>
>> I made this struct:
>>
>>
>> typedef struct justfname_s
>> {
>> char *value;
>> int len;
>> } justfname_t;
>>
>>
>> and want to know if it's correct to end struct's names with "_s" and types with "_t".
>> In what I've read until now, I didn't see any clear convention.
>
> There are conventions people use apart from C standards. You can
> also define structs without typedef commands if you switch to a
> C++ compiler to compile your C code.
>
> I typically use:
>
> struct SWhatever
> {
> // members go here
> };
>
> And then in C++ you can reference it thusly:
>
> SWhatever *w = malloc(sizeof(*w));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6
What about the cast to SWhatever* and the missing std::?
In my experience, C++ does not really like for somebody to use
std::malloc without a cast.
;^)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-12 19:35 -0800 |
| Message-ID | <ac618d99-b7d4-4c5d-b58a-57fbed064963@googlegroups.com> |
| In reply to | #101570 |
On Thursday, January 12, 2017 at 8:48:21 PM UTC-5, Chris M. Thomasson wrote:
> On 1/12/2017 11:58 AM, Rick C. Hodgin wrote:
> > On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> >> Hi:
> >>
> >> I made this struct:
> >>
> >>
> >> typedef struct justfname_s
> >> {
> >> char *value;
> >> int len;
> >> } justfname_t;
> >>
> >>
> >> and want to know if it's correct to end struct's names with "_s" and types with "_t".
> >> In what I've read until now, I didn't see any clear convention.
> >
> > There are conventions people use apart from C standards. You can
> > also define structs without typedef commands if you switch to a
> > C++ compiler to compile your C code.
> >
> > I typically use:
> >
> > struct SWhatever
> > {
> > // members go here
> > };
> >
> > And then in C++ you can reference it thusly:
> >
> > SWhatever *w = malloc(sizeof(*w));
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6
>
> What about the cast to SWhatever* and the missing std::?
>
> In my experience, C++ does not really like for somebody to use
> std::malloc without a cast.
Correct. My mistake in that post. That's actually one of the main
reasons I use a C++ compiler for writing C code (stricter typing).
I also think C's requirement of using the keyword struct everywhere
is lunacy. And requiring a typedef to not use it, and two names,
is even more lunacy. But hey, that's just me. :-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-12 19:45 -0800 |
| Message-ID | <o59idl$kbr$1@dont-email.me> |
| In reply to | #101573 |
On 1/12/2017 7:35 PM, Rick C. Hodgin wrote:
> On Thursday, January 12, 2017 at 8:48:21 PM UTC-5, Chris M. Thomasson wrote:
>> On 1/12/2017 11:58 AM, Rick C. Hodgin wrote:
>>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>>>> Hi:
>>>>
>>>> I made this struct:
>>>>
>>>>
>>>> typedef struct justfname_s
>>>> {
>>>> char *value;
>>>> int len;
>>>> } justfname_t;
>>>>
>>>>
>>>> and want to know if it's correct to end struct's names with "_s" and types with "_t".
>>>> In what I've read until now, I didn't see any clear convention.
>>>
>>> There are conventions people use apart from C standards. You can
>>> also define structs without typedef commands if you switch to a
>>> C++ compiler to compile your C code.
>>>
>>> I typically use:
>>>
>>> struct SWhatever
>>> {
>>> // members go here
>>> };
>>>
>>> And then in C++ you can reference it thusly:
>>>
>>> SWhatever *w = malloc(sizeof(*w));
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6
>>
>> What about the cast to SWhatever* and the missing std::?
>>
>> In my experience, C++ does not really like for somebody to use
>> std::malloc without a cast.
>
> Correct. My mistake in that post. That's actually one of the main
> reasons I use a C++ compiler for writing C code (stricter typing).
Okay.
> I also think C's requirement of using the keyword struct everywhere
> is lunacy.
Why?
> And requiring a typedef to not use it, and two names,
> is even more lunacy. But hey, that's just me. :-)
Yup. :^)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-12 19:51 -0800 |
| Message-ID | <f89db573-f881-47ab-8345-ec7a9e2a91fa@googlegroups.com> |
| In reply to | #101575 |
On Thursday, January 12, 2017 at 10:45:31 PM UTC-5, Chris M. Thomasson wrote: > On 1/12/2017 7:35 PM, Rick C. Hodgin wrote: > > I also think C's requirement of using the keyword struct everywhere > > is lunacy. > > Why? struct Why? struct Because struct it's struct very struct cluttered. struct It struct becomes struct superfluous, struct or, struct extra struct unnecessary struct information struct that struct doesn't struct really struct add struct anything struct (as C++ demonstrates for us so very clearly by it not requiring the keyword anywhere except the definition, which is as it should be). struct Best struct regards, struct Rick struct C. struct Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-12 21:12 -0800 |
| Message-ID | <o59ngf$vfj$1@dont-email.me> |
| In reply to | #101576 |
On 1/12/2017 7:51 PM, Rick C. Hodgin wrote: > On Thursday, January 12, 2017 at 10:45:31 PM UTC-5, Chris M. Thomasson wrote: >> On 1/12/2017 7:35 PM, Rick C. Hodgin wrote: >>> I also think C's requirement of using the keyword struct everywhere >>> is lunacy. >> >> Why? > > struct Why? > struct Because struct it's struct very struct cluttered. struct It struct > becomes struct superfluous, struct or, struct extra struct unnecessary > struct information struct that struct doesn't struct really struct > add struct anything struct (as C++ demonstrates for us so very clearly > by it not requiring the keyword anywhere except the definition, which > is as it should be). use C++ then? Ahh, struct it!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-13 12:53 +0100 |
| Message-ID | <o5af0p$3om$1@dont-email.me> |
| In reply to | #101576 |
On 13/01/17 04:51, Rick C. Hodgin wrote: > On Thursday, January 12, 2017 at 10:45:31 PM UTC-5, Chris M. Thomasson wrote: >> On 1/12/2017 7:35 PM, Rick C. Hodgin wrote: >>> I also think C's requirement of using the keyword struct everywhere >>> is lunacy. >> >> Why? > > struct Why? > > struct Because struct it's struct very struct cluttered. struct It struct > becomes struct superfluous, struct or, struct extra struct unnecessary > struct information struct that struct doesn't struct really struct > add struct anything struct (as C++ demonstrates for us so very clearly > by it not requiring the keyword anywhere except the definition, which > is as it should be). > > struct Best struct regards, > struct Rick struct C. struct Hodgin > Some people prefer to have the struct keyword wherever they use a struct. Similarly, they prefer to have a * when pointers are used. Other people prefer to use typedef's and omit the struct, and perhaps have typedefs for pointer types too. Pick whichever form /you/ think makes your code clearer, your programming easier, and your results less buggy. That applies whether you write in C, C++, or a C-like subset of C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 08:59 -0800 |
| Message-ID | <lnpojqnbep.fsf@kst-u.example.com> |
| In reply to | #101599 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Pick whichever form /you/ think makes your code clearer, your
> programming easier, and your results less buggy. That applies whether
> you write in C, C++, or a C-like subset of C++.
Or, more commonly, use whatever convention already exists in the code
you're working on, whether you like it or not. If you're working by
yourself on your own project, impose whatever conventions you like. If
you're not (and that's the most common case), consistency is important.
--
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 | 2017-01-13 18:48 +0100 |
| Message-ID | <o5b3q2$2eo$2@dont-email.me> |
| In reply to | #101618 |
On 13/01/17 17:59, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Pick whichever form /you/ think makes your code clearer, your >> programming easier, and your results less buggy. That applies whether >> you write in C, C++, or a C-like subset of C++. > > Or, more commonly, use whatever convention already exists in the code > you're working on, whether you like it or not. If you're working by > yourself on your own project, impose whatever conventions you like. If > you're not (and that's the most common case), consistency is important. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-13 18:03 -0800 |
| Message-ID | <o5c0q4$8au$1@dont-email.me> |
| In reply to | #101618 |
On 1/13/2017 8:59 AM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Pick whichever form /you/ think makes your code clearer, your >> programming easier, and your results less buggy. That applies whether >> you write in C, C++, or a C-like subset of C++. > > Or, more commonly, use whatever convention already exists in the code > you're working on, whether you like it or not. If you're working by > yourself on your own project, impose whatever conventions you like. If > you're not (and that's the most common case), consistency is important. > Agreed. IMVHO, the art of being able to adapt ones "self-style" to an existing teams "foreign" coding style is an _essential_ skill for anyone to posses.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-18 12:05 +0000 |
| Message-ID | <587f5988.3727843@news.xs4all.nl> |
| In reply to | #101618 |
Keith Thompson <kst-u@mib.org> wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] > > Pick whichever form /you/ think makes your code clearer, your > > programming easier, and your results less buggy. That applies whether > > you write in C, C++, or a C-like subset of C++. > > Or, more commonly, use whatever convention already exists in the code > you're working on, whether you like it or not. If you're working by > yourself on your own project, impose whatever conventions you like. If > you're not (and that's the most common case), consistency is important. I'd like to add that even if you are, internal consistency is still important. Someone else may still want to read your code, and that someone else may be you in five years. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-13 19:30 +1300 |
| Message-ID | <edraguF4adcU2@mid.individual.net> |
| In reply to | #101545 |
On 01/13/17 08:58 AM, Rick C. Hodgin wrote: <> Other comments are all good. > I use the SWhatever because it's a convention in C++ to use CWhatever > for classes. No it isn't a convention, it is an artifact of MFC naming many of us C++ programmers despise. > It's not very popular in this comp.lang.c group to postulate using a > C++ compiler for C code, but I do very highly recommend it. It adds > a lot, and you lose nothing except possibly compile time (C++ > compilers are often notably slower than C compilers). Not when compiling what amounts to C. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-13 13:00 +0000 |
| Message-ID | <o5aith$qv9$1@dont-email.me> |
| In reply to | #101580 |
On 13/01/17 06:30, Ian Collins wrote: > On 01/13/17 08:58 AM, Rick C. Hodgin wrote: > > <> > > Other comments are all good. > >> I use the SWhatever because it's a convention in C++ to use CWhatever >> for classes. > > No it isn't a convention, it is an artifact of MFC naming many of us C++ > programmers despise. > >> It's not very popular in this comp.lang.c group to postulate using a >> C++ compiler for C code, but I do very highly recommend it. It adds >> a lot, and you lose nothing except possibly compile time (C++ >> compilers are often notably slower than C compilers). > > Not when compiling what amounts to C. Do you mean that you agree with him that using a C++ compiler for C code is a good idea? If so, why, and what do you do with C code that isn't legal C++, or that has different meanings in C and C++? -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 10:43 -0800 |
| Message-ID | <c2873081-2433-4659-a3a0-d1e74d76801d@googlegroups.com> |
| In reply to | #101604 |
On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote: > On 13/01/17 06:30, Ian Collins wrote: > > Do you mean that you agree with him that using a C++ compiler for C code > is a good idea? If so, why, and what do you do with C code that isn't > legal C++, or that has different meanings in C and C++? > It's a reasonable idea. It means you can cut and paste C routines into C++ programs. Also, some C++ compilers seem to throw wobblies when asked to link with C. I got a complaint that the math library had been doubly defined, for example. Eventually you fiddle with it and the link errors go away, but that's not a productive use of programmer time. C code that does something different in C++ is usually a bad idea, or joke code. But you can have the problem that C works fine on what C++ folks call PODs, plain old data, but breaks down when machinery is attached to the data. In my view, a fundamental misdesign of C++, but impossible to eradicate now. (C++ people are beginning to address the issue with the "data" and "view" concept). But the risk of accidentally using a C++ only construct in what is supposedly C code outweighs the benefits of using a C++ compiler.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-13 18:52 +0000 |
| Message-ID | <o5b7hn$4qe$3@dont-email.me> |
| In reply to | #101643 |
On 13/01/17 18:43, Malcolm McLean wrote: > On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote: >> On 13/01/17 06:30, Ian Collins wrote: >> >> Do you mean that you agree with him that using a C++ compiler for C code >> is a good idea? If so, why, and what do you do with C code that isn't >> legal C++, or that has different meanings in C and C++? >> > It's a reasonable idea. It means you can cut and paste C routines into C++ > programs. That's a bad idea in itself! Compile the C as C, and link it into the C++ program. Why duplicate the code? > Also, some C++ compilers seem to throw wobblies when asked to > link with C. Not when you ask nice. > I got a complaint that the math library had been doubly defined, > for example. Eventually you fiddle with it and the link errors go away, but > that's not a productive use of programmer time. But you write it down somewhere, and then other people look up what you've written, and they don't have to fiddle. > C code that does something different in C++ is usually a bad idea, or joke > code. I don't write C code with the intent of being able to compile it in C++. As a consequence, sometimes it isn't legal C++ code. It isn't joke code, either, so presumably you're saying it's a bad idea. Why? -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 12:56 -0800 |
| Message-ID | <5f80f737-f90a-41c9-9ffd-b82ae919840d@googlegroups.com> |
| In reply to | #101650 |
On Friday, January 13, 2017 at 6:52:14 PM UTC, Richard Heathfield wrote: > On 13/01/17 18:43, Malcolm McLean wrote: > > > Also, some C++ compilers seem to throw wobblies when asked to > > link with C. > > Not when you ask nice. > The problem is that modern compilers have a whole massive list of options, If the options are not set up correctly, it fails with confusing messages (currently my XCode compiler is reporting a fail because some post-processing script doesn't find the right file, but in fact produces a workable plug-in). Then half the time the options are not set directly but via CMake, which is effectively a programming language for building IDE files. When things go wrong, as they frequently do, it is very time-consuming.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-14 10:54 +1300 |
| Message-ID | <edt0kvF4adeU2@mid.individual.net> |
| In reply to | #101663 |
On 01/14/17 09:56 AM, Malcolm McLean wrote: > On Friday, January 13, 2017 at 6:52:14 PM UTC, Richard Heathfield wrote: >> On 13/01/17 18:43, Malcolm McLean wrote: >> >>> Also, some C++ compilers seem to throw wobblies when asked to >>> link with C. >> >> Not when you ask nice. >> > The problem is that modern compilers have a whole massive list of options, > If the options are not set up correctly, it fails with confusing > messages (currently my XCode compiler is reporting a fail because > some post-processing script doesn't find the right file, but in fact > produces a workable plug-in). > Then half the time the options are not set directly but via CMake, > which is effectively a programming language for building IDE files. > > When things go wrong, as they frequently do, it is very time-consuming. In a word, bollocks. If C++ compilers "throw wobblies when asked to link with C", no hosted C++ program would ever link. What do you think system libraries are written in, Martian? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-13 22:00 +0000 |
| Message-ID | <o5biiv$sr3$1@dont-email.me> |
| In reply to | #101671 |
On 13/01/2017 21:54, Ian Collins wrote: > On 01/14/17 09:56 AM, Malcolm McLean wrote: >> On Friday, January 13, 2017 at 6:52:14 PM UTC, Richard Heathfield wrote: >>> On 13/01/17 18:43, Malcolm McLean wrote: >>> >>>> Also, some C++ compilers seem to throw wobblies when asked to >>>> link with C. >>> >>> Not when you ask nice. >>> >> The problem is that modern compilers have a whole massive list of >> options, >> If the options are not set up correctly, it fails with confusing >> messages (currently my XCode compiler is reporting a fail because >> some post-processing script doesn't find the right file, but in fact >> produces a workable plug-in). >> Then half the time the options are not set directly but via CMake, >> which is effectively a programming language for building IDE files. >> >> When things go wrong, as they frequently do, it is very time-consuming. > > In a word, bollocks. If C++ compilers "throw wobblies when asked to > link with C", no hosted C++ program would ever link. What do you think > system libraries are written in, Martian? He didn't say it can't be done, but that it can give problems. Of course, if your entire job is spent day in and day out using and configuring all these different tools, then you're going to think it's easy. To a more casual user, the problems may be insurmountable. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web