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 1 of 10  [1] 2 3 … 10  Next page →

#101543 — Naming convention for structs and types

Hi:

I made this struct:


typedef struct justfname_s
{
    char *value;
    int len;
} justfname_t;


and want to know if it's correct to end struct's names with "_s" and types with "_t".
In what I've read until now, I didn't see any clear convention.

Thanks.-

[toc] | [next] | [standalone]

#101545

On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> Hi:
> 
> I made this struct:
> 
> 
> typedef struct justfname_s
> {
>     char *value;
>     int len;
> } justfname_t;
> 
> 
> and want to know if it's correct to end struct's names with "_s" and types with "_t".
> In what I've read until now, I didn't see any clear convention.

There are conventions people use apart from C standards.  You can
also define structs without typedef commands if you switch to a
C++ compiler to compile your C code.

I typically use:

    struct SWhatever
    {
        // members go here
    };

And then in C++ you can reference it thusly:

    SWhatever *w = malloc(sizeof(*w));
    if (w)
    {
        // You're good
    }

I use the SWhatever because it's a convention in C++ to use CWhatever
for classes.

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).

Best regards,
Rick C. Hodgin

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

#101568

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
<snip>
>> typedef struct justfname_s
>> {
>>     char *value;
>>     int len;
>> } justfname_t;
>> 
>> 
>> and want to know if it's correct to end struct's names with "_s" and
>> types with "_t".
>> In what I've read until now, I didn't see any clear convention.
>
> There are conventions people use apart from C standards.  You can
> also define structs without typedef commands if you switch to a
> C++ compiler to compile your C code.

Then what you are writing is not C.

> I typically use:
>
>     struct SWhatever
>     {
>         // members go here
>     };
>
> And then in C++ you can reference it thusly:
>
>     SWhatever *w = malloc(sizeof(*w));
>     if (w)
>     {
>         // You're good
>     }

Exactly: you can do that "in C++".

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

You can write C and compile it with C++, but you are suggesting writing
C++.  Anyone following this advice will be writing code that won't
compile with a C compiler.

Using a typedef you could write C that will compile as C++ and still be
valid C.

<snip>
-- 
Ben.

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

#101569

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Using a typedef you could write C that will compile as C++ and still be
> valid C.

You can do the same without using a typedef.

    struct foo {
        int n;
    };
    struct foo obj;

is valid C and valid C++.  (It might not be considered *good* C++;
`foo obj;` probably would be but as you've pointed out that's not
valid C.)

On the other hand, writing code that compiles both as C and as C++ is
IMHO not useful as often as a lot of people think it is.

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

#101571

On 13/01/17 01:35, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

<snip>

>> There are conventions people use apart from C standards.  You can
>> also define structs without typedef commands if you switch to a
>> C++ compiler to compile your C code.
>
> Then what you are writing is not C.

Right.

>
>> I typically use:
>>
>>     struct SWhatever
>>     {
>>         // members go here
>>     };
>>
>> And then in C++ you can reference it thusly:
>>
>>     SWhatever *w = malloc(sizeof(*w));
>>     if (w)
>>     {
>>         // You're good
>>     }
>
> Exactly: you can do that "in C++".

No, he can't, because in C++ he can't assign a void * value to an 
SWhatever * without a cast. C++ is very fussy about things like that.

<snip>

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

#101572

On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> <snip>
> >> typedef struct justfname_s
> >> {
> >>     char *value;
> >>     int len;
> >> } justfname_t;
> >> 
> >> 
> >> and want to know if it's correct to end struct's names with "_s" and
> >> types with "_t".
> >> In what I've read until now, I didn't see any clear convention.
> >
> > There are conventions people use apart from C standards.  You can
> > also define structs without typedef commands if you switch to a
> > C++ compiler to compile your C code.
> 
> Then what you are writing is not C.

Correct! (on a handful of such points ... syntax relaxations that
C++ provides for C-like code)

> > I typically use:
> >
> >     struct SWhatever
> >     {
> >         // members go here
> >     };
> >
> > And then in C++ you can reference it thusly:
> >
> >     SWhatever *w = malloc(sizeof(*w));
> >     if (w)
> >     {
> >         // You're good
> >     }
> 
> Exactly: you can do that "in C++".

