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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 22:16 +0100 |
| Message-ID | <o5m1gr$m7a$1@dont-email.me> |
| In reply to | #102067 |
On 17/01/17 20:47, Rick C. Hodgin wrote:
> On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
>> On 01/18/17 04:04 AM, Rick C. Hodgin wrote:
>>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote:
>>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote:
>>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote:
>>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
>>>>>>> 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.
>>>>>
>>>>> I was wondering why many C++ developers despise that naming convention.
>>>>> To me it seems fundamental, such that it gives a cue on use as to exactly
>>>>> what it is.
>>>>
>>>> The context should make it obvious what it is!
>>>
>>> I look to things like long-term maintenance. I may re-enter a software
>>> project I haven't worked on actively in a year or more. I've slept
>>> since that time and things that were once in my memory solidly may be
>>> less so now.
>>>
>>> By keeping to a standard (in this case, the S or C prefixes, along with
>>> other standards), it makes it clear at a glance what it is, without
>>> having to divine from context.
>>
>> I'm currently working with a code base where the matrix class is
>> "CMatrix". A matrix is a matrix, the fact that it is a class is
>> irrelevant in the context in which it is used. In the context of C++,
>> it can't be anything other than a class. If it walks like a duck and
>> quacks like a duck, it's a duck.
>
> In that case a matrix is a matrix. But, how do you know it's a matrix
> class and not a matrix array? You'd have to search for source code
> which references it.
>
> And what about cases where the class or structure name is something
> that's not a standard word?
>
> SExternalParams
> CPixelBuffer
>
> What do those mean? Could be anything. And merely having something
> like 'externalParams' or 'pixelBuffer' would not convey enough. I
> also feel the same about just "matrix".
If you have a type PixelBuffer, what does it matter whether it is a
class or a struct? It is a type - you can declare objects of type
PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
if it is a fundamental type like "int" or a standard library type or
your own type. It's just a type.
You need to know what you can /do/ with the type - what its methods are,
what operators are valid, and so on. Adding a "C" or "S" prefix tells
you absolutely nothing about that.
>
>> Luckily C has been spared these abominations - if you really want to be
>> explicit that something is a struct, you can write "struct something".
>> I guess someone at Microsoft thought it was a good idea (and their code
>> was so awful maybe it did help) and C++ programmers have suffered the
>> consequences ever since.
>
> Or you could use SSomething.
>
>>> Just my opinion.
>>>
>>> For CAlive I also take this a step further and plan to introduce GUI
>>> color cues which identify what things are so there will be less need
>>> for names. But even with the presence of name prefixes, like "lcXyz"
>>> for a local variable char, or "tcXyz" for a parameter char, those
>>> prefixes can also be removed so the value shows up as "xyz" in the
>>> editor, while retaining its full name in the source code.
>>
>> My point is that if you need those prefixes, there's something wrong
>> with your code.
>
> Of course they're not needed. You could call everything variations
> of i and l characters:
>
> struct lillililiil
> {
> };
>
> It would compile and work flawlessly. But why do that? To make code
> easier for human beings, they are another tool in the toolbox.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-17 15:44 -0800 |
| Message-ID | <43a80d3f-c7ee-457f-b5d5-151e1a712c50@googlegroups.com> |
| In reply to | #102078 |
On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
> On 17/01/17 20:47, Rick C. Hodgin wrote:
> > On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
> >> On 01/18/17 04:04 AM, Rick C. Hodgin wrote:
> >>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote:
> >>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote:
> >>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote:
> >>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
> >>>>>>> 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.
> >>>>>
> >>>>> I was wondering why many C++ developers despise that naming convention.
> >>>>> To me it seems fundamental, such that it gives a cue on use as to exactly
> >>>>> what it is.
> >>>>
> >>>> The context should make it obvious what it is!
> >>>
> >>> I look to things like long-term maintenance. I may re-enter a software
> >>> project I haven't worked on actively in a year or more. I've slept
> >>> since that time and things that were once in my memory solidly may be
> >>> less so now.
> >>>
> >>> By keeping to a standard (in this case, the S or C prefixes, along with
> >>> other standards), it makes it clear at a glance what it is, without
> >>> having to divine from context.
> >>
> >> I'm currently working with a code base where the matrix class is
> >> "CMatrix". A matrix is a matrix, the fact that it is a class is
> >> irrelevant in the context in which it is used. In the context of C++,
> >> it can't be anything other than a class. If it walks like a duck and
> >> quacks like a duck, it's a duck.
> >
> > In that case a matrix is a matrix. But, how do you know it's a matrix
> > class and not a matrix array? You'd have to search for source code
> > which references it.
> >
> > And what about cases where the class or structure name is something
> > that's not a standard word?
> >
> > SExternalParams
> > CPixelBuffer
> >
> > What do those mean? Could be anything. And merely having something
> > like 'externalParams' or 'pixelBuffer' would not convey enough. I
> > also feel the same about just "matrix".
>
> If you have a type PixelBuffer, what does it matter whether it is a
> class or a struct? It is a type - you can declare objects of type
> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
> if it is a fundamental type like "int" or a standard library type or
> your own type. It's just a type.
Why do we have types then? Why not just create various interfaces and
use a generic placeholder type ("var") which then accumulates abilities
as needed based on what's observed to be required at compile-time?
Why formalize anything in something so rigid as a type? Why not make
it a completely flexible ad hoc type?
> You need to know what you can /do/ with the type - what its methods are,
> what operators are valid, and so on. Adding a "C" or "S" prefix tells
> you absolutely nothing about that.
It tells you that it's a class or struct and has members.
> >> Luckily C has been spared these abominations - if you really want to be
> >> explicit that something is a struct, you can write "struct something".
> >> I guess someone at Microsoft thought it was a good idea (and their code
> >> was so awful maybe it did help) and C++ programmers have suffered the
> >> consequences ever since.
> >
> > Or you could use SSomething.
> >
> >>> Just my opinion.
> >>>
> >>> For CAlive I also take this a step further and plan to introduce GUI
> >>> color cues which identify what things are so there will be less need
> >>> for names. But even with the presence of name prefixes, like "lcXyz"
> >>> for a local variable char, or "tcXyz" for a parameter char, those
> >>> prefixes can also be removed so the value shows up as "xyz" in the
> >>> editor, while retaining its full name in the source code.
> >>
> >> My point is that if you need those prefixes, there's something wrong
> >> with your code.
> >
> > Of course they're not needed. You could call everything variations
> > of i and l characters:
> >
> > struct lillililiil
> > {
> > };
> >
> > It would compile and work flawlessly. But why do that? To make code
> > easier for human beings, they are another tool in the toolbox.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 17:59 +1300 |
| Message-ID | <ee8b1kF2vaqU3@mid.individual.net> |
| In reply to | #102090 |
On 01/18/17 12:44 PM, Rick C. Hodgin wrote:
> On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
>> On 17/01/17 20:47, Rick C. Hodgin wrote:
>>> On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
>>>> On 01/18/17 04:04 AM, Rick C. Hodgin wrote:
>>>>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote:
>>>>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote:
>>>>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote:
>>>>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
>>>>>>>>> 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.
>>>>>>>
>>>>>>> I was wondering why many C++ developers despise that naming convention.
>>>>>>> To me it seems fundamental, such that it gives a cue on use as to exactly
>>>>>>> what it is.
>>>>>>
>>>>>> The context should make it obvious what it is!
>>>>>
>>>>> I look to things like long-term maintenance. I may re-enter a software
>>>>> project I haven't worked on actively in a year or more. I've slept
>>>>> since that time and things that were once in my memory solidly may be
>>>>> less so now.
>>>>>
>>>>> By keeping to a standard (in this case, the S or C prefixes, along with
>>>>> other standards), it makes it clear at a glance what it is, without
>>>>> having to divine from context.
>>>>
>>>> I'm currently working with a code base where the matrix class is
>>>> "CMatrix". A matrix is a matrix, the fact that it is a class is
>>>> irrelevant in the context in which it is used. In the context of C++,
>>>> it can't be anything other than a class. If it walks like a duck and
>>>> quacks like a duck, it's a duck.
>>>
>>> In that case a matrix is a matrix. But, how do you know it's a matrix
>>> class and not a matrix array? You'd have to search for source code
>>> which references it.
>>>
>>> And what about cases where the class or structure name is something
>>> that's not a standard word?
>>>
>>> SExternalParams
>>> CPixelBuffer
>>>
>>> What do those mean? Could be anything. And merely having something
>>> like 'externalParams' or 'pixelBuffer' would not convey enough. I
>>> also feel the same about just "matrix".
>>
>> If you have a type PixelBuffer, what does it matter whether it is a
>> class or a struct? It is a type - you can declare objects of type
>> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
>> if it is a fundamental type like "int" or a standard library type or
>> your own type. It's just a type.
>
> Why do we have types then? Why not just create various interfaces and
> use a generic placeholder type ("var") which then accumulates abilities
> as needed based on what's observed to be required at compile-time?
This comment doesn't appear to be relevant to David's post.
> Why formalize anything in something so rigid as a type? Why not make
> it a completely flexible ad hoc type?
How do you associate actions with your ad hoc type?
>> You need to know what you can /do/ with the type - what its methods are,
>> what operators are valid, and so on. Adding a "C" or "S" prefix tells
>> you absolutely nothing about that.
>
> It tells you that it's a class or struct and has members.
What do you gain? You still have to look up the declaration to find out
what those member are.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-18 04:42 -0800 |
| Message-ID | <3e38f928-e6a5-4fd7-bedf-cc3904c10553@googlegroups.com> |
| In reply to | #102101 |
On Tuesday, January 17, 2017 at 11:59:40 PM UTC-5, Ian Collins wrote:
> On 01/18/17 12:44 PM, Rick C. Hodgin wrote:
> > On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
> >> If you have a type PixelBuffer, what does it matter whether it is a
> >> class or a struct? It is a type - you can declare objects of type
> >> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
> >> if it is a fundamental type like "int" or a standard library type or
> >> your own type. It's just a type.
> >
> > Why do we have types then? Why not just create various interfaces and
> > use a generic placeholder type ("var") which then accumulates abilities
> > as needed based on what's observed to be required at compile-time?
>
> This comment doesn't appear to be relevant to David's post.
>
> > Why formalize anything in something so rigid as a type? Why not make
> > it a completely flexible ad hoc type?
>
> How do you associate actions with your ad hoc type?
What do you mean by "actions"?
> >> You need to know what you can /do/ with the type - what its methods are,
> >> what operators are valid, and so on. Adding a "C" or "S" prefix tells
> >> you absolutely nothing about that.
> >
> > It tells you that it's a class or struct and has members.
>
> What do you gain? You still have to look up the declaration to find out
> what those member are.
In tools like Visual Studio, if you saw the definition as an SXyz or
CXyz, then you would know to begin by typing the token name and ->
or . and it will list members for you.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-19 07:57 +1300 |
| Message-ID | <ee9s5iFnke7U2@mid.individual.net> |
| In reply to | #102119 |
On 01/19/17 01:42 AM, Rick C. Hodgin wrote:
> On Tuesday, January 17, 2017 at 11:59:40 PM UTC-5, Ian Collins wrote:
>> On 01/18/17 12:44 PM, Rick C. Hodgin wrote:
>>> On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
>>>> If you have a type PixelBuffer, what does it matter whether it is a
>>>> class or a struct? It is a type - you can declare objects of type
>>>> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
>>>> if it is a fundamental type like "int" or a standard library type or
>>>> your own type. It's just a type.
>>>
>>> Why do we have types then? Why not just create various interfaces and
>>> use a generic placeholder type ("var") which then accumulates abilities
>>> as needed based on what's observed to be required at compile-time?
>>
>> This comment doesn't appear to be relevant to David's post.
>>
>>> Why formalize anything in something so rigid as a type? Why not make
>>> it a completely flexible ad hoc type?
>>
>> How do you associate actions with your ad hoc type?
>
> What do you mean by "actions"?
Operators and members.
To be fair I have written C++ code that has functions returning a JSON
object and taking one as the parameter. But that was a special case :)
>>>> You need to know what you can /do/ with the type - what its methods are,
>>>> what operators are valid, and so on. Adding a "C" or "S" prefix tells
>>>> you absolutely nothing about that.
>>>
>>> It tells you that it's a class or struct and has members.
>>
>> What do you gain? You still have to look up the declaration to find out
>> what those member are.
>
> In tools like Visual Studio, if you saw the definition as an SXyz or
> CXyz, then you would know to begin by typing the token name and ->
> or . and it will list members for you.
It would do the same for Xyz. Still clutter for no gain.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-18 11:22 -0800 |
| Message-ID | <49f4a3cb-bdf1-4072-af95-20b144a1a723@googlegroups.com> |
| In reply to | #102142 |
On Wednesday, January 18, 2017 at 1:58:02 PM UTC-5, Ian Collins wrote:
> On 01/19/17 01:42 AM, Rick C. Hodgin wrote:
> > On Tuesday, January 17, 2017 at 11:59:40 PM UTC-5, Ian Collins wrote:
> >> On 01/18/17 12:44 PM, Rick C. Hodgin wrote:
> >>> On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
> >>>> If you have a type PixelBuffer, what does it matter whether it is a
> >>>> class or a struct? It is a type - you can declare objects of type
> >>>> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
> >>>> if it is a fundamental type like "int" or a standard library type or
> >>>> your own type. It's just a type.
> >>>
> >>> Why do we have types then? Why not just create various interfaces and
> >>> use a generic placeholder type ("var") which then accumulates abilities
> >>> as needed based on what's observed to be required at compile-time?
> >>
> >> This comment doesn't appear to be relevant to David's post.
> >>
> >>> Why formalize anything in something so rigid as a type? Why not make
> >>> it a completely flexible ad hoc type?
> >>
> >> How do you associate actions with your ad hoc type?
You use them. I create this initially:
var x;
I use it as an integer and the compiler associates it to an integer
type. But, later on I add this:
float f = x.round();
round() exists in template form, or not, and the editor references
it, or creates it as an empty member.
In CAlive, it creates a condition called an inquiry. It suspends
execution to the debugger/editor IDE and allows the code to be
written when encountered.
> > What do you mean by "actions"?
>
> Operators and members.
>
> To be fair I have written C++ code that has functions returning a JSON
> object and taking one as the parameter. But that was a special case :)
>
> >>>> You need to know what you can /do/ with the type - what its methods are,
> >>>> what operators are valid, and so on. Adding a "C" or "S" prefix tells
> >>>> you absolutely nothing about that.
> >>>
> >>> It tells you that it's a class or struct and has members.
> >>
> >> What do you gain? You still have to look up the declaration to find out
> >> what those member are.
> >
> > In tools like Visual Studio, if you saw the definition as an SXyz or
> > CXyz, then you would know to begin by typing the token name and ->
> > or . and it will list members for you.
>
> It would do the same for Xyz. Still clutter for no gain.
If all you ever used were classes or structs it would be no gain
because everything's on equal footing. But if you use a combination
of classes, structs, unions, enums, and pods, then ... it would be
gain.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 13:36 +0100 |
| Message-ID | <o5nndc$9qq$1@dont-email.me> |
| In reply to | #102090 |
On 18/01/17 00:44, Rick C. Hodgin wrote:
> On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
>> On 17/01/17 20:47, Rick C. Hodgin wrote:
>>> On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
>>>> On 01/18/17 04:04 AM, Rick C. Hodgin wrote:
>>>>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote:
>>>>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote:
>>>>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote:
>>>>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
>>>>>>>>> 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.
>>>>>>>
>>>>>>> I was wondering why many C++ developers despise that naming convention.
>>>>>>> To me it seems fundamental, such that it gives a cue on use as to exactly
>>>>>>> what it is.
>>>>>>
>>>>>> The context should make it obvious what it is!
>>>>>
>>>>> I look to things like long-term maintenance. I may re-enter a software
>>>>> project I haven't worked on actively in a year or more. I've slept
>>>>> since that time and things that were once in my memory solidly may be
>>>>> less so now.
>>>>>
>>>>> By keeping to a standard (in this case, the S or C prefixes, along with
>>>>> other standards), it makes it clear at a glance what it is, without
>>>>> having to divine from context.
>>>>
>>>> I'm currently working with a code base where the matrix class is
>>>> "CMatrix". A matrix is a matrix, the fact that it is a class is
>>>> irrelevant in the context in which it is used. In the context of C++,
>>>> it can't be anything other than a class. If it walks like a duck and
>>>> quacks like a duck, it's a duck.
>>>
>>> In that case a matrix is a matrix. But, how do you know it's a matrix
>>> class and not a matrix array? You'd have to search for source code
>>> which references it.
>>>
>>> And what about cases where the class or structure name is something
>>> that's not a standard word?
>>>
>>> SExternalParams
>>> CPixelBuffer
>>>
>>> What do those mean? Could be anything. And merely having something
>>> like 'externalParams' or 'pixelBuffer' would not convey enough. I
>>> also feel the same about just "matrix".
>>
>> If you have a type PixelBuffer, what does it matter whether it is a
>> class or a struct? It is a type - you can declare objects of type
>> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
>> if it is a fundamental type like "int" or a standard library type or
>> your own type. It's just a type.
>
> Why do we have types then? Why not just create various interfaces and
> use a generic placeholder type ("var") which then accumulates abilities
> as needed based on what's observed to be required at compile-time?
>
I think you have misunderstood me (perhaps I was not clear). Types are
important. What you can /do/ with a type is important. Details of how
the type is implemented in the system are seldom as relevant. It
/certainly/ does not matter at all if a type is a class or a struct -
why should anyone using a type care if the default access mode is
private or public?
> Why formalize anything in something so rigid as a type? Why not make
> it a completely flexible ad hoc type?
Not all languages /do/ have something as rigid as types, and others have
a variety of ways of distinguishing types and their uses. C uses
nominative typing - a variable can be used as a given type if it /is/
that type, based on the declarations. In Python, you have duck typing -
you can use a variable in a given way if it has the appropriate fields
or methods. Other languages have different ideas. So it's fine to ask
those sorts of questions when you are considering a new language. For a
C-like language, having more rigid definitions is appropriate.
>
>> You need to know what you can /do/ with the type - what its methods are,
>> what operators are valid, and so on. Adding a "C" or "S" prefix tells
>> you absolutely nothing about that.
>
> It tells you that it's a class or struct and has members.
Again, so what? First, let us be clear that it matters not a jot
whether it is a struct or a class. I hope you will not argue that one.
(It is not unreasonable to suggest that it is useful for users to see if
a class is a "plain old data" type, or consists of nothing but publicly
accessible data members. But that is /not/ the difference between
"struct" and "class" in C++.)
Consider a class called WrappedInteger32 (designed to please Supercat).
Objects of this class can be freely converted back and forth from
normal int32_t variables, and it has operators for basic arithmetic,
conditionals, etc. It can be used wherever an int32_t is used, but
operator overloads are used to ensure that any time you have an
operation on two WrappedInteger32 types, the operations are done using
two's complement arithmetic with wrapping on overflow.
Ignoring the misuse of reserved identifiers, it would be reasonable to
call this class "wint32_t". People could use it just as they do an
int32_t. Knowing that it is a class, and not an alias for a standard
type, gives absolutely /zero/ useful information to the user.
There are classes that have no members (and even no fields or data) -
should /they/ be prefixed with C? Unions in C++ can have members -
should /they/ be prefixed with C? or U?
The ability to have members is just one feature of classes - there are
many more that might be of interest, and many of those features are
shared by other types too. A user wants to know how to /use/ a type,
not what sort of features the type /might/ have. It is helpful to know
which methods a type has - not that it has (or might have) methods.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-18 05:07 -0800 |
| Message-ID | <817adb1a-1599-4264-92ff-0ca70cf5c005@googlegroups.com> |
| In reply to | #102118 |
On Wednesday, January 18, 2017 at 7:36:36 AM UTC-5, David Brown wrote:
> On 18/01/17 00:44, Rick C. Hodgin wrote:
> > On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
> >> On 17/01/17 20:47, Rick C. Hodgin wrote:
> >>> On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
> >>>> On 01/18/17 04:04 AM, Rick C. Hodgin wrote:
> >>>>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote:
> >>>>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote:
> >>>>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote:
> >>>>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
> >>>>>>>>> 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.
> >>>>>>>
> >>>>>>> I was wondering why many C++ developers despise that naming convention.
> >>>>>>> To me it seems fundamental, such that it gives a cue on use as to exactly
> >>>>>>> what it is.
> >>>>>>
> >>>>>> The context should make it obvious what it is!
> >>>>>
> >>>>> I look to things like long-term maintenance. I may re-enter a software
> >>>>> project I haven't worked on actively in a year or more. I've slept
> >>>>> since that time and things that were once in my memory solidly may be
> >>>>> less so now.
> >>>>>
> >>>>> By keeping to a standard (in this case, the S or C prefixes, along with
> >>>>> other standards), it makes it clear at a glance what it is, without
> >>>>> having to divine from context.
> >>>>
> >>>> I'm currently working with a code base where the matrix class is
> >>>> "CMatrix". A matrix is a matrix, the fact that it is a class is
> >>>> irrelevant in the context in which it is used. In the context of C++,
> >>>> it can't be anything other than a class. If it walks like a duck and
> >>>> quacks like a duck, it's a duck.
> >>>
> >>> In that case a matrix is a matrix. But, how do you know it's a matrix
> >>> class and not a matrix array? You'd have to search for source code
> >>> which references it.
> >>>
> >>> And what about cases where the class or structure name is something
> >>> that's not a standard word?
> >>>
> >>> SExternalParams
> >>> CPixelBuffer
> >>>
> >>> What do those mean? Could be anything. And merely having something
> >>> like 'externalParams' or 'pixelBuffer' would not convey enough. I
> >>> also feel the same about just "matrix".
> >>
> >> If you have a type PixelBuffer, what does it matter whether it is a
> >> class or a struct? It is a type - you can declare objects of type
> >> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
> >> if it is a fundamental type like "int" or a standard library type or
> >> your own type. It's just a type.
> >
> > Why do we have types then? Why not just create various interfaces and
> > use a generic placeholder type ("var") which then accumulates abilities
> > as needed based on what's observed to be required at compile-time?
>
> I think you have misunderstood me (perhaps I was not clear). Types are
> important. What you can /do/ with a type is important. Details of how
> the type is implemented in the system are seldom as relevant. It
> /certainly/ does not matter at all if a type is a class or a struct -
> why should anyone using a type care if the default access mode is
> private or public?
I understood. I want to move to this model where everything is always
running, and is able to be changed while in flight. It's part of my
thinking in CAlive's development.
> > Why formalize anything in something so rigid as a type? Why not make
> > it a completely flexible ad hoc type?
>
> Not all languages /do/ have something as rigid as types ... For a
> C-like language, having more rigid definitions is appropriate.
I disagree. I think for a hardware implementation to operate like a
C-like compiler would generate it needs to have rigid definitions,
but I think the language itself does not need such a constraint. A
developer should be free to do whatever they choose, with the compiler
then determining how best to express that operation in hardware. It
could ultimately determine (through compilation and optimization) that
a particular rigid type is required, but until that time it's never
been specified. It's simply a variable that falls into the category
of use dictated by the source code.
> >> You need to know what you can /do/ with the type - what its methods are,
> >> what operators are valid, and so on. Adding a "C" or "S" prefix tells
> >> you absolutely nothing about that.
> >
> > It tells you that it's a class or struct and has members.
>
> Again, so what? First, let us be clear that it matters not a jot
> whether it is a struct or a class. I hope you will not argue that one.
It's a little different. All members of a struct are always public.
> Consider a class called WrappedInteger32 (designed to please Supercat).
> Objects of this class can be freely converted back and forth from
> normal int32_t variables, and it has operators for basic arithmetic,
> conditionals, etc. It can be used wherever an int32_t is used, but
> operator overloads are used to ensure that any time you have an
> operation on two WrappedInteger32 types, the operations are done using
> two's complement arithmetic with wrapping on overflow.
>
> Ignoring the misuse of reserved identifiers, it would be reasonable to
> call this class "wint32_t". People could use it just as they do an
> int32_t. Knowing that it is a class, and not an alias for a standard
> type, gives absolutely /zero/ useful information to the user.
I would prefer it be called CWrappedInteger32 as a published entity.
Any user acquiring that class and desiring a simpler type could then
include "#define wint32_t CWrappedInteger32" so they could use it
however they want.
> There are classes that have no members (and even no fields or data) -
> should /they/ be prefixed with C? Unions in C++ can have members -
> should /they/ be prefixed with C? or U?
I believe it should be S for structs, C for classes, U for (non-
anonymous) unions, E for enums, and _ALL_CAPS for constants. I also
believe internal functions should be prefixed with an i if they do
require NULL checking, and ii if they do not.
int iSomeFunction(char *p)
{
if (p)
{
// Valid code here
} else {
return(-1);
}
}
And if it's known that p has already been validated, then use the ii
form:
int iiSomeFunction(char *p)
{
// Valid code here
}
In CAlive I formalize this with the i {..} block. A function can be
named iiWhatever and include an i {..} block. It can then be called
using the iWhatever() or iiWhatever() forms.
int iiWhatever(char* p)
{
i {
if (!p)
return(-1);
}
// Valid code here
}
> The ability to have members is just one feature of classes - there are
> many more that might be of interest, and many of those features are
> shared by other types too. A user wants to know how to /use/ a type,
> not what sort of features the type /might/ have. It is helpful to know
> which methods a type has - not that it has (or might have) methods.
Well I think that statement is inconsistent with need. A developer
needs to know if a type has members, and then also what those members
are.
In CAlive I add the ability to document definitions in various ways
for this purpose. I call the functionality "SourceLight."
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 16:09 +0100 |
| Message-ID | <o5o0ce$bpc$1@dont-email.me> |
| In reply to | #102122 |
On 18/01/17 14:07, Rick C. Hodgin wrote:
> On Wednesday, January 18, 2017 at 7:36:36 AM UTC-5, David Brown wrote:
>> On 18/01/17 00:44, Rick C. Hodgin wrote:
>>> On Tuesday, January 17, 2017 at 4:16:56 PM UTC-5, David Brown wrote:
>>>> On 17/01/17 20:47, Rick C. Hodgin wrote:
>>>>> On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote:
<snip>
>>>> If you have a type PixelBuffer, what does it matter whether it is a
>>>> class or a struct? It is a type - you can declare objects of type
>>>> PixelBuffer, you can return PixelBuffer's, and so on. It doesn't matter
>>>> if it is a fundamental type like "int" or a standard library type or
>>>> your own type. It's just a type.
>>>
>>> Why do we have types then? Why not just create various interfaces and
>>> use a generic placeholder type ("var") which then accumulates abilities
>>> as needed based on what's observed to be required at compile-time?
>>
>> I think you have misunderstood me (perhaps I was not clear). Types are
>> important. What you can /do/ with a type is important. Details of how
>> the type is implemented in the system are seldom as relevant. It
>> /certainly/ does not matter at all if a type is a class or a struct -
>> why should anyone using a type care if the default access mode is
>> private or public?
>
> I understood. I want to move to this model where everything is always
> running, and is able to be changed while in flight. It's part of my
> thinking in CAlive's development.
>
>>> Why formalize anything in something so rigid as a type? Why not make
>>> it a completely flexible ad hoc type?
>>
>> Not all languages /do/ have something as rigid as types ... For a
>> C-like language, having more rigid definitions is appropriate.
>
> I disagree. I think for a hardware implementation to operate like a
> C-like compiler would generate it needs to have rigid definitions,
> but I think the language itself does not need such a constraint. A
> developer should be free to do whatever they choose, with the compiler
> then determining how best to express that operation in hardware. It
> could ultimately determine (through compilation and optimization) that
> a particular rigid type is required, but until that time it's never
> been specified. It's simply a variable that falls into the category
> of use dictated by the source code.
I agree that the compiler should be free to use any implementation it
wants, using the "as-if" rule. But I would say that having a more
flexible typing system means it is even /less/ meaningful to use
prefixes for some kinds of types, because the distinction between them
is even less relevant than in C or C++.
>
>>>> You need to know what you can /do/ with the type - what its methods are,
>>>> what operators are valid, and so on. Adding a "C" or "S" prefix tells
>>>> you absolutely nothing about that.
>>>
>>> It tells you that it's a class or struct and has members.
>>
>> Again, so what? First, let us be clear that it matters not a jot
>> whether it is a struct or a class. I hope you will not argue that one.
>
> It's a little different. All members of a struct are always public.
Not in C++ (and we can't be talking about C, since C has no classes).
In C++, there is no difference between:
class A { public: xxx };
and
struct A { xxx };
nor any difference between:
class A { xxx };
and
struct A { private: xxx };
The /only/ difference between "class" and "struct" (in this context) is
that the default access mode for a "struct" declaration is public, while
the default access mode for a "class" is private. Make the access modes
explicit and the difference is gone. Structs can have private and
protected members just like classes, and it can have methods as well as
data members, friends, overloads, etc.
It is a common convention to use "struct" only when dealing with C-like
structures and "class" for anything more advanced (methods, non-public
access, overloads, etc.). But that is merely a convention - not a part
of the language.
>
>> Consider a class called WrappedInteger32 (designed to please Supercat).
>> Objects of this class can be freely converted back and forth from
>> normal int32_t variables, and it has operators for basic arithmetic,
>> conditionals, etc. It can be used wherever an int32_t is used, but
>> operator overloads are used to ensure that any time you have an
>> operation on two WrappedInteger32 types, the operations are done using
>> two's complement arithmetic with wrapping on overflow.
>>
>> Ignoring the misuse of reserved identifiers, it would be reasonable to
>> call this class "wint32_t". People could use it just as they do an
>> int32_t. Knowing that it is a class, and not an alias for a standard
>> type, gives absolutely /zero/ useful information to the user.
>
> I would prefer it be called CWrappedInteger32 as a published entity.
> Any user acquiring that class and desiring a simpler type could then
> include "#define wint32_t CWrappedInteger32" so they could use it
> however they want.
I would much prefer not to have or encourage #define's, or additional
names for the same thing.
But okay, it's fine that you /prefer/ this. I was just wondering if
there are technical reasons for it or some way you can justify the
prefix as adding useful information. Apparently not, but that's okay.
>
>> There are classes that have no members (and even no fields or data) -
>> should /they/ be prefixed with C? Unions in C++ can have members -
>> should /they/ be prefixed with C? or U?
>
> I believe it should be S for structs, C for classes, U for (non-
> anonymous) unions, E for enums, and _ALL_CAPS for constants. I also
> believe internal functions should be prefixed with an i if they do
> require NULL checking, and ii if they do not.
IMHO, that is getting /really/ ugly /really/ quickly. But that's my
opinion - you are free to have yours.
>
> int iSomeFunction(char *p)
> {
> if (p)
> {
> // Valid code here
> } else {
> return(-1);
> }
> }
>
> And if it's known that p has already been validated, then use the ii
> form:
>
> int iiSomeFunction(char *p)
> {
> // Valid code here
> }
What about when you have two parameters, one of which may be null? What
about checking or validation other than for NULL pointers?
For a new language, consider copying references from C++ - then you have
a way to specify non-NULL in the language rather than with a letter in
the function name. Also consider attributes, or some other method of
marking and checking such things in the language.
>
> In CAlive I formalize this with the i {..} block. A function can be
> named iiWhatever and include an i {..} block. It can then be called
> using the iWhatever() or iiWhatever() forms.
>
> int iiWhatever(char* p)
> {
> i {
> if (!p)
> return(-1);
> }
> // Valid code here
> }
>
I cannot fathom why you might consider that to be a useful idea, but
it's your language - I won't be using it, so you don't have to explain
it to me.
>> The ability to have members is just one feature of classes - there are
>> many more that might be of interest, and many of those features are
>> shared by other types too. A user wants to know how to /use/ a type,
>> not what sort of features the type /might/ have. It is helpful to know
>> which methods a type has - not that it has (or might have) methods.
>
> Well I think that statement is inconsistent with need. A developer
> needs to know if a type has members, and then also what those members
> are.
The point is that knowing that a type /has/ members, without knowing
what those members are, is useless information. And if the developer
knows what the methods are, he/she already knows that the type has members.
>
> In CAlive I add the ability to document definitions in various ways
> for this purpose. I call the functionality "SourceLight."
>
> Thank you,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-18 07:36 -0800 |
| Message-ID | <1131bbe2-6277-4794-9293-47c4df74b49b@googlegroups.com> |
| In reply to | #102125 |
On Wednesday, January 18, 2017 at 10:09:43 AM UTC-5, David Brown wrote:
> On 18/01/17 14:07, Rick C. Hodgin wrote:
> > On Wednesday, January 18, 2017 at 7:36:36 AM UTC-5, David Brown wrote:
> >> Again, so what? First, let us be clear that it matters not a jot
> >> whether it is a struct or a class. I hope you will not argue that one.
> >
> > It's a little different. All members of a struct are always public.
>
> [snip]
>
> The /only/ difference between "class" and "struct" (in this context) is
> that the default access mode for a "struct" declaration is public, while
> the default access mode for a "class" is private.
I was not aware that struct allowed the access mode to be changed. I
thought it was always public in all cases. My ignorance.
> > I would prefer it be called CWrappedInteger32 as a published entity.
> > Any user acquiring that class and desiring a simpler type could then
> > include "#define wint32_t CWrappedInteger32" so they could use it
> > however they want.
>
> I would much prefer not to have or encourage #define's, or additional
> names for the same thing.
>
> But okay, it's fine that you /prefer/ this. I was just wondering if
> there are technical reasons for it or some way you can justify the
> prefix as adding useful information. Apparently not, but that's okay.
I think it does provide useful information. It tells me at a glance
that it's a class. I'll then know it has members which may go beyond
basic operator definitions and into more interesting things like a
round() or int() function.
> > int iSomeFunction(char *p)
> > {
> > if (p)
> > {
> > // Valid code here
> > } else {
> > return(-1);
> > }
> > }
> >
> > And if it's known that p has already been validated, then use the ii
> > form:
> >
> > int iiSomeFunction(char *p)
> > {
> > // Valid code here
> > }
>
> What about when you have two parameters, one of which may be null? What
> about checking or validation other than for NULL pointers?
As a general rule, the i definition is for when anything needs to be
checked. The ii definition is for when nothing needs to be checked.
And, of course, in the case of explicit contexts where input into the
ii function is coming from an external source, but all other params
are known to be valid, you may still check the data you're processing.
And, these are just conventions. In the i usage, the i {..} block is
traversed. In the ii usage, the i {..} block is skipped.
> The point is that knowing that a type /has/ members, without knowing
> what those members are, is useless information. And if the developer
> knows what the methods are, he/she already knows that the type has members.
I prefer a developer to know that by whether or not the type is prefixed
with a C (or possibly S, though I see no reason to use structs for any
purpose other than raw data storage ... if you need the class abilities
then use a class, not a struct).
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 17:32 +0100 |
| Message-ID | <o5o58b$c2$1@dont-email.me> |
| In reply to | #102127 |
On 18/01/17 16:36, Rick C. Hodgin wrote: > On Wednesday, January 18, 2017 at 10:09:43 AM UTC-5, David Brown wrote: >> On 18/01/17 14:07, Rick C. Hodgin wrote: >>> On Wednesday, January 18, 2017 at 7:36:36 AM UTC-5, David Brown wrote: >>>> Again, so what? First, let us be clear that it matters not a jot >>>> whether it is a struct or a class. I hope you will not argue that one. >>> >>> It's a little different. All members of a struct are always public. >> >> [snip] >> >> The /only/ difference between "class" and "struct" (in this context) is >> that the default access mode for a "struct" declaration is public, while >> the default access mode for a "class" is private. > > I was not aware that struct allowed the access mode to be changed. I > thought it was always public in all cases. My ignorance. > That explains it. C++ is a big language - there is always something new to learn. Restricting "struct" to public access is common, but it is not universal. You might find it helpful to use an online reference. I get a lot of useful information from <http://en.cppreference.com/>. You could always read the C++ standards - the drafts are freely available. They are even better than the C standards if you have trouble sleeping in your uncomfortable office chair :-)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 17:55 +1300 |
| Message-ID | <ee8apuF2vaqU2@mid.individual.net> |
| In reply to | #102067 |
On 01/18/17 08:47 AM, Rick C. Hodgin wrote: > On Tuesday, January 17, 2017 at 2:02:07 PM UTC-5, Ian Collins wrote: >> On 01/18/17 04:04 AM, Rick C. Hodgin wrote: >>> On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote: >>>> On 01/17/17 09:19 AM, Rick C. Hodgin wrote: >>>>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote: >>>>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote: >>>>>>> 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. >>>>> >>>>> I was wondering why many C++ developers despise that naming convention. >>>>> To me it seems fundamental, such that it gives a cue on use as to exactly >>>>> what it is. >>>> >>>> The context should make it obvious what it is! >>> >>> I look to things like long-term maintenance. I may re-enter a software >>> project I haven't worked on actively in a year or more. I've slept >>> since that time and things that were once in my memory solidly may be >>> less so now. >>> >>> By keeping to a standard (in this case, the S or C prefixes, along with >>> other standards), it makes it clear at a glance what it is, without >>> having to divine from context. >> >> I'm currently working with a code base where the matrix class is >> "CMatrix". A matrix is a matrix, the fact that it is a class is >> irrelevant in the context in which it is used. In the context of C++, >> it can't be anything other than a class. If it walks like a duck and >> quacks like a duck, it's a duck. > > In that case a matrix is a matrix. But, how do you know it's a matrix > class and not a matrix array? You'd have to search for source code > which references it. An array doesn't have operators or methods. > And what about cases where the class or structure name is something > that's not a standard word? > > SExternalParams > CPixelBuffer > > What do those mean? Could be anything. And merely having something > like 'externalParams' or 'pixelBuffer' would not convey enough. I > also feel the same about just "matrix". So use a cleaner style such as capitalised names for types, so it then becomes clear with Matrix matrix; that matrix is an instance of a Matrix object. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-19 22:28 -0800 |
| Message-ID | <o5saju$oss$1@dont-email.me> |
| In reply to | #102048 |
On 1/17/2017 7:04 AM, Rick C. Hodgin wrote: > On Tuesday, January 17, 2017 at 2:57:38 AM UTC-5, Ian Collins wrote: >> On 01/17/17 09:19 AM, Rick C. Hodgin wrote: >>> On Friday, January 13, 2017 at 1:31:02 AM UTC-5, Ian Collins wrote: >>>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote: >>>>> 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. >>> >>> I was wondering why many C++ developers despise that naming convention. >>> To me it seems fundamental, such that it gives a cue on use as to exactly >>> what it is. >> >> The context should make it obvious what it is! > > I look to things like long-term maintenance. I may re-enter a software > project I haven't worked on actively in a year or more. I've slept > since that time and things that were once in my memory solidly may be > less so now. > > By keeping to a standard (in this case, the S or C prefixes, along with > other standards), it makes it clear at a glance what it is, without > having to divine from context. > > Just my opinion. > > For CAlive Is it C alive, or class Alive? > I also take this a step further and plan to introduce GUI > color cues which identify what things are so there will be less need > for names. But even with the presence of name prefixes, like "lcXyz" > for a local variable char, or "tcXyz" for a parameter char, those > prefixes can also be removed so the value shows up as "xyz" in the > editor, while retaining its full name in the source code. > > Things to help human beings is what I am in pursuit of. We all have > basic abilities, and where the machine can do a little extra work to > meet us where we are ... that's what I want for my machine to do for > me.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-20 08:36 +0000 |
| Message-ID | <o5si3t$dgq$2@dont-email.me> |
| In reply to | #102203 |
On 20/01/17 06:28, Chris M. Thomasson wrote: > On 1/17/2017 7:04 AM, Rick C. Hodgin wrote: <snip> >> >> For CAlive > > Is it C alive, or class Alive? I'm sure the documentation will make this clear when you install the package. -- 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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-20 04:27 -0800 |
| Message-ID | <2016b6ae-eb97-467c-98e0-51949c8e9ab7@googlegroups.com> |
| In reply to | #102203 |
Chris M. Thomasson writeth: > Is it C alive, or class Alive? It's spelled "CAlive," but it's pronounced, "Throat Warbler Mangrove." Actually, CAlive includes the basic class, which is shown in its name. Clever, yes? Well not really. It's just an interesting co-inkydink. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-01-12 12:01 -0800 |
| Message-ID | <316df0b2-5692-4eff-8ec7-41ad9ff08d17@googlegroups.com> |
| In reply to | #101543 |
On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, 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.
>
> Thanks.-
The trailing _t is actually reserved for the implementation,
so I see (and use) a prefix like 's_' or 't_' instead more
often.
Establishing a convention for naming things in your code is
very very good. Make sure it's something you can type easily.
For my own code, I avoid extra decorations like this as much
as possible mostly because I have to shift to type '_'.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-12 20:11 +0000 |
| Message-ID | <o58nqd$9p0$1@dont-email.me> |
| In reply to | #101546 |
On 12/01/17 20:01, luser droog wrote: <snip> > > The trailing _t is actually reserved for the implementation, Certainly true for int*_t and uint*_t, but do you have a citation for the more general claim? -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-12 12:50 -0800 |
| Message-ID | <lnfukongsz.fsf@kst-u.example.com> |
| In reply to | #101549 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
>>
>> The trailing _t is actually reserved for the implementation,
>
> Certainly true for int*_t and uint*_t, but do you have a citation for
> the more general claim?
I think it's a POSIX rule.
--
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 | 2017-01-12 21:02 +0000 |
| Message-ID | <o58qq2$kr6$1@dont-email.me> |
| In reply to | #101551 |
On 12/01/17 20:50, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 12/01/17 20:01, luser droog wrote: >> <snip> >>> >>> The trailing _t is actually reserved for the implementation, >> >> Certainly true for int*_t and uint*_t, but do you have a citation for >> the more general claim? > > I think it's a POSIX rule. So do I, but I can't find any reference to it in the POSIX Standard. That, of course, is not a matter for this group. It seems to me, though, that luser_droog was claiming it was a C rule, and it was that claim (if I have understood him correctly) for which I was seeking a citation. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-12 13:26 -0800 |
| Message-ID | <ln37gonf59.fsf@kst-u.example.com> |
| In reply to | #101553 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/01/17 20:50, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 12/01/17 20:01, luser droog wrote:
>>> <snip>
>>>>
>>>> The trailing _t is actually reserved for the implementation,
>>>
>>> Certainly true for int*_t and uint*_t, but do you have a citation for
>>> the more general claim?
>>
>> I think it's a POSIX rule.
>
> So do I, but I can't find any reference to it in the POSIX Standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
Search for the phrase "ANY header" at the bottom of the table in section
2.2.2.
[...]
--
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]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web