Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101543 > unrolled thread

Naming convention for structs and types

Back to article view | Back to comp.lang.c

Contents

  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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10  Next page →

#101770

On 14/01/17 15:00, BartC wrote:
> On 14/01/2017 13:27, Gareth Owen wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>>> 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!
>>>>
>>>
>>> The confusion is only in your mind - because you work so hard to
>>> create it.
>>
>> I no longer think he's working hard to create it.  I think his state of
>> perpetual bafflement comes to him naturally.
>
> I used to do a lot of customer support. I know the sort of things people
> have difficulty with, and used to write user and reference manuals with
> that in mind.
>
> Now, in all the years I've been frequenting this group, I don't recall
> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
> every other post.

CC for the C++ compiler is definitely a unixism.  It is not unreasonable 
that you don't know it if you are not familiar with Unix, and if you are 
a DOS/Windows user you might even still believe that "cc" and "CC" would 
refer to the same program.

Not knowing the command name for your own C++ compiler is, however, 
ridiculous.

>
> Nor have I have ever comes across the file extension '.cc'.

I am sure you would have found that with the first hit on a google 
search for "file extension .cc".  You might also find the Wikipedia page 
for C++ a good introduction.  Among other things, it tells you that 
".cc" is a common file extension for C++ files.

>
> This is exactly the sort of thing I would have added notes about if I
> was doing the posting.

I believe Ian assumed the readers had at least basic familiarity with 
C++, C++ files, and C++ compilers.