As Chris Thomasson points out, you can't.  You actually need:

    SWhatever *w = (SWhatever*)malloc(sizeof(*w));

> > 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.
> 
> You can write C and compile it with C++, but you are suggesting writing
> C++.  Anyone following this advice will be writing code that won't
> compile with a C compiler.

Correct.  And, if I may add, who cares?  Any person following this
advice would've switched from a C to C++ compiler by choice, and
then moved forward.

C's syntax in a half dozen areas is very clunky.  C++ adds relaxations
which make it so much easier.  And, it's what C should've been had
they done it right from the get-go.

> Using a typedef you could write C that will compile as C++ and still be
> valid C.

Typedefs are silly in this case.  A "struct SWhatever" is all that's
needed with a C++ compiler.  It simplifies C's clunky syntax and
removes the need for typedef.

Seriously, who wants to type:

    typedef struct coughcoughchoke1 {
        // members
    } coughcoughchoke2;

When this will do:

    struct awesomeness {
        // members
    }

?  I guess there /are/ some people, right Ben? :-)

Best regards,
Rick C. Hodgin

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

#101584

El viernes, 13 de enero de 2017, 4:27:17 (UTC+1), Rick C. Hodgin  escribió:
<snip> 
> C's syntax in a half dozen areas is very clunky.  C++ adds relaxations
> which make it so much easier.  And, it's what C should've been had
> they done it right from the get-go.
> 

Because I'm new in this language, there is not much I can rebate, but I think that I one takes into account that C whas developed at the very beginning of the computer history, before personal computers, with many hardware restrictions and before OOP and many more advanced concepts, I think that Ritchie made a very good job with this.

I really enjoyed the reading of this paper and did make me understand some limitations and design decisions at that time:

https://www.bell-labs.com/usr/dmr/www/chist.html

Best Regards.-

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

#101596

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
>> > There are conventions people use apart from C standards.  You can
>> > also define structs without typedef commands if you switch to a
>> > C++ compiler to compile your C code.
>> 
>> Then what you are writing is not C.
>
> Correct!

<snip>
>> You can write C and compile it with C++, but you are suggesting writing
>> C++.  Anyone following this advice will be writing code that won't
>> compile with a C compiler.
>
> Correct.  And, if I may add, who cares?

People who want to write C, of course.  All the evidence suggests that
includes the OP to whom you gave this bad advice.

There is hardly any code posted here that could not be simplified by
writing it in C++ but what would be the point of that?

<snip>
-- 
Ben.

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

#102003

On Friday, January 13, 2017 at 5:56:51 AM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> >> > There are conventions people use apart from C standards.  You can
> >> > also define structs without typedef commands if you switch to a
> >> > C++ compiler to compile your C code.
> >> 
> >> Then what you are writing is not C.
> >
> > Correct!
> 
> <snip>
> >> You can write C and compile it with C++, but you are suggesting writing
> >> C++.  Anyone following this advice will be writing code that won't
> >> compile with a C compiler.
> >
> > Correct.  And, if I may add, who cares?
> 
> People who want to write C, of course.  All the evidence suggests that
> includes the OP to whom you gave this bad advice.

He's new to C.  He may not realize he can use a C++ compiler and still
compile C code, but with a few differences.

> There is hardly any code posted here that could not be simplified by
> writing it in C++ but what would be the point of that?

There are some advantages in using the class.  I don't generally see
C++ being useful beyond that.  The aspects of C++ I've encountered are
often obtuse and make the source code more complex, the learning curve
of expert knowledge more comprehensive, and with little gain (except
to die-hard C++ coders who want to write simpler C++ code).

I see value in the class, and it is incorporated into CAlive.  I also
see value in several other things from C and other languages.  I will
incorporate those as well (James 4:15).  We'll see though.  Life keeps
kicking me in the teeth with steel boots.

Best regards,
Rick C. Hodgin

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

#101598

