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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-01-14 13:26 +0000 |
| Message-ID | <87bmv9pybl.fsf@gmail.com> |
| In reply to | #101734 |
BartC <bc@freeuk.com> writes: >>Just writing a simple C++ hello world program >> and then doing >> >> CC helloWorld.cc > >>will be linking C and C++ libraries. ... it just works. > > Obviously it didn't. He said CC. You typed cc. Do you see the difference? CC is a common name for a C++ compiler. (Not on your system, though) cc is a common name for a C compiler. (Including your system). Do you see the difference? You assumed that he meant cc, and then told him he was wrong. > I tried it out because I was puzzled by the use of the .cc extension, > and was wondering why he would use what looks like a C compiler (even > I can vaguely recall cc from Unix) But not CC, evidently. That you assumed they were the same is you problem, not his. As I said, your problem was not knowing that CC is a C++ compiler. > on what he said was C++ code. So, guess what tool he used to build it. Clue - not cc, the C compiler. > And even if somehow CC had worked and managed to produce an > executable, I still don't see how this is linking a C library, as the > program makes use of std::cout. Because the startup code will be a C library, and that will be linked too. Because Unix kernels us the C-library-entry-point to start code.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-15 08:10 +1300 |
| Message-ID | <edvbdcFbp8vU1@mid.individual.net> |
| In reply to | #101734 |
On 01/15/17 12:48 AM, BartC wrote: > On 14/01/2017 11:28, Gareth Owen wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 13/01/2017 22:18, Ian Collins wrote: >> >> On 01/14/17 11:00 AM, BartC wrote: >>> >>> $ cc hello.cc >>> What is CC or cc? I don't even know. But if I try: >>> >>> g++ hello.cc >>> >>> I'm sorry, but things *do* go wrong, even if you clearly don't believe me. >> >> Really??? >> Your complaint is "If I want my C++ code to link I have to know the name >> of my C++ compiler and call it"? Why not point out that >> >> python hello.cc >> >> doesn't work either? >> >> Even by your standards, that's embarrassing. >> > Ian said this: > > >Just writing a simple C++ hello world program > > and then doing > > > > CC helloWorld.cc > > >will be linking C and C++ libraries. ... it just works. > > Obviously it didn't. It does on my system... > I tried it out because I was puzzled by the use of the .cc extension, > and was wondering why he would use what looks like a C compiler (even I > can vaguely recall cc from Unix) on what he said was C++ code. I assumed a basic level of intelligence and knowledge of the tools on your system. I see now I overestimated both. > And even if somehow CC had worked and managed to produce an executable, > I still don't see how this is linking a C library, as the program makes > use of std::cout. How do you think the output gets delivered to the console? > In short, there were half a dozen points of confusion in about as many > lines, and people are making out that it's /me/ talking bollocks! There is only one - your ignorance of your tools. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-14 12:28 -0800 |
| Message-ID | <49e34b68-2bc2-46fd-a349-c6ffe46d559a@googlegroups.com> |
| In reply to | #101792 |
On Saturday, January 14, 2017 at 7:10:44 PM UTC, Ian Collins wrote: > On 01/15/17 12:48 AM, BartC wrote: > > > In short, there were half a dozen points of confusion in about as many > > lines, and people are making out that it's /me/ talking bollocks! > > There is only one - your ignorance of your tools. > One of the characteristics of software engineering is that you can be professor or, as I am, a doctor with a doctorate in a computational subject. You're presented with a new system, and you don't know how to log on. Other fields tend not to have that problem. Either there are conventions long established, such as how to make air traffic control ware of your intention to land, and so on, or it's physically intuitive - the# throttle might work in a slightly different way on another model of aircraft, but it's still obvious that it's a throttle. Software has conventions which are not established, and no real way of examining the software to see which are in use. It's made much worse by thing such as the proliferation of languages and libraries, many of which do much the same sort of thing, just with slightly different syntax for for loops because someone thought it would be nice to have a "ranged for" and so on. You can learn the conventions for a small subset of the software you happen to use, that then sometimes gives people feelings of superiority - I remember as young man being told how to set the number of lines in the cursor on DOS by a friend. He smiled proudly and said that was the result of years of knowledge. I didn't disabuse him.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-15 10:17 +1300 |
| Message-ID | <edvirgFbp90U3@mid.individual.net> |
| In reply to | #101802 |
On 01/15/17 09:28 AM, Malcolm McLean wrote: > On Saturday, January 14, 2017 at 7:10:44 PM UTC, Ian Collins wrote: >> On 01/15/17 12:48 AM, BartC wrote: >> >>> In short, there were half a dozen points of confusion in about as many >>> lines, and people are making out that it's /me/ talking bollocks! >> >> There is only one - your ignorance of your tools. >> > One of the characteristics of software engineering is that you can > be professor or, as I am, a doctor with a doctorate in a computational > subject. You're presented with a new system, and you don't know > how to log on. So you ask. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 15:12 -0800 |
| Message-ID | <d74abda5-68bd-4038-bf1f-d5c339e66233@googlegroups.com> |
| In reply to | #101673 |
On Friday, January 13, 2017 at 10:00:48 PM UTC, Bart wrote: > 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. > Exactly. The program consists of both C and C++ files, both of which need to be compiled and linked. Firstly you've got to specify C linkage, which you wouldn't necessarily know unless someone had told you. Then as I said,a few weeks ago I got an error claiming the math library functions had been multiply defined. The C code in question wasn't mine, and I actually resolved the issue by changing the file extension to C++ and compiling as C++. Doubtless with more fiddling I would have found the underlying reason, but it's not a good use of my time. It helps if you either always use the same set up, or if you've got someone whose job it is to configure programs so that they work. But for many people, these don't apply. It's very easy to underestimate the costs of using a library, however.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-14 12:31 +1300 |
| Message-ID | <edt6adF4adeU5@mid.individual.net> |
| In reply to | #101680 |
On 01/14/17 12:12 PM, Malcolm McLean wrote: > On Friday, January 13, 2017 at 10:00:48 PM UTC, Bart wrote: >> 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. >> > Exactly. Exactly what? > The program consists of both C and C++ files, both of which need to be > compiled and linked. Firstly you've got to specify C linkage, which > you wouldn't necessarily know unless someone had told you. Only if you want C++ functions to link to C. If a C++ programmer didn't know about linkage, he/she shouldn't be programming. > Then as > I said,a few weeks ago I got an error claiming the math library > functions had been multiply defined. The C code in question wasn't > mine, and I actually resolved the issue by changing the file extension > to C++ and compiling as C++. Doubtless with more fiddling I would have > found the underlying reason, but it's not a good use of my time. So there was an issue with some third party C code, nothing to do with C++. > It helps if you either always use the same set up, or if you've got > someone whose job it is to configure programs so that they work. Anyone form a summer student up should be able to manage that. > But for many people, these don't apply. It's very easy to underestimate > the costs of using a library, however. It's even easier to underestimate the costs of reimplementing a library -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 16:03 -0800 |
| Message-ID | <5790d14a-ce12-4623-8f10-a3c94c684b2f@googlegroups.com> |
| In reply to | #101682 |
On Friday, January 13, 2017 at 11:31:32 PM UTC, Ian Collins wrote: > On 01/14/17 12:12 PM, Malcolm McLean wrote: > > > But for many people, these don't apply. It's very easy to underestimate > > the costs of using a library, however. > > It's even easier to underestimate the costs of reimplementing a library > Depends what the library is doing and who you have. Some functions you have the skills to implement very quickly and easily, others you don't. I'm currently in two minds about Open CV - if I was doing full on image recognition then I'd use it, but I'm not, I only want a few lines and corners and other features.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-13 15:57 -0800 |
| Message-ID | <o5bpdd$l1e$1@dont-email.me> |
| In reply to | #101643 |
On 1/13/2017 10:43 AM, 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. 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. True. IMHO, these are some good points you raise Malcolm. > 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. Well, I remember accidentally compiling a C library with a C++ compiler, and thought this thing is totally screwed! Found the problem a couple of minutes later, recompiled and BAM! Everything worked, compiled, and rendered a correct image after 103 minutes or so. I was in a state of panic when I thought that the compilation was correct in its list of errors. Then, a C compiler rescued me. And by the way, the code was never meant to be C++.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-14 13:29 -0800 |
| Message-ID | <o5e54v$e5f$1@dont-email.me> |
| In reply to | #101691 |
On 1/13/2017 3:57 PM, Chris M. Thomasson wrote: > On 1/13/2017 10:43 AM, 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. just make sure that the std:: evaporates into thin air before you use it in a C compiler, wrt freely exchanging C and C++ free-functions. [...]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-14 10:45 +1300 |
| Message-ID | <edt030F4adeU1@mid.individual.net> |
| In reply to | #101604 |
On 01/14/17 02:00 AM, Richard Heathfield wrote: > 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? In general, no it isn't a good idea. If you have a C++ compiler, you may as well use C++... > 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++? The times where I have (as I've mentioned here before) is where I have been using some form of simulation for devices that requires C++. The compromise there was not using code that has different meanings in C and C++. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-16 12:19 -0800 |
| Message-ID | <bf37cf2d-81da-4125-b4e1-1d8e80f37baa@googlegroups.com> |
| In reply to | #101580 |
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. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-16 15:22 -0800 |
| Message-ID | <o5jkgu$pj8$1@dont-email.me> |
| In reply to | #102002 |
On 1/16/2017 12:19 PM, 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. COkay... COkay.COK() lol. struct? ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-16 16:35 -0800 |
| Message-ID | <a62aeccd-01a6-4b24-aa28-6dc893ea5142@googlegroups.com> |
| In reply to | #102009 |
On Monday, January 16, 2017 at 6:22:44 PM UTC-5, Chris M. Thomasson wrote: > On 1/16/2017 12:19 PM, 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. > > COkay... COkay.COK() lol. struct? ;^) In C++, using COkay would indicate a type when referenced. It would indicate it's a class. As Fernando indicated, that type of information is preferred within the name by many developers. I would prefer to see CName and SName for classes and structs in the type definition and/or type reference. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-17 17:02 -0800 |
| Message-ID | <o5meof$3rg$1@dont-email.me> |
| In reply to | #102016 |
On 1/16/2017 4:35 PM, Rick C. Hodgin wrote: > On Monday, January 16, 2017 at 6:22:44 PM UTC-5, Chris M. Thomasson wrote: >> On 1/16/2017 12:19 PM, 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. >> >> COkay... COkay.COK() lol. struct? ;^) > > In C++, using COkay would indicate a type when referenced. It would > indicate it's a class. [...] struct okay is a struct. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-17 20:57 +1300 |
| Message-ID | <ee6139Ft7v7U1@mid.individual.net> |
| In reply to | #102002 |
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! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-17 08:47 +0000 |
| Message-ID | <o5klj7$k2d$1@dont-email.me> |
| In reply to | #102024 |
On 17/01/17 07:57, 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 learned to avoid them when I discovered that you couldn't have a CList of CLists. Did they ever fix that? -- 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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 08:03 +1300 |
| Message-ID | <ee783aF2tftU3@mid.individual.net> |
| In reply to | #102030 |
On 01/17/17 09:47 PM, Richard Heathfield wrote: > On 17/01/17 07:57, 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 learned to avoid them when I discovered that you couldn't have a CList > of CLists. Did they ever fix that? In MFC? No idea, I've managed to avoid it! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-17 07:04 -0800 |
| Message-ID | <e1e67678-a17a-44df-ae66-fca6fd13ce2f@googlegroups.com> |
| In reply to | #102024 |
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 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. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 08:01 +1300 |
| Message-ID | <ee7811F2tftU2@mid.individual.net> |
| In reply to | #102048 |
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. 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. > 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. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-01-17 11:47 -0800 |
| Message-ID | <b9fdf825-fc83-44e9-9e94-17a9e1ba24cc@googlegroups.com> |
| In reply to | #102063 |
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".
> 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]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web