>
> (Nice touch BTW of having .cc meaning a C++ source file, and cc meaning
> a C compiler. You don't want to make this stuff too obvious!)
>

[toc] | [prev] | [next] | [standalone]

#101778

On 14/01/2017 15:18, David Brown wrote:
> On 14/01/17 15:00, BartC wrote:
>> On 14/01/2017 13:27, Gareth Owen wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>>> 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!
>>>>>
>>>>
>>>> The confusion is only in your mind - because you work so hard to
>>>> create it.
>>>
>>> I no longer think he's working hard to create it.  I think his state of
>>> perpetual bafflement comes to him naturally.
>>
>> I used to do a lot of customer support. I know the sort of things people
>> have difficulty with, and used to write user and reference manuals with
>> that in mind.
>>
>> Now, in all the years I've been frequenting this group, I don't recall
>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>> every other post.
>
> CC for the C++ compiler is definitely a unixism.  It is not unreasonable
> that you don't know it if you are not familiar with Unix, and if you are
> a DOS/Windows user you might even still believe that "cc" and "CC" would
> refer to the same program.

It just seems perverse. How would you say 'cc' or 'CC' over the phone 
when instructing someone what to type?

>
> Not knowing the command name for your own C++ compiler is, however,
> ridiculous.

Where did you get that idea? I said I resorted 'g++' when cc and CC 
didn't work.

But Linux seems confused about it itself; typing man cc, man CC or man 
gcc or man g++ all bring up the same page:

   gcc - GNU project C and C++ compiler

Which suggests that gcc does both. However it appears that gcc and g++ 
can't be used interchangeably, despite the man page saying that invoking 
gcc on a file with a C++ extension (eg. .cc) will compile it as g++. 
(And invoking g++ on a .c file doesn't seem to work with my C programs 
either.)

(BTW the man info for gcc is about 350 pages!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101789

BartC <bc@freeuk.com> writes:

> It just seems perverse. How would you say 'cc' or 'CC' over the phone
> when instructing someone what to type?

"type see see - just the letter 'see' twice in lowercase"
"type capital see, capital see"

I honestly can't believe I answered that question, since you were
clearly trying to make a rhetorical point.

Worth pointing out what a freaking terrible rhetorical point it was.

I am now kill-filing you, as you are clearly dimmer than a Toc-H lamp.

[toc] | [prev] | [next] | [standalone]

#101795

On 14/01/2017 18:50, Gareth Owen wrote:
> BartC <bc@freeuk.com> writes:
>
>> It just seems perverse. How would you say 'cc' or 'CC' over the phone
>> when instructing someone what to type?
>
> "type see see - just the letter 'see' twice in lowercase"
> "type capital see, capital see"

But why such a cause of confusion in the first place?

You ask someone to read back what they typed - 'see see' - 'is that 
upper case see see, or lower case see see'?

It's a source of confusion.

And an unbelievable lack of imagination: Let's see, our C compiler is 
called 'cc' (in lower case); what can we possible call the C++ one? I 
know, how about calling it exactly the same as the C compiler, but in 
upper case?'!

Which also mean a lot of capslocking on and off everytime you have to 
type CC program.cc!

Actually I really don't care, if Linux/Unix people want to do these 
ridiculous things. And if they're paid by the hour, then one can 
understand why they want the slowest tools, most complicated and 
fiddliest tools they can find!

> I honestly can't believe I answered that question, since you were
> clearly trying to make a rhetorical point.
>
> Worth pointing out what a freaking terrible rhetorical point it was.
>
> I am now kill-filing you, as you are clearly dimmer than a Toc-H lamp.

Thank god for that. But you do seem to mainly come on here to have a go 
at people. Without me, who's left, fir, Malcolm or Rick?


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101804

On 01/15/17 08:48 AM, BartC wrote:
> On 14/01/2017 18:50, Gareth Owen wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> It just seems perverse. How would you say 'cc' or 'CC' over the phone
>>> when instructing someone what to type?
>>
>> "type see see - just the letter 'see' twice in lowercase"
>> "type capital see, capital see"
>
> But why such a cause of confusion in the first place?
>
> You ask someone to read back what they typed - 'see see' - 'is that
> upper case see see, or lower case see see'?
>
> It's a source of confusion.

For the simple minded, maybe.

I suppose you fine cl.exe a more intuitive name?

CC has been the Solaris C++ compiler since it was still SunOS.
-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101799

Gareth Owen <gwowen@gmail.com> writes:
<snip>
> ... you are clearly dimmer than a Toc-H lamp.

I haven't heard that phrase for years!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101817

On 14/01/17 17:31, BartC wrote:
> On 14/01/2017 15:18, David Brown wrote:
>> On 14/01/17 15:00, BartC wrote:
>>> On 14/01/2017 13:27, Gareth Owen wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>>> 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!
>>>>>>
>>>>>
>>>>> The confusion is only in your mind - because you work so hard to
>>>>> create it.
>>>>
>>>> I no longer think he's working hard to create it.  I think his state of
>>>> perpetual bafflement comes to him naturally.
>>>
>>> I used to do a lot of customer support. I know the sort of things people
>>> have difficulty with, and used to write user and reference manuals with
>>> that in mind.
>>>
>>> Now, in all the years I've been frequenting this group, I don't recall
>>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>>> every other post.
>>
>> CC for the C++ compiler is definitely a unixism.  It is not unreasonable
>> that you don't know it if you are not familiar with Unix, and if you are
>> a DOS/Windows user you might even still believe that "cc" and "CC" would
>> refer to the same program.
>
> It just seems perverse. How would you say 'cc' or 'CC' over the phone
> when instructing someone what to type?

"cc in small letters" or "CC in capital letters" ?  Or type it in the 
chat window in Skype?  Send it by email?  I don't know - phones are such 
extraordinarily poor ways to communicate such things that I would use 
one of a range of alternatives.  But if I /had/ to use a phone, I can't 
imagine that would be a serious problem.

>
>>
>> Not knowing the command name for your own C++ compiler is, however,
>> ridiculous.
>
> Where did you get that idea? I said I resorted 'g++' when cc and CC
> didn't work.

So you knew how to run your C++ compiler, but instead you copied Ian's 
comment about how /he/ runs /his/ C++ compiler, and then complained it 
didn't work?

>
> But Linux seems confused about it itself; typing man cc, man CC or man
> gcc or man g++ all bring up the same page:
>
>   gcc - GNU project C and C++ compiler
>
> Which suggests that gcc does both. However it appears that gcc and g++
> can't be used interchangeably, despite the man page saying that invoking
> gcc on a file with a C++ extension (eg. .cc) will compile it as g++.
> (And invoking g++ on a .c file doesn't seem to work with my C programs
> either.)
>
> (BTW the man info for gcc is about 350 pages!)
>

gcc is the "GNU compiler collection" - it is not just a C compiler.  The 
package includes support for a number of languages, including C and C++. 
  The binary "gcc" is a /driver/ - it is not the compiler itself.  It 
calls the appropriate pre-processor, then the appropriate compiler, and 
then the linker - all depending on the flags and files passed to it. 
The compiler to use is chosen based on the file extension - .c files get 
the C compiler, .cc and .cpp files get the the C++ compiler, etc.  If it 
is called with the name "g++", the C++ and C libraries are linked in 
automatically.  If it is called with the name "gcc", the C libraries 
alone are linked in automatically.

[toc] | [prev] | [next] | [standalone]

#101786

On Saturday, January 14, 2017 at 3:18:21 PM UTC, David Brown wrote:
> On 14/01/17 15:00, BartC wrote:
>
> I believe Ian assumed the readers had at least basic familiarity with 
> C++, C++ files, and C++ compilers.
> 
> >
> > (Nice touch BTW of having .cc meaning a C++ source file, and cc meaning
> > a C compiler. You don't want to make this stuff too obvious!)
> >
>
The point is the trivial is important. No-one is born knowing that
cc is the C compiler and .cc is the C++ extension. Or what 
std::char_trait<char> is supposed to be achieving and why it might
appear in an error message.

Either someone hand holds you through the process, in which case you
get the same problems as soon as you get a step wrong, or you fiddle
and look things up and write short exploratory programs and do web
searches, and at the end of several hours, you've got the answer,
but you've run through hours of work time.

[toc] | [prev] | [next] | [standalone]

#101790

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> Either someone hand holds you through the process,

"How do I link my C++ objects to C objects?"

"Run your system's C++ compiler."

So complex..

[toc] | [prev] | [next] | [standalone]

#101820

Gareth Owen <gwowen@gmail.com> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> Either someone hand holds you through the process,
>
> "How do I link my C++ objects to C objects?"
>
> "Run your system's C++ compiler."
>
> So complex..

See also https://isocpp.org/wiki/faq/mixing-c-and-cpp

Incidentally, C++ has built-in facilities for interfacing to C; C does
not have such facilities for interfacing with C++.  Questions about
mixing the two languages are probably better asked in comp.lang.c++
(after checking the FAQs).

-- 
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]

#101819

BartC <bc@freeuk.com> writes:
[...]
> Now, in all the years I've been frequenting this group, I don't recall 
> the name 'CC' ever coming up. Compared with 'gcc' which might be almost 
> every other post.
>
> Nor have I have ever comes across the file extension '.cc'.
[...]

And now you have.  Is learning new things painful for you?

-- 
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]

#101822

On 14/01/2017 22:41, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> Now, in all the years I've been frequenting this group, I don't recall
>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>> every other post.
>>
>> Nor have I have ever comes across the file extension '.cc'.
> [...]
>
> And now you have.  Is learning new things painful for you?

Why is everyone so keen to make it personal? Do you get a kick out of it 
or something? Putting the boot in to the poor sod that doesn't get Unix?

Someone posts an example of something that is rarely seen in this group, 
without explanation, but of course it's got to be my fault for not 
understanding, for not grabbing the opportunity to LEARN NEW THINGS, 
instead of the poster's fault for not being clearer.

And yes, I get it now. C++ files extensions can apparently be any of 
.cc, .cp, .cxx, .cpp, .CPP, .c++ or .C (yes, 'C'!). Header files can be 
.hh, .hpp, .H or .tcc. A ghastly mess to go with a ghastly language, 
where they can't even decide on a file extension.

[toc] | [prev] | [next] | [standalone]

#101835

On 14/01/17 23:03, BartC wrote:
> On 14/01/2017 22:41, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> Now, in all the years I've been frequenting this group, I don't recall
>>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>>> every other post.
>>>
>>> Nor have I have ever comes across the file extension '.cc'.
>> [...]
>>
>> And now you have.  Is learning new things painful for you?
>
> Why is everyone so keen to make it personal? Do you get a kick out of it
> or something? Putting the boot in to the poor sod that doesn't get Unix?
>
> Someone posts an example of something that is rarely seen in this group,

the .cc extension is rarely seen in this group because this is a c 
group, not a c++ group, so we tend to talk about c programs, not c++ 
programs

nevertheless, any programmer who has been around c and c++ for at least 
a little while can reasonably be expected to have heard of the .cc extension

> without explanation, but of course it's got to be my fault for not
> understanding, for not grabbing the opportunity to LEARN NEW THINGS,
> instead of the poster's fault for not being clearer.

it's not your fault the first time you don't know something, only the 
second time and onwards

> And yes, I get it now. C++ files extensions can apparently be any of
> .cc, .cp, .cxx, .cpp, .CPP, .c++ or .C (yes, 'C'!). Header files can be
> .hh, .hpp, .H or .tcc. A ghastly mess to go with a ghastly language,
> where they can't even decide on a file extension.

no you still don't get it

file extensions are not part of either language

C++ file extensions can be .doc, .html, .xls, .bartc, or 
.itsybitsyteenyweenyyellowpolkadotbikini if you like

C++ compilers wont necessarily guess those extensions though so you 
might have to tell them yourself

[toc] | [prev] | [next] | [standalone]

#102001

On 15/01/2017 08:41, Parity Error wrote:
> On 14/01/17 23:03, BartC wrote:

>> And yes, I get it now. C++ files extensions can apparently be any of
>> .cc, .cp, .cxx, .cpp, .CPP, .c++ or .C (yes, 'C'!). Header files can be
>> .hh, .hpp, .H or .tcc. A ghastly mess to go with a ghastly language,
>> where they can't even decide on a file extension.
>
> no you still don't get it
>
> file extensions are not part of either language
>
> C++ file extensions can be .doc, .html, .xls, .bartc, or
> .itsybitsyteenyweenyyellowpolkadotbikini if you like

'man gcc' lists over 60 file extensions that are recognised.

If they are not part of the language, it certainly seems to make a big 
deal of them!

One thing has always puzzled me, and it actually applies to lots of 
programs, but the ones that call themselves C compilers are good 
examples. Why is it always necessary to invoke them like this, for example:

    mycc file.c

and not just:

    mycc file

Would it hurt to just assume that this is a .c file if there is no 
extension? How many tens of thousands of times over a year does someone 
have to add in '.c'? It must add up to a huge amount of wasted effort 
when added up over the years and across millions of people. And frustration.

(All my applications that work on one dominant type of file will always 
apply a default extension, sometimes several if there is more than one 
likely possibility. It's called being user-friendly.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#102007

On 16/01/17 21:01, BartC wrote:
> On 15/01/2017 08:41, Parity Error wrote:
>> On 14/01/17 23:03, BartC wrote:
>
>>> And yes, I get it now. C++ files extensions can apparently be any of
>>> .cc, .cp, .cxx, .cpp, .CPP, .c++ or .C (yes, 'C'!). Header files can be
>>> .hh, .hpp, .H or .tcc. A ghastly mess to go with a ghastly language,
>>> where they can't even decide on a file extension.
>>
>> no you still don't get it
>>
>> file extensions are not part of either language
>>
>> C++ file extensions can be .doc, .html, .xls, .bartc, or
>> .itsybitsyteenyweenyyellowpolkadotbikini if you like
>
> 'man gcc' lists over 60 file extensions that are recognised.
>
> If they are not part of the language, it certainly seems to make a big
> deal of them!
>

They are not part of the language.  But they are a convenience to 
/users/ of the language.  You can call your file "hello" or 
"hello.bikini" if you want - but then you need to use "-x c" or "-x c++" 
or "-x ada" to tell gcc what language the source code is written in. 
It's a lot easier to use an extension that by convention is interpreted 
in a particular way unless you specifically override it.  Thus you can 
compile "hello.c" as C++ with "-x c++" if you want.

> One thing has always puzzled me, and it actually applies to lots of
> programs, but the ones that call themselves C compilers are good
> examples. Why is it always necessary to invoke them like this, for example:
>
>    mycc file.c
>
> and not just:
>
>    mycc file
>
> Would it hurt to just assume that this is a .c file if there is no
> extension? How many tens of thousands of times over a year does someone
> have to add in '.c'? It must add up to a huge amount of wasted effort
> when added up over the years and across millions of people. And
> frustration.

In the case of gcc, obviously you need to specify the full file - you 
can have both file.c and file.cpp.  You can also have file.h, which you 
might be passing on to gcc for pre-processing or to figure out its 
dependencies (other #include files) for generation Makefiles.

>
> (All my applications that work on one dominant type of file will always
> apply a default extension, sometimes several if there is more than one
> likely possibility. It's called being user-friendly.)
>

As a user, I've always found full file names to be friendly - at least 
since I left DOS behind and could use a shell with "tab completion" of 
filenames (available in Windows since at least NT 4.0).

[toc] | [prev] | [next] | [standalone]

#102014

On 16/01/2017 23:19, David Brown wrote:
> On 16/01/17 21:01, BartC wrote:

>> 'man gcc' lists over 60 file extensions that are recognised.
>>
>> If they are not part of the language, it certainly seems to make a big
>> deal of them!
>>
>
> They are not part of the language.  But they are a convenience to
> /users/ of the language.

So why not put it on a more official footing? The Standard doesn't need 
to stipulate a particular extension, but an implementation could.

Rather than just have a free-for-all. You don't want a project with .c, 
.cpp and .py files to all actually contain code for a completely 
different language.

(Also, moving a bit beyond C here, when dealing with things such as 
'import' systems, you want to specify a module name. But with a module, 
you don't want to have to give a path, or even a file extension; the 
name of a module is not a filename, but the basis to construct or 
determine a filename and path. But what extension should be used? Things 
will get sticky if source files corresponding to modules could have any 
random extension. Some discipline is called for.)


>> Would it hurt to just assume that this is a .c file if there is no
>> extension?

> In the case of gcc, obviously you need to specify the full file - you
> can have both file.c and file.cpp.

No: gcc is specifically a C compiler (with the ability to do C++) and 
vice versa for g++. If someone really needs to compile C++ using 'gcc', 
then they can type the .cpp. But surely most of the time it will be 
compiling C?

   You can also have file.h, which you
> might be passing on to gcc for pre-processing or to figure out its
> dependencies (other #include files) for generation Makefiles.

I've never passed a .h file to a compiler. The most common kind of file 
is a .c file to a C compiler. But if you did want to do that, then you 
just add the .h.

>> (All my applications that work on one dominant type of file will always
>> apply a default extension, sometimes several if there is more than one
>> likely possibility. It's called being user-friendly.)
>>
>
> As a user, I've always found full file names to be friendly - at least
> since I left DOS behind and could use a shell with "tab completion" of
> filenames (available in Windows since at least NT 4.0).

Tab completion doesn't seem to work with Ubuntu. It works as far as the 
".", but typing Tab here just shows a list of possibilities; it doesn't 
complete the extension.

Even if it did work, you'd probably have to cycle through all the 
possibilities first. If I pressed Tab after typing 'gcc hello' in my 
main C directory, it might work through hello.ali, .asm, .asm64, .b, 
.bas, .bx, .cl, .cpp, .cx, .dll, .exe, .ftn, .h, .i, .lsp, .m, .map, 
.mx, .o, .obj, .pc, .pcs, .png, .pro, .q, .s, and finally .c! (Actually 
it appears to do them in alphabetical order, but it would still be the 
7th option; it would be quicker to just type .c.)

Some apps do work properly: 'unzip fred' for example will unzip 
fred.zip. And the world doesn't seem to have ended yet.

Such a brilliantly simple idea, but most people seem to be intent on 
making poor programmers work a little bit harder!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102025

On 17/01/17 01:29, BartC wrote:
> On 16/01/2017 23:19, David Brown wrote:
>> On 16/01/17 21:01, BartC wrote:
> 
>>> 'man gcc' lists over 60 file extensions that are recognised.
>>>
>>> If they are not part of the language, it certainly seems to make a big
>>> deal of them!
>>>
>>
>> They are not part of the language.  But they are a convenience to
>> /users/ of the language.
> 
> So why not put it on a more official footing? The Standard doesn't need
> to stipulate a particular extension, but an implementation could.

Implementations certainly /can/ stipulate particular extensions.  Maybe
some do - I have not had occasion to name my C files anything other than
.c, or to name my C++ files anything other than a standard extension (I
usually use .cpp).

gcc chooses the most flexible and convenient solution of giving a
default language to a wide range of common extensions, and allowing you
to override it if you want.  I can't see how one could get better than that.

> 
> Rather than just have a free-for-all. You don't want a project with .c,
> .cpp and .py files to all actually contain code for a completely
> different language.

I suppose the C standards could include clauses like "The programmer is
required to be sensible" or "Putting a moron in charge of the project
leads to undefined behaviour".  But I suspect most people on the
standards committee would view that as feature creep.

> 
> (Also, moving a bit beyond C here, when dealing with things such as
> 'import' systems, you want to specify a module name. But with a module,
> you don't want to have to give a path, or even a file extension; the
> name of a module is not a filename, but the basis to construct or
> determine a filename and path. But what extension should be used? Things
> will get sticky if source files corresponding to modules could have any
> random extension. Some discipline is called for.)

C does not have "modules", and is unlikely to acquire them any time
soon.  C++ should get modules before long, though I don't know the
details.  I expect, however, that you /will/ want to be able to specify
paths - just as you do for #include files - while having a "search path"
for common modules.  And I see absolutely no problem with having file
extensions in the names - equally, I see no problem with having a
default or standard file extension.  Both work perfectly well.

The only thing you got right is "some discipline is called for".

> 
> 
>>> Would it hurt to just assume that this is a .c file if there is no
>>> extension?
> 
>> In the case of gcc, obviously you need to specify the full file - you
>> can have both file.c and file.cpp.
> 
> No: gcc is specifically a C compiler (with the ability to do C++) and
> vice versa for g++.

No, as has been explained to you countless times, the gcc project is the
GNU compiler /collection/ supporting a number of languages, and the gcc
binary is the front-end driver supporting a range of languages.  You can
use "gcc" to compile your C code, C++ code, Fortran, Ada, Objective-C,
Objective-C++ and Go last time I looked.  You can also use the same
program for driving the assembler and linker.

The /only/ difference between running the program as "gcc" rather than
"g++" (it's the same binary) is that it adds a "-lstdc++" flag to
include the stdc++ library in links, and treats .c, .h and .i files as
C++ rather than C (unless you override it).

For anything non-trivial, I use "gcc" for compiling C files to object
files, for compiling C++ files to object files, for assembling .S files
to object files, and as a separate command for linking them all.
(Controlled by a Makefile.)

The actual C compiler is "cc1", and the C++ compiler is "cc1plus".  Not
that it matters to anyone - you should use "gcc" (or g++ if you prefer)
as the driver.

> If someone really needs to compile C++ using 'gcc',
> then they can type the .cpp. But surely most of the time it will be
> compiling C?

Most of the time, perhaps, but not all of it.

If I had to use "gcc hello" instead of "gcc hello.c", it would make
using gcc /more/ complicated.  And I really cannot comprehend how anyone
would be bothered about having to type the extra two keystrokes on occasion.

> 
>   You can also have file.h, which you
>> might be passing on to gcc for pre-processing or to figure out its
>> dependencies (other #include files) for generation Makefiles.
> 
> I've never passed a .h file to a compiler. The most common kind of file
> is a .c file to a C compiler. But if you did want to do that, then you
> just add the .h.

I have not had to pass a header to the compiler either, but it is a
feature that some people might use.  I certainly pass things other than
.c files to it.

> 
>>> (All my applications that work on one dominant type of file will always
>>> apply a default extension, sometimes several if there is more than one
>>> likely possibility. It's called being user-friendly.)
>>>
>>
>> As a user, I've always found full file names to be friendly - at least
>> since I left DOS behind and could use a shell with "tab completion" of
>> filenames (available in Windows since at least NT 4.0).
> 
> Tab completion doesn't seem to work with Ubuntu. It works as far as the
> ".", but typing Tab here just shows a list of possibilities; it doesn't
> complete the extension.

Trust me, it works for everyone else's Linux system since the dawn of
time.  But you excel at failing to do what others find easy.

I suspect in this case it is because you expect *nix style completion to
work exactly like Windows-style completion.  It is a little different.

> 
> Even if it did work, you'd probably have to cycle through all the
> possibilities first. If I pressed Tab after typing 'gcc hello' in my
> main C directory, it might work through hello.ali, .asm, .asm64, .b,
> .bas, .bx, .cl, .cpp, .cx, .dll, .exe, .ftn, .h, .i, .lsp, .m, .map,
> .mx, .o, .obj, .pc, .pcs, .png, .pro, .q, .s, and finally .c! (Actually
> it appears to do them in alphabetical order, but it would still be the
> 7th option; it would be quicker to just type .c.)
> 
> Some apps do work properly: 'unzip fred' for example will unzip
> fred.zip. And the world doesn't seem to have ended yet.

That is not "working properly" - that is simply "using a default
extension if non is given", which is a choice that an application
developer can make.

You are stuck in the world of DOS and Windows, and think that anything
in *nix that does something different is weird, counter-intuitive,
confusing or broken.  Many details are different.  Sometimes I think one
OS is significantly better than the other in such things, but mostly
it's just different.

In this case, you should understand that in *nix, a file's type is
determined by its contents - /not/ by its extension as it is in Windows.
 In *nix, file extensions are just part of a file's name, and possibly a
convenience to the user - they do not determine a file's type or what
can be done with the file.

> 
> Such a brilliantly simple idea, but most people seem to be intent on
> making poor programmers work a little bit harder!
> 

Yes, typing ".c" is such a hardship!

[toc] | [prev] | [next] | [standalone]

#102033

On 17/01/2017 08:12, David Brown wrote:
> On 17/01/17 01:29, BartC wrote:

> The actual C compiler is "cc1", and the C++ compiler is "cc1plus".  Not
> that it matters to anyone - you should use "gcc" (or g++ if you prefer)
> as the driver.

And the actual linker is ld. Which if you try and run it separately, 
doesn't work because it's driven in a very complicated manner. (When I 
once tried to intercept the options that gcc was feeding it, it turns 
out, iirc, it was running programs to create a script to feed to ld. gcc 
can't do anything simply when there is a more complicated alternative!)

Using one program for compiling .c, one for .cpp, and another for 
linking seems a lot simpler to me. Combining them into one script is 
child's play for anyone used to C code.

> I have not had to pass a header to the compiler either, but it is a
> feature that some people might use.  I certainly pass things other than
> .c files to it.

This is because it combines cc1, cc1plus and ld (and other programs that 
are also called such as the assembler).

If the programs were separate, the range of file extensions each would 
need cope with would be far smaller, and a natural default extension far 
more viable.

>> Tab completion doesn't seem to work with Ubuntu. It works as far as the
>> ".", but typing Tab here just shows a list of possibilities; it doesn't
>> complete the extension.
>
> Trust me, it works for everyone else's Linux system since the dawn of
> time.  But you excel at failing to do what others find easy.

I excel at finding bugs in other people's programs, especially 
compilers. And I excel at finding troublesome issues in user interfaces. 
(You presumably excel at brushing them under the carpet!)

With this one, I start here with 7 hello.* files including hello.c:

$

Now I type this, up to the 'o':

$ gcc hello

Now I press Tab, it gives me:

$ gcc hello.

OK, that was useful; pressing Tab saved me one keystroke! But there is 
no actual "hello." file. I press Tab again:

$ gcc hello.

No change. I press Tab one more time:

hello.asm64  hello.cc     hello.m      hello.q
hello.c      hello.exe    hello.mx
$ gcc hello.

I get a list of possibilities, and it repeats what I had before. How do 
I get it to auto-complete that blasted ".c"?! I can't.

This is, of course, all /my/ fault. Because I haven't twoggled the 
zwiggle-stick on the thingamijig. <palm to forehead!>

Now let's try that again but on Windows; I type 'gcc hello' up to the 
'o' again:

 > gcc hello

Now I press tab:

 > gcc hello.ali

And I magically get the first extension! Not quite the one I want, which 
is the problem with tabbing, but it's now doing what it says on the box.

> I suspect in this case it is because you expect *nix style completion to
> work exactly like Windows-style completion.  It is a little different.

Oh, like, it doesn't actually auto-complete! So what /does/ it do?

>> Even if it did work, you'd probably have to cycle through all the
>> possibilities first. If I pressed Tab after typing 'gcc hello' in my
>> main C directory, it might work through hello.ali, .asm, .asm64, .b,
>> .bas, .bx, .cl, .cpp, .cx, .dll, .exe, .ftn, .h, .i, .lsp, .m, .map,
>> .mx, .o, .obj, .pc, .pcs, .png, .pro, .q, .s, and finally .c! (Actually
>> it appears to do them in alphabetical order, but it would still be the
>> 7th option; it would be quicker to just type .c.)
>>
>> Some apps do work properly: 'unzip fred' for example will unzip
>> fred.zip. And the world doesn't seem to have ended yet.
>
> That is not "working properly" - that is simply "using a default
> extension if non is given", which is a choice that an application
> developer can make.

Since 99.99% of the time, the extension of the file /will/ be .zip, for 
what perverse, sadistic reason would the developer INSIST that the 
extension is always typed out in full?

> In this case, you should understand that in *nix, a file's type is
> determined by its contents - /not/ by its extension as it is in Windows.

We should be grateful then that file extensions such as .c, .cpp and .o 
exist at all. But then even Unix realised if that if 'hello' is a C 
source file, then you're going to be stuck for a name for the asm file, 
the pp file, the map file, the listing file , the object file and the 
executable as they can't all be called 'hello'. (Or can they? Unix seems 
to excel in allowing stuff like this.)

>  In *nix, file extensions are just part of a file's name,

Odd then that auto-complete would stop at "." in that case; what's 
special about "."?

>> Such a brilliantly simple idea, but most people seem to be intent on
>> making poor programmers work a little bit harder!
>>
>
> Yes, typing ".c" is such a hardship!

Yes I know. You're always so optimistic; nothing is a hardship; nothing 
is too much work; nothing is too complicated; or too slow; or too full 
or problems. Even if you admit that something could be better, you just 
shrug and get on with it.

There are too types of people: those who shrug; and those who don't 
shrug and try and make things a bit different.

I mean, who was the guy who invented tab-completion? When he touted his 
or her idea around, I bet everyone just shrugged their shoulders and 
said, what's the hardship in having to type the rest of a filename 
yourself! It's easier than digging a hole after all.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102036

On 17/01/2017 11:59, BartC wrote:

> I mean, who was the guy who invented tab-completion? When he touted his
> or her idea around ...

I think I'm going to give up trying to be gender neutral.

Let's face it, just like a C source file fed to a compiler is nearly 
always going to end in ".c", so most C programmers are going to be male. 
Women are more sensible!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102038 — OT: Bash tab completion (was: Naming convention for structs and types)

On 2017-01-17, BartC <bc@freeuk.com> wrote:
> I get a list of possibilities, and it repeats what I had before. How do 
> I get it to auto-complete that blasted ".c"?! I can't.

Sure, you can. :-)

> Now let's try that again but on Windows; I type 'gcc hello' up to the 
> 'o' again:
>
> > gcc hello
>
> Now I press tab:
>
> > gcc hello.ali
>
> And I magically get the first extension! Not quite the one I want, which 
> is the problem with tabbing, but it's now doing what it says on the box.

Since you are using Ubuntu I guess your interactive shell is bash. So just 
type

$ bind '"\t": menu-complete'

and you should get the behaviour you are used to on Windows. 

For more information: "man bash" (section READLINE).

[toc] | [prev] | [next] | [standalone]

Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10  Next page →

Back to top | Article view | comp.lang.c

csiph-web