On 13/01/17 04:26, Rick C. Hodgin wrote:
> On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>> <snip>
>>>> typedef struct justfname_s
>>>> {
>>>>     char *value;
>>>>     int len;
>>>> } justfname_t;
>>>>
>>>>
>>>> and want to know if it's correct to end struct's names with "_s" and
>>>> types with "_t".
>>>> In what I've read until now, I didn't see any clear convention.
>>>
>>> There are conventions people use apart from C standards.  You can
>>> also define structs without typedef commands if you switch to a
>>> C++ compiler to compile your C code.
>>
>> Then what you are writing is not C.
> 
> Correct! (on a handful of such points ... syntax relaxations that
> C++ provides for C-like code)
> 

C++ provides a lot of possibilities that C does not have, even if you
stick to "C-like" programming (no OOP, exceptions, overloading,
templates, etc.).  But then it is not C, it is a subset of C++.

And what "syntax relaxations" are you talking about?

>>> I typically use:
>>>
>>>     struct SWhatever
>>>     {
>>>         // members go here
>>>     };
>>>
>>> And then in C++ you can reference it thusly:
>>>
>>>     SWhatever *w = malloc(sizeof(*w));
>>>     if (w)
>>>     {
>>>         // You're good
>>>     }
>>
>> Exactly: you can do that "in C++".
> 
> As Chris Thomasson points out, you can't.  You actually need:
> 
>     SWhatever *w = (SWhatever*)malloc(sizeof(*w));
> 
>>> 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.
>>
>> You can write C and compile it with C++, but you are suggesting writing
>> C++.  Anyone following this advice will be writing code that won't
>> compile with a C compiler.
> 
> Correct.  And, if I may add, who cares?  Any person following this
> advice would've switched from a C to C++ compiler by choice, and
> then moved forward.

Then why not just write in C++ rather than picking a vague restricted
subset that is mostly like C, but not quite - and is missing a few
useful C features into the bargain?

> 
> C's syntax in a half dozen areas is very clunky.  C++ adds relaxations
> which make it so much easier.  And, it's what C should've been had
> they done it right from the get-go.
> 

Can you name these?  You have given one example, but that is based on
your apparent misunderstanding about struct tags and typedefs in C.
What else are you referring to?  (I am not saying that such benefits of
C++ over C do not exist, I am just asking which /you/ think are
particularly useful.)

>> Using a typedef you could write C that will compile as C++ and still be
>> valid C.
> 
> Typedefs are silly in this case.  A "struct SWhatever" is all that's
> needed with a C++ compiler.  It simplifies C's clunky syntax and
> removes the need for typedef.
> 
> Seriously, who wants to type:
> 
>     typedef struct coughcoughchoke1 {
>         // members
>     } coughcoughchoke2;
> 
> When this will do:
> 
>     struct awesomeness {
>         // members
>     }
> 
> ?  I guess there /are/ some people, right Ben? :-)
> 

Why not use:

	typedef struct {
		// members
	} awesomeness;

There is no need to give the struct a tag in most cases (though you need
it for forward declarations for recursive types).  It is simple, clear,
and defines the same name that is used in the same way whether you
compile as C or C++.

Also note that if you /want/ a struct tag, there is nothing wrong with:

	typedef struct awesomeness {
		// members
	} awesomeness;

i.e., the same name for the tag and the typedef.  Again, this is fine in
C and C++ and code using it can do so in exactly the same way.

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

#101605

On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
[...]
> >>> I typically use:
> >>>
> >>>     struct SWhatever
> >>>     {
> >>>         // members go here
> >>>     };
> >>>
> >>> And then in C++ you can reference it thusly:


C++ needs to know the type name before enter
into the type definition for contructor, destructor operators..

struct X
{
  X(){  }
  ~X(){  }
  operator == (X* ) {} 
  //etc..
};

The same for C when we need

struct X
{
  struct X * pNext;
}


An alternative syntax that could have been used for C is:

typedef struct X;
typedef struct { X *pNext; } X;

Today we can use: (very repetitive)

typedef struct X X;
typedef struct X { X *pNext; } X;

or a "Self" keyword for the type could exists.

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

#101607

On 13/01/17 14:03, Thiago Adams wrote:
> On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
> [...]
>>>>> I typically use:
>>>>>
>>>>>     struct SWhatever
>>>>>     {
>>>>>         // members go here
>>>>>     };
>>>>>
>>>>> And then in C++ you can reference it thusly:
> 
> 
> C++ needs to know the type name before enter
> into the type definition for contructor, destructor operators..
> 

Yes, but that is no longer the "sort-of C" subset of C++.  When you are
using methods in your structs, you are clearly in C++ and not a language
that is a few syntax variations away from C.

> struct X
> {
>   X(){  }
>   ~X(){  }
>   operator == (X* ) {} 
>   //etc..
> };
> 
> The same for C when we need
> 

As I mentioned - you need the tag for recursive structures.

> struct X
> {
>   struct X * pNext;
> }
> 
> 
> An alternative syntax that could have been used for C is:
> 
> typedef struct X;
> typedef struct { X *pNext; } X;
> 
> Today we can use: (very repetitive)
> 
> typedef struct X X;
> typedef struct X { X *pNext; } X;
> 
> or a "Self" keyword for the type could exists.
> 

If we wanted an alternative syntax in C, then the obvious choice would
be to allow "struct X { X * pNext; };" and make the "struct" keyword
optional when using the type - just like in C++.  That would cause
conflicts for people who like to take advantage of the separate struct
tag namespace and write things like "struct X X;" to define a variable X
of type "struct X".

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

#101717

On Friday, January 13, 2017 at 1:00:42 PM UTC-2, David Brown wrote:
> On 13/01/17 14:03, Thiago Adams wrote:
> > On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
> > [...]
> >>>>> I typically use:
> >>>>>
> >>>>>     struct SWhatever
> >>>>>     {
> >>>>>         // members go here
> >>>>>     };
> >>>>>
> >>>>> And then in C++ you can reference it thusly:
> > 
> > 
> > C++ needs to know the type name before enter
> > into the type definition for contructor, destructor operators..

Although the name  is "typedef" a better name would be 
typealias.
Typedef is always a alias for type. This alias can have 
pointers and qualifiers.

So:

typedef struct X { int i; } X, *X2;

X is a alias for struct X and X2 is a 
alias for pointer to struct X.
X2 is not a new type.

typedef int int; 
int is a alias for int

C and C++ are equal on this.

We cannot create a new type "X pointer". 
We can only create type X.

I cannot create a constructor and 
destructor for a "type pointer" in C++ because 
"type pointer" cannot be created.

So C++ invented "smart pointers" (fake pointers)
to change the semantics of pointers creating
fake pointers classes. 
In C++ I cannot override on typedef for int as 
well only override on classes and enuns.

Is this "alias" behavior what we really want?
Or the possibility to create new types with new 
properties would be much more useful?

We could create
typedef int meters;
typedef int seconds;

and they could be different types, not alias for int.
You can convert meters to int but not to seconds.

Could we have "pointer to X" as a new type?

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

#101720

On Friday, January 13, 2017 at 8:29:05 PM UTC-6, Thiago Adams wrote:
> Is this "alias" behavior what we really want?
> Or the possibility to create new types with new 
> properties would be much more useful?
> 
> We could create
> typedef int meters;
> typedef int seconds;
> 
> and they could be different types, not alias for int.
> You can convert meters to int but not to seconds.
> 
> Could we have "pointer to X" as a new type?

Extending that principle, it would be useful to be able to allow a
compiler to assume that, in the absence of evidence to the contrary,
a "meters*" won't be used to access a "seconds", nor will a "second*"
be used to access a "meters", but an "int*" could be used to access
either type, and a "meters*" or "seconds*" could be used to access an
"int".

For that to be workable, the aliasing rules would need to be adjusted in
some other ways, but such adjustments would allow more optimizations while
reducing the number of situations requiring "-fno-strict-aliasing".

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

#101747

On 14/01/17 03:28, Thiago Adams wrote:
> On Friday, January 13, 2017 at 1:00:42 PM UTC-2, David Brown wrote:
>> On 13/01/17 14:03, Thiago Adams wrote:
>>> On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
>>> [...]
>>>>>>> I typically use:
>>>>>>>
>>>>>>>     struct SWhatever
>>>>>>>     {
>>>>>>>         // members go here
>>>>>>>     };
>>>>>>>
>>>>>>> And then in C++ you can reference it thusly:
>>>
>>>
>>> C++ needs to know the type name before enter
>>> into the type definition for contructor, destructor operators..
>
> Although the name  is "typedef" a better name would be
> typealias.

Agreed.

> Typedef is always a alias for type. This alias can have
> pointers and qualifiers.
>
> So:
>
> typedef struct X { int i; } X, *X2;
>
> X is a alias for struct X and X2 is a
> alias for pointer to struct X.
> X2 is not a new type.
>
> typedef int int;
> int is a alias for int
>
> C and C++ are equal on this.
>
> We cannot create a new type "X pointer".
> We can only create type X.
>
> I cannot create a constructor and
> destructor for a "type pointer" in C++ because
> "type pointer" cannot be created.
>
> So C++ invented "smart pointers" (fake pointers)
> to change the semantics of pointers creating
> fake pointers classes.
> In C++ I cannot override on typedef for int as
> well only override on classes and enuns.
>
> Is this "alias" behavior what we really want?
> Or the possibility to create new types with new
> properties would be much more useful?
>
> We could create
> typedef int meters;
> typedef int seconds;

I would like that, as it gives a good deal more type-safety in the 
language (at the cost of making some things more verbose).  You can do 
it in C++ with classes, but in C you can only make your new types using 
struct wrappers:

typedef struct { int meters; } meters;

The usage then gets very verbose, and you still don't have any good way 
to avoid assigning a length in meters to a time in seconds.

>
> and they could be different types, not alias for int.
> You can convert meters to int but not to seconds.
>
> Could we have "pointer to X" as a new type?
>

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

#101816

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> typedef int int; 
> int is a alias for int
[...]

That's illegal; you can't use a keyword as a typedef name.

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

#101620

On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
> On 13/01/17 04:26, Rick C. Hodgin wrote:
> > On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> >> <snip>
> >>>> typedef struct justfname_s
> >>>> {
> >>>>     char *value;
> >>>>     int len;
> >>>> } justfname_t;
> >>>>
> >>>>
> >>>> and want to know if it's correct to end struct's names with "_s" and
> >>>> types with "_t".
> >>>> In what I've read until now, I didn't see any clear convention.
> >>>
> >>> There are conventions people use apart from C standards.  You can
> >>> also define structs without typedef commands if you switch to a
> >>> C++ compiler to compile your C code.
> >>
> >> Then what you are writing is not C.
> > 
> > Correct! (on a handful of such points ... syntax relaxations that
> > C++ provides for C-like code)
> > 
> 
> C++ provides a lot of possibilities that C does not have, even if you
> stick to "C-like" programming (no OOP, exceptions, overloading,
> templates, etc.).  But then it is not C, it is a subset of C++.

I have said that in every post.  I have said that if a person is
willing to move to a C++ compiler, then there are some benefits
from that migration.  I have never tried to hide it.

> And what "syntax relaxations" are you talking about?

(1)  Not using struct keyword everywhere, coupled to
(2)  Not having to use typedef.
(3)  Native bool type.
(4)  Use of & types (int&, char&).
(5)  Function overloading.
(6)  Parameter initialization on definition line.

A few others I can't remember off the top of my head.

And some new benefits:
(7)  Stricter typing.
(8)  The class syntax (ptr->member and member() functions) if desired.
(9)  Exception handling.

I prefer (7).  I don't generally use (8) or (9), but it's nice to
know they are there.  I've had to use (9) a couple times to catch
errors in Windows DLLs that were really non-issues, but would cause
the app to crash at runtime without catching their exceptions.

Best regards,
Rick C. Hodgin

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

#101626

On 13/01/17 18:20, Rick C. Hodgin wrote:
> On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
>> On 13/01/17 04:26, Rick C. Hodgin wrote:
>>> On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>>
>>>>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>>>> <snip>
>>>>>> typedef struct justfname_s
>>>>>> {
>>>>>>     char *value;
>>>>>>     int len;
>>>>>> } justfname_t;
>>>>>>
>>>>>>
>>>>>> and want to know if it's correct to end struct's names with "_s" and
>>>>>> types with "_t".
>>>>>> In what I've read until now, I didn't see any clear convention.
>>>>>
>>>>> There are conventions people use apart from C standards.  You can
>>>>> also define structs without typedef commands if you switch to a
>>>>> C++ compiler to compile your C code.
>>>>
>>>> Then what you are writing is not C.
>>>
>>> Correct! (on a handful of such points ... syntax relaxations that
>>> C++ provides for C-like code)
>>>
>>
>> C++ provides a lot of possibilities that C does not have, even if you
>> stick to "C-like" programming (no OOP, exceptions, overloading,
>> templates, etc.).  But then it is not C, it is a subset of C++.
>
> I have said that in every post.  I have said that if a person is
> willing to move to a C++ compiler, then there are some benefits
> from that migration.  I have never tried to hide it.
>
>> And what "syntax relaxations" are you talking about?
>
> (1)  Not using struct keyword everywhere, coupled to

You don't have to use "struct" keyword everywhere.  When I program in C, 
I rarely need it any more than in C++ - because I like to typedef my 
structs.  So this is a non-issue.

> (2)  Not having to use typedef.

Having to write "typedef" when defining structs and enum types is such a 
negligible issue that this is also a non-issue.

> (3)  Native bool type.

C has _Bool, and after #include <stdbool.h> you have bool, true, false 
just like in C++.  So this is also a non-issue.

> (4)  Use of & types (int&, char&).

Using references instead of pointers /is/ a useful feature, and I agree 
it is clearly an advantage C++ has over C.

But that is moving from the "I use a C++ compiler to compile C" category 
into "I use some features of C++ in my coding".  It is not just a minor 
tweak that is nice when you use a C++ compiler for C.

And if you are programming in C++, why not admit it and call it C++ 
rather than "C programming with a C++ compiler" ?

> (5)  Function overloading.

The same applies here as with (4).

> (6)  Parameter initialization on definition line.

What, like "int x = foo();" rather than "int x; x = foo();" or defining 
your variables at the start of a function?  (I'm thinking local 
variables here.)  C has supported that for so long that I don't know 
when it was introduced.  Freely mixing declarations and statements is 
from C99.  (The lack of such mixing is one of my key dislikes about C90.)

However, when you are using Microsoft's tools, their C99 support has 
been very poor until quite recently (as far as I have heard - I have no 
personal experience).  So if you are comparing C as supported by 
slightly out-of-date MS tools to C++, then I can see this point.  But if 
you are comparing /C/ to C++, then this is definitely a non-issue.

>
> A few others I can't remember off the top of my head.
>
> And some new benefits:
> (7)  Stricter typing.

True - /if/ you are using C++ features.

> (8)  The class syntax (ptr->member and member() functions) if desired.

That's C++, not C compiled by a C++ compiler.

> (9)  Exception handling.

That's C++, not C compiled by a C++ compiler.

>
> I prefer (7).  I don't generally use (8) or (9), but it's nice to
> know they are there.  I've had to use (9) a couple times to catch
> errors in Windows DLLs that were really non-issues, but would cause
> the app to crash at runtime without catching their exceptions.
>

Basically, what you are saying is that you like some C++ features and 
like to use them in your coding, even though you also /dislike/ certain 
other C++ features and you avoid them.

That's fine - but you are programming in C++ with limitations.  You are 
not using a C++ compiler to compile your C code.

And that applies even if you think that some or all of these features 
should be part of C.

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

#101632

On Friday, January 13, 2017 at 12:47:52 PM UTC-5, David Brown wrote:
> On 13/01/17 18:20, Rick C. Hodgin wrote:
> > On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
> >> And what "syntax relaxations" are you talking about?
> >
> > (1)  Not using struct keyword everywhere, coupled to
> 
> You don't have to use "struct" keyword everywhere.  When I program in C, 
> I rarely need it any more than in C++ - because I like to typedef my 
> structs.  So this is a non-issue.

You do unless you use a typdef.

> > (2)  Not having to use typedef.
> 
> Having to write "typedef" when defining structs and enum types is such a 
> negligible issue that this is also a non-issue.

We differ in opinions here.

> > (3)  Native bool type.
> 
> C has _Bool, and after #include <stdbool.h> you have bool, true, false 
> just like in C++.  So this is also a non-issue.

_Bool is not bool.  It's close, but it doesn't have to be one byte.
And, it's not included with Visual Studio.

> > (4)  Use of & types (int&, char&).
> > (5)  Function overloading.
> > (6)  Parameter initialization on definition line.
> 
> What, like "int x = foo();" rather than "int x; x = foo();" or defining 
> your variables at the start of a function?  (I'm thinking local 
> variables here.)  C has supported that for so long that I don't know 
> when it was introduced.  Freely mixing declarations and statements is 
> from C99.  (The lack of such mixing is one of my key dislikes about C90.)

This:

    int myfunc(int a, int b = 3, char* c = NULL);

With usage:

    myfunc(5);

It automatically populates b and c for you.

> Basically, what you are saying is that you like some C++ features and 
> like to use them in your coding, even though you also /dislike/ certain 
> other C++ features and you avoid them.

I think C should have these features, as they are very C-like, and
are not really C++-like.  C++-like features are in the class and its
many features.

> That's fine - but you are programming in C++ with limitations.  You are 
> not using a C++ compiler to compile your C code.

99% of what I write is C code.  The 1% that's not is as I indicate
above.  And, as I have stated repeatedly, even asking for some of
these features to be considered for inclusion on comp.std.c, I
believe these should be C features.

> And that applies even if you think that some or all of these features 
> should be part of C.

I am not confined in my thinking of what C should be based on what
the C standard says.  I look at C as a type of thing, rather than
the explicitly defined thing.  I look at the C Standard as a thing,
and C itself to be more of a philosophy.

I intend to introduce these features into CAlive, and be done with
it.  And my offering here to Fernando D. Bozzo is an offering to
simplify his programming life in C by using these few features of
a C++ compiler, and by switching to a C++ compiler to use them.

I have done this successfully since the 90s.  It's just not "kosher"
with the C-strict group.  And ... I'm not only okay with that, I am
more than okay with that because I look at strict C as a dying language
because it is too constrictive.  C++ took great strides toward greater
simplicity, but went too far.

Something better meeting the needs of human beings is what's required.
And those are my goals with CAlive.  And they've been the goals of a
few dozen other spawned off projects.

Best regards,
Rick C. Hodgin

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

#101658

On 13/01/17 19:02, Rick C. Hodgin wrote:
> On Friday, January 13, 2017 at 12:47:52 PM UTC-5, David Brown wrote:
>> On 13/01/17 18:20, Rick C. Hodgin wrote:
>>> On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
>>>> And what "syntax relaxations" are you talking about?
>>>
>>> (1)  Not using struct keyword everywhere, coupled to
>>
>> You don't have to use "struct" keyword everywhere.  When I program in C,
>> I rarely need it any more than in C++ - because I like to typedef my
>> structs.  So this is a non-issue.
>
> You do unless you use a typdef.
>
>>> (2)  Not having to use typedef.
>>
>> Having to write "typedef" when defining structs and enum types is such a
>> negligible issue that this is also a non-issue.
>
> We differ in opinions here.

Apparently so.

Nonetheless, you certainly don't get to count (1) and (2) as two 
different issues - it is a single combined point that I believe most 
people would consider minor.

>
>>> (3)  Native bool type.
>>
>> C has _Bool, and after #include <stdbool.h> you have bool, true, false
>> just like in C++.  So this is also a non-issue.
>
> _Bool is not bool.  It's close, but it doesn't have to be one byte.
> And, it's not included with Visual Studio.

_Bool in C works like bool in C++.  In neither case do they have to be 
single byte (not that the size of "byte" is fixed in C).  In practice, 
both /are/ a single byte.  I certainly know of no C/C++ compiler that 
implements C _Bool in any other way than C++ bool.

The failings of MSVC to implement 20 year old C standards is not a 
failing of C.  It /is/ a reason to use MSVC C++ mode rather than MSVC C 
mode to compile your C code - if you are stuck with only a very limited 
C compiler.  But you should be clear that C /has/ a native Boolean type 
that is exactly like that of C++, even if you are unable to use it with 
your choice of C compiler.

>
>>> (4)  Use of & types (int&, char&).
>>> (5)  Function overloading.
>>> (6)  Parameter initialization on definition line.
>>
>> What, like "int x = foo();" rather than "int x; x = foo();" or defining
>> your variables at the start of a function?  (I'm thinking local
>> variables here.)  C has supported that for so long that I don't know
>> when it was introduced.  Freely mixing declarations and statements is
>> from C99.  (The lack of such mixing is one of my key dislikes about C90.)
>
> This:
>
>     int myfunc(int a, int b = 3, char* c = NULL);
>
> With usage:
>
>     myfunc(5);
>
> It automatically populates b and c for you.

This is a different thing - it is default parameters.  And that goes 
along with most of your points as a useful feature of C++ - but nothing 
to do with using a C++ compiler to compile C code.

>
>> Basically, what you are saying is that you like some C++ features and
>> like to use them in your coding, even though you also /dislike/ certain
>> other C++ features and you avoid them.
>
> I think C should have these features, as they are very C-like, and
> are not really C++-like.  C++-like features are in the class and its
> many features.

I don't disagree that they might be /useful/ in C, and that these 
features are all nice points in C++.  Whether they are "C-like" is much 
less clear, as is the question of whether C would be a "better" language 
if they were included.  I suspect that if they were considered 
sufficiently C-like, and sufficiently useful in C style programming, 
then compilers such as gcc would allow at least some of them as 
extensions.  (It already allows a little flexibility of some features 
between C and C++ and between different standards of C and C++.)

The fact that these features are considered integral parts of C++, but 
are not part of C at all, suggests that by definition they are C++-like 
and not C-like.

>
>> That's fine - but you are programming in C++ with limitations.  You are
>> not using a C++ compiler to compile your C code.
>
> 99% of what I write is C code.  The 1% that's not is as I indicate
> above.  And, as I have stated repeatedly, even asking for some of
> these features to be considered for inclusion on comp.std.c, I
> believe these should be C features.
>
>> And that applies even if you think that some or all of these features
>> should be part of C.
>
> I am not confined in my thinking of what C should be based on what
> the C standard says.  I look at C as a type of thing, rather than
> the explicitly defined thing.  I look at the C Standard as a thing,
> and C itself to be more of a philosophy.
>

C /is/ defined by the standards.  That is what C is.

I believe I understand what you are trying to say here, I just don't 
think you are using the right words to describe the way you like to 
program.  Structured procedural programming, perhaps?  I am not sure.

> I intend to introduce these features into CAlive, and be done with
> it.  And my offering here to Fernando D. Bozzo is an offering to
> simplify his programming life in C by using these few features of
> a C++ compiler, and by switching to a C++ compiler to use them.

For the umpteenth time, it is not an "offering" - this is not a temple. 
You are giving advice or suggestions, like everyone else.

If he is interested in C programming, your advice is bad - you are 
suggesting he breaks from the language that all other C programmers use. 
  If he is interested in C++ programming, your advice is bad - you are 
suggesting he hobbles his programming and misses most of the point of 
the language.  /You/ can choose to program in a language that is mostly 
C but with some C++ bits thrown in - but it is not something that should 
be recommended to someone starting out in C programming.

>
> I have done this successfully since the 90s.  It's just not "kosher"
> with the C-strict group.  And ... I'm not only okay with that, I am
> more than okay with that because I look at strict C as a dying language
> because it is too constrictive.  C++ took great strides toward greater
> simplicity, but went too far.
>
> Something better meeting the needs of human beings is what's required.
> And those are my goals with CAlive.  And they've been the goals of a
> few dozen other spawned off projects.
>
> Best regards,
> Rick C. Hodgin
>

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

Page 1 of 10  [1] 2 3 … 10  Next page →

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

csiph-web