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

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

How would you design C's replacement?

Started byRui Maciel <rui.maciel@gmail.com>
First post2012-04-29 17:17 +0100
Last post2012-05-03 12:37 -0400
Articles 20 on this page of 253 — 38 participants

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

Contents

  How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-29 17:17 +0100
    Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-29 18:44 +0100
      Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-29 22:20 +0100
      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 15:32 -0700
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 00:37 +0100
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 18:30 -0700
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-04-30 13:43 +1200
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-29 23:45 -0400
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 22:12 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 13:06 +0100
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 08:36 -0700
        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 00:17 -0700
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 01:05 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 07:36 -0400
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 13:39 +0100
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 23:06 +0100
            Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 18:11 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:36 +0100
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 00:24 +0100
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 17:08 -0700
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 19:15 -0700
          Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-05-01 03:06 +0000
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 21:18 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 12:14 +0100
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 16:53 +1200
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:17 -0700
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 17:24 +1200
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:44 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 12:18 +0100
    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-29 11:10 -0700
    Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-04-29 18:27 +0000
      Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 13:54 +0100
    Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:07 +0200
      Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:23 +0200
        Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-04-30 00:41 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 07:30 -0400
            Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 16:29 +0200
      Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:26 +0200
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-29 21:27 +0100
        Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 08:49 +0200
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-04-30 00:42 -0700
        Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 19:40 +0200
          Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-05-25 10:38 +0200
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-27 10:22 +0100
    Re: How would you design C's replacement? FireXware <none@none.invalid> - 2012-04-29 14:29 -0600
      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 17:18 -0700
        Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:56 +0100
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 08:04 -0700
    Re: How would you design C's replacement? Mark Storkamp <mstorkamp@yahoo.com> - 2012-04-29 16:37 -0500
    Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-04-29 22:43 +0000
    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 06:41 +0200
    Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-30 01:33 -0500
      Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 07:26 -0400
        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 13:30 +0200
      Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 11:44 +1200
        Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:25 -0700
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 18:23 +1200
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 06:18 -0700
        Re: How would you design C's replacement? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-02 20:25 +0000
        Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:10 -0700
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 20:34 +1200
    Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-30 01:01 -0700
      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 10:08 +0200
        Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-30 08:22 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 12:09 -0400
            Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-01 00:23 -0700
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:40 -0700
            Re: How would you design C's replacement? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-02 20:15 +0000
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 17:17 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 12:44 -0400
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 16:28 -0700
                Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 23:50 -0400
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 13:52 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 13:44 +0100
            Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-01 08:34 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:22 +0100
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:14 -0700
        Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:35 -0400
        Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-04 00:44 -0700
    Re: How would you design C's replacement? Leo Havmøller <rtxleh@nospam.nospam> - 2012-04-30 13:39 +0200
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 11:15 +0100
        Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:15 -0700
    Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-04-30 12:11 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:29 +0100
        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 16:43 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:31 +0100
            Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 03:11 -0700
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 12:32 +0100
                Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:06 -0700
                  Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 14:11 +0100
                    Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:29 -0700
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:24 -0700
                      Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:22 -0700
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 06:44 -0700
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:22 -0700
                  Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-05-02 21:33 +0000
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:59 -0700
                    Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-05-02 22:16 -0500
                  Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-03 10:13 +0100
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-03 13:05 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 23:36 +0100
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 02:40 -0700
          Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 01:37 -0700
            Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-05-02 16:41 +0200
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 02:54 -0700
              Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:18 -0400
        Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-02 20:27 -0700
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 01:22 -0700
        Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-05-04 00:41 -0700
          Re: How would you design C's replacement? Ike Naar <ike@iceland.freeshell.org> - 2012-05-04 08:41 +0000
            Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-05-07 01:11 -0700
              Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-07 07:18 -0400
                Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-07 05:41 -0700
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-07 09:24 -0400
                  Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-07 09:31 -0700
                    Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-10 15:37 -0700
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-04 08:16 -0700
          Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-04 09:49 -0700
    Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-04-30 14:25 -0400
      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 22:19 +0200
        Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 14:04 -0700
          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-01 00:33 +0200
            Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 15:43 -0700
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:17 +0100
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:15 +0100
            Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-01 07:12 -0700
          Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-05-01 10:41 -0400
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 17:39 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 12:46 -0400
        Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 21:41 -0700
        Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-01 00:22 -0700
        Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-01 15:53 -0400
        Re: How would you design C's replacement? Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-05-09 21:06 +0000
          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-10 00:32 +0200
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-10 10:35 +1200
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-09 16:18 -0700
            Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-10 02:45 +0000
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-10 16:18 +0100
                Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-05-11 03:21 -0500
                  Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-11 15:55 +0000
                    Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-13 17:39 +0100
                      Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-14 00:08 -0700
                    Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-13 21:24 +0100
                      Re: How would you design C's replacement? Marco <prenom_nomus@yahoo.com> - 2012-05-20 06:50 -0700
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-10 00:08 -0700
              Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-10 04:04 -0700
            Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-10 10:38 -0700
              Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-10 11:15 -0700
                Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:36 -0700
                  Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 17:49 +0200
                    Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:34 -0700
                    Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 09:41 -0700
                      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 19:42 +0200
                        Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 10:50 -0700
                          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:16 +0200
                            Trigraphs (was Re: How would you design C's replacement?) Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:49 -0400
                              Re: Trigraphs (was Re: How would you design C's replacement?) James Kuyper <jameskuyper@verizon.net> - 2012-05-14 12:21 -0400
                                Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 09:50 -0700
                                  Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 13:05 -0400
                                    Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 10:24 -0700
                                      Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:56 -0700
                                        Re: Trigraphs jacob navia <jacob@spamsink.net> - 2012-05-14 21:00 +0200
                                          Re: Trigraphs Robert Wessel <robertwessel2@yahoo.com> - 2012-05-14 16:37 -0500
                                            Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:58 -0400
                                              Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 21:05 -0700
                                                Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:19 -0700
                                          Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:05 -0700
                                          Re: Trigraphs jgk@panix.com (Joe keane) - 2012-05-17 22:04 +0000
                                        Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 16:22 -0400
                                          Re: Trigraphs "BartC" <bc@freeuk.com> - 2012-05-14 22:05 +0100
                                            Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 22:31 -0400
                                              Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 21:17 -0700
                                          Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:42 -0700
                                    Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 13:33 -0700
                                      Re: Trigraphs Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-14 23:02 +0200
                                        Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:35 -0400
                        Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:49 -0700
                      Re: How would you design C's replacement? Gareth Owen <gwowen@gmail.com> - 2012-05-11 18:49 +0100
                        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:14 +0200
                          Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:56 -0700
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-10 11:31 -0700
                Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:38 -0700
                  Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:36 -0700
                    Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 19:12 -0700
                      Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:56 -0400
                        Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:34 -0700
        Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-05-10 20:05 +0000
          Re: How would you design C's replacement? "J. J. Farrell" <jjf@bcs.org.uk> - 2012-05-11 06:19 +0100
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:33 +0100
    Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-04-30 22:38 +0000
    Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 17:43 +1200
      Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 09:39 +0200
        Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 20:21 +1200
          Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 10:39 +0200
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 20:47 +1200
              Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 08:10 -0400
              Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 14:37 +0200
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 08:17 -0400
        Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 07:48 -0400
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:32 -0700
            Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 23:07 +0200
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-02 18:02 +1200
                Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-02 14:40 +0200
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 10:35 -0400
                    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-02 16:51 +0200
                      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 11:44 -0700
                        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:23 -0700
                        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-03 12:14 +0200
                          Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-03 13:38 +0200
                      Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 07:28 +1200
                        Re: How would you design C's replacement? ImpalerCore <jadill33@gmail.com> - 2012-05-02 13:28 -0700
                          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 18:44 +1200
                      Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-03 00:56 -0700
                  Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-02 16:04 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 17:14 -0400
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:10 -0700
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-02 17:52 +1200
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 02:37 -0700
                Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 07:29 -0400
    Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 12:19 +0100
    Re: How would you design C's replacement? Lanarcam <lanarcam1@yahoo.fr> - 2012-05-01 18:02 +0200
      Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:43 -0700
        Re: How would you design C's replacement? Lanarcam <lanarcam1@yahoo.fr> - 2012-05-01 22:52 +0200
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:12 -0700
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 20:59 -0700
            Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 02:09 -0700
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:08 -0400
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-03 16:05 -0700
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 02:04 -0700
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-02 10:36 +0100
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 07:36 -0400
            Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-02 16:21 +0100
              Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:26 -0400
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-03 16:08 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-02 16:16 +0100
            Re: How would you design C's replacement? Dr Nick <3-nospam@temporary-address.org.uk> - 2012-05-02 19:46 +0100
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 12:12 -0700
              Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-02 20:26 +0100
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 12:59 -0700
                Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-02 14:32 -0700
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:09 -0700
                Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 18:45 +1200
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-03 08:13 -0400
                    Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-04 07:18 +1200
              Re: How would you design C's replacement? David Thompson <dave.thompson2@verizon.net> - 2012-05-13 00:15 -0400
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:22 -0400
          Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 03:09 -0700
            Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-03 03:55 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-03 12:45 +0100
            Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-03 13:15 +0100
              Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-03 13:41 +0100
                Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-03 17:51 +0100
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:37 -0400

Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13  Next page →

#20186

FromJens Gustedt <jens.gustedt@loria.fr>
Date2012-05-01 23:07 +0200
Message-ID<4FA050A0.6070009@loria.fr>
In reply to#20183
Am 05/01/2012 10:32 PM, schrieb Keith Thompson:
> As I understand it, C++ introduced a new use for the "auto" keyword
> *without* breaking existing uses.
> 
> (The new form of "auto" lets you declare an object without explicitly
> specifying its type; the type is inferred from the initializer.)
> 
> For example:
> 
>     {
>         auto int x = 42; /* old-style "auto", useless but legal */
>         auto y = x;      /* new-style "auto" */
>     }
> 
> It's no more problematic than C's habitual re-use of "static".

that would be good news, since I like the feature itself

As long as there is a type following auto, this is an old style
declaration of an automatic variable?

How would one then resove ambiguities, and declaration order?

Would it fit well with the rest of C?

In C++ an "auto" type determined variable can't have a {} initializer,
since these don't have types. But in C we could use a compound
literal:

typedef struct toto toto;
struct toto { toto * x; };
auto y = (toto){ &y };

The compound literal that is used for initialization is only valid if
y is of type toto. So the compound literal would first be evaluated
for its type, the type of y would be determined, and then the compound
literal would be evaluated for its value?

Jens

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

#20207

FromIan Collins <ian-news@hotmail.com>
Date2012-05-02 18:02 +1200
Message-ID<a0c0uoFmc0U4@mid.individual.net>
In reply to#20186
On 05/ 2/12 09:07 AM, Jens Gustedt wrote:
> Am 05/01/2012 10:32 PM, schrieb Keith Thompson:
>> As I understand it, C++ introduced a new use for the "auto" keyword
>> *without* breaking existing uses.
>>
>> (The new form of "auto" lets you declare an object without explicitly
>> specifying its type; the type is inferred from the initializer.)
>>
>> For example:
>>
>>      {
>>          auto int x = 42; /* old-style "auto", useless but legal */
>>          auto y = x;      /* new-style "auto" */
>>      }
>>
>> It's no more problematic than C's habitual re-use of "static".
>
> that would be good news, since I like the feature itself
>
> As long as there is a type following auto, this is an old style
> declaration of an automatic variable?
>
> How would one then resove ambiguities, and declaration order?
>
> Would it fit well with the rest of C?

James Kuyper addressed compatibility.

> In C++ an "auto" type determined variable can't have a {} initializer,
> since these don't have types. But in C we could use a compound
> literal:

It can where the type can be deduced, the standard uses an example:

auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>

Something simple like

auto x = {1};

is also OK.

> typedef struct toto toto;
> struct toto { toto * x; };
> auto y = (toto){&y };

This wouldn't work, but in that case there is nothing to be gained with 
auto (you had to name the type in the cast).

> The compound literal that is used for initialization is only valid if
> y is of type toto. So the compound literal would first be evaluated
> for its type, the type of y would be determined, and then the compound
> literal would be evaluated for its value?

But you still have to name the type somewhere in the statement.

-- 
Ian Collins

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

#20217

FromJens Gustedt <jens.gustedt@loria.fr>
Date2012-05-02 14:40 +0200
Message-ID<4FA12B57.1010609@loria.fr>
In reply to#20207
Am 05/02/2012 08:02 AM, schrieb Ian Collins:

> It can where the type can be deduced, the standard uses an example:
> 
> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>

You mean the C++ states this, I suppose. Could you translate that into
something for C? int[2]?

> Something simple like
> 
> auto x = {1};
> 
> is also OK.

Is it int or int[1] ?

>> typedef struct toto toto;
>> struct toto { toto * x; };
>> auto y = (toto){&y };
> 
> This wouldn't work, but in that case there is nothing to be gained with
> auto (you had to name the type in the cast).


>> The compound literal that is used for initialization is only valid if
>> y is of type toto. So the compound literal would first be evaluated
>> for its type, the type of y would be determined, and then the compound
>> literal would be evaluated for its value?
> 
> But you still have to name the type somewhere in the statement.

An application of all this would be something where you have a macro for
initialisation, say

#define TOTO_INITIALIZER(X) (toto){&(X)}

Then

auto y = TOTO_INITIALIZER(y);

would avoid to give the type twice. Nowadays such macros in C look more like

#define TOTO_INITIALIZER(X) {&(X)}

with only implicit mention of the type and then

toto y = TOTO_INITIALIZER(y);

will not check for consistence.

Jens

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

#20218

FromJames Kuyper <jameskuyper@verizon.net>
Date2012-05-02 10:35 -0400
Message-ID<4FA14649.30701@verizon.net>
In reply to#20217
On 05/02/2012 08:40 AM, Jens Gustedt wrote:
> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
> 
>> It can where the type can be deduced, the standard uses an example:
>>
>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
> 
> You mean the C++ states this, I suppose. Could you translate that into
> something for C? int[2]?

std::initializer_list<> is a relatively new standard library template.
It's too new for me to be very familiar with it; I stopped paying close
attention to the C++ standard around the time they started preparing the
2003 standard. Key sections mentioning initializer lists seem to be
8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
should be adapted to C; I think that C might need to take a simpler
approach to the cases where C++ relies upon initializer lists.

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

#20220

Fromjacob navia <jacob@spamsink.net>
Date2012-05-02 16:51 +0200
Message-ID<jnrhlq$m1h$1@speranza.aioe.org>
In reply to#20218
Le 02/05/12 16:35, James Kuyper a écrit :
> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>>
>>> It can where the type can be deduced, the standard uses an example:
>>>
>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>>
>> You mean the C++ states this, I suppose. Could you translate that into
>> something for C? int[2]?
>
> std::initializer_list<>  is a relatively new standard library template.
> It's too new for me to be very familiar with it; I stopped paying close
> attention to the C++ standard around the time they started preparing the
> 2003 standard. Key sections mentioning initializer lists seem to be
> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
> should be adapted to C; I think that C might need to take a simpler
> approach to the cases where C++ relies upon initializer lists.


Excuse me but how should that work?

auto foo = 45;

What should that be?

char, short, int, long long, unsigned char, unsigned short, unsigned int
or unsigned long long?

ALL those types qualify actually. Even float and double qualify also.

And this:

auto x = 'a';

Is that a char? an int?

And what would the users gain from such a construct?
In C++ with the template stuff it is maybe necessary, but in C???

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

#20229

FromBGB <cr88192@hotmail.com>
Date2012-05-02 11:44 -0700
Message-ID<jnrvds$527$1@news.albasani.net>
In reply to#20220
On 5/2/2012 7:51 AM, jacob navia wrote:
> Le 02/05/12 16:35, James Kuyper a écrit :
>> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
>>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>>>
>>>> It can where the type can be deduced, the standard uses an example:
>>>>
>>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>>>
>>> You mean the C++ states this, I suppose. Could you translate that into
>>> something for C? int[2]?
>>
>> std::initializer_list<> is a relatively new standard library template.
>> It's too new for me to be very familiar with it; I stopped paying close
>> attention to the C++ standard around the time they started preparing the
>> 2003 standard. Key sections mentioning initializer lists seem to be
>> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
>> should be adapted to C; I think that C might need to take a simpler
>> approach to the cases where C++ relies upon initializer lists.
>
>
> Excuse me but how should that work?
>
> auto foo = 45;
>
> What should that be?
>

AFAIK, absent anything else, the default type here is 'int'.


> char, short, int, long long, unsigned char, unsigned short, unsigned int
> or unsigned long long?
>

it defaults to int, as there is little reason for anything smaller.
int is sort of the "implicit default type" in C (though it is at least a 
little more explicit in C99, "implicit int" and similar tend to remain, 
well, implicitly...).

long or long-long literals generally require suffixes, such as L or LL.


> ALL those types qualify actually. Even float and double qualify also.
>

actually, no:
you only get float or double if it has a form like '1.0' or similar.

IIRC, in C it defaults to double in this case.


> And this:
>
> auto x = 'a';
>
> Is that a char? an int?
>

probably, it would be char in C++, and int in C.


> And what would the users gain from such a construct?
> In C++ with the template stuff it is maybe necessary, but in C???

it is less clear.


my own language does something similar with declarations like "var x;" 
where the compiler may attempt to infer the type, but with the 
difference that the variable is not forced to use a single type over its 
entire lifetime, but rather it is local to "a specific location in the 
program".

so, assigning to a variable not only assigns a value at run-time, but 
may also assign a type at compile-time, with some special handling for 
"clashes".

all else fails, it uses dynamic types for the variable.

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

#20250

FromKeith Thompson <kst-u@mib.org>
Date2012-05-02 17:23 -0700
Message-ID<lnlilaru2k.fsf@nuthaus.mib.org>
In reply to#20229
BGB <cr88192@hotmail.com> writes:
> On 5/2/2012 7:51 AM, jacob navia wrote:
>> Le 02/05/12 16:35, James Kuyper a écrit :
>>> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
>>>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>>>>
>>>>> It can where the type can be deduced, the standard uses an example:
>>>>>
>>>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>>>>
>>>> You mean the C++ states this, I suppose. Could you translate that into
>>>> something for C? int[2]?
>>>
>>> std::initializer_list<> is a relatively new standard library template.
>>> It's too new for me to be very familiar with it; I stopped paying close
>>> attention to the C++ standard around the time they started preparing the
>>> 2003 standard. Key sections mentioning initializer lists seem to be
>>> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
>>> should be adapted to C; I think that C might need to take a simpler
>>> approach to the cases where C++ relies upon initializer lists.
>>
>>
>> Excuse me but how should that work?
>>
>> auto foo = 45;
>>
>> What should that be?
>
> AFAIK, absent anything else, the default type here is 'int'.
>
>> char, short, int, long long, unsigned char, unsigned short, unsigned int
>> or unsigned long long?
>
> it defaults to int, as there is little reason for anything smaller.
> int is sort of the "implicit default type" in C (though it is at least a 
> little more explicit in C99, "implicit int" and similar tend to remain, 
> well, implicitly...).
>
> long or long-long literals generally require suffixes, such as L or LL.
>
>> ALL those types qualify actually. Even float and double qualify also.
>
> actually, no:
> you only get float or double if it has a form like '1.0' or similar.
>
> IIRC, in C it defaults to double in this case.
[...]

There's no ambiguity for simple cases like this; the type is the type of
the initializer expression:

    auto x = 42;  /* 42 is of type int */
    auto y = 'y'; /* 'y' is of type char in C++, int in C */
    auto z = 1.0; /* 1.0 is of type double */

In C++, the types of x, y, and z are int, char, and double,
respectively.  In particular, x is of type int not because int is
the "default implicit type" in C, but because 42 is of type int.

If C adopted C++'s "auto" feature, they'd presumably be of types int,
int, and double, respectively (the type of a character constant is one
difference between C and C++.)

The C++ rules for auto are more complicated:

    Once the type of a declarator-id has been determined according to
    8.3, the type of the declared variable using the declarator-id is
    determined from the type of its initializer using the rules for
    template argument deduction.

and I don't claim to understand them.

Presumably a C version of this feature would be defined more simply,
while maintaining at least some compatibility with C++.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20274

Fromjacob navia <jacob@spamsink.net>
Date2012-05-03 12:14 +0200
Message-ID<jntlql$sf0$1@speranza.aioe.org>
In reply to#20229
Le 02/05/12 20:44, BGB a écrit :
> On 5/2/2012 7:51 AM, jacob navia wrote:
>> Excuse me but how should that work?
>>
>> auto foo = 45;
>>
>> What should that be?
>>
>
> AFAIK, absent anything else, the default type here is 'int'.


Then you can NEVER initialize types short or char with a constant.
Unless you make a cast:

auto foo = (short)45;

What is worst than the more concise

short foo =45;

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

#20278

FromJens Gustedt <jens.gustedt@loria.fr>
Date2012-05-03 13:38 +0200
Message-ID<4fa26e3e$0$16480$426a74cc@news.free.fr>
In reply to#20274
Am 05/03/2012 12:14 PM, schrieb jacob navia:
> Then you can NEVER initialize types short or char with a constant.
> Unless you make a cast:
> 
> auto foo = (short)45;
> 
> What is worst than the more concise
> 
> short foo =45;

Sure, if you initialize from a known constant the C++ auto feature
doesn't make much sense, anyhow.

It only does where the type is somehow hidden to the eye. In C++ I
guess the most interesting case are templates. In C this would be if
you have a type generic macro à la _Generic on the right hand side.

E.g

auto x = sin(y);

where you want x to inherit the type of y, even if occasionally
somebody is changing the type of y from double to float for example

Jens

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

#20233

FromIan Collins <ian-news@hotmail.com>
Date2012-05-03 07:28 +1200
Message-ID<a0dg7dFt22U2@mid.individual.net>
In reply to#20220
On 05/ 3/12 02:51 AM, jacob navia wrote:
> Le 02/05/12 16:35, James Kuyper a écrit :
>> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
>>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>>>
>>>> It can where the type can be deduced, the standard uses an example:
>>>>
>>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>>>
>>> You mean the C++ states this, I suppose. Could you translate that into
>>> something for C? int[2]?
>>
>> std::initializer_list<>   is a relatively new standard library template.
>> It's too new for me to be very familiar with it; I stopped paying close
>> attention to the C++ standard around the time they started preparing the
>> 2003 standard. Key sections mentioning initializer lists seem to be
>> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
>> should be adapted to C; I think that C might need to take a simpler
>> approach to the cases where C++ relies upon initializer lists.
>
>
<snip>
>
> And what would the users gain from such a construct?

A trivial example might be something like:

   auto in  = fopen("x", "r" );
   auto out = fopen("y", "w+" );

   char buf[64];

   // what does fread return?
   //
   auto toWrite = fread( buf, sizeof(buf), 1, in );

   if( toWrite )
   {
     auto written = fwrite( buf, sizeof(buf), 1, out );

     if( written != toWrite ) { /* report error */ }
   }

> In C++ with the template stuff it is maybe necessary, but in C???

I agree the feature is much more important to C++ than to C, but handy 
none the lass.

-- 
Ian Collins

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

#20238

FromImpalerCore <jadill33@gmail.com>
Date2012-05-02 13:28 -0700
Message-ID<c462972f-d1ad-4bf6-886e-31823fa5f49a@y11g2000vbn.googlegroups.com>
In reply to#20233
On May 2, 3:28 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 05/ 3/12 02:51 AM, jacob navia wrote:
>
>
>
>
>
>
>
>
>
> > Le 02/05/12 16:35, James Kuyper a écrit :
> >> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
> >>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>
> >>>> It can where the type can be deduced, the standard uses an example:
>
> >>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>
> >>> You mean the C++ states this, I suppose. Could you translate that into
> >>> something for C? int[2]?
>
> >> std::initializer_list<>   is a relatively new standard library template.
> >> It's too new for me to be very familiar with it; I stopped paying close
> >> attention to the C++ standard around the time they started preparing the
> >> 2003 standard. Key sections mentioning initializer lists seem to be
> >> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
> >> should be adapted to C; I think that C might need to take a simpler
> >> approach to the cases where C++ relies upon initializer lists.
>
> <snip>
>
> > And what would the users gain from such a construct?
>
> A trivial example might be something like:
>
>    auto in  = fopen("x", "r" );
>    auto out = fopen("y", "w+" );
>
>    char buf[64];
>
>    // what does fread return?
>    //
>    auto toWrite = fread( buf, sizeof(buf), 1, in );
>
>    if( toWrite )
>    {
>      auto written = fwrite( buf, sizeof(buf), 1, out );
>
>      if( written != toWrite ) { /* report error */ }
>    }
>
> > In C++ with the template stuff it is maybe necessary, but in C???
>
> I agree the feature is much more important to C++ than to C, but handy
> none the lass.

Handy perhaps, but detrimental to readability and troubleshooting.
Now I have to infer the type of each 'auto' variable by remembering
the return type of each function, as well as any conversions that may
happen under the hood.  Without knowing exactly what 'fread' returns,
it's not clear whether the return type is a int, size_t, or even bool,
and from the context of the next 'if' statement, 'toWrite' could
easily be interpreted as the name of a boolean variable when it's
actually a 'size_t'.

I would not label this a "gain" for C.  Your example is but a taste of
how bad 'auto' would be if used liberally.

Best regards,
John D.

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

#20260

FromIan Collins <ian-news@hotmail.com>
Date2012-05-03 18:44 +1200
Message-ID<a0enptFlveU1@mid.individual.net>
In reply to#20238
On 05/ 3/12 08:28 AM, ImpalerCore wrote:
> On May 2, 3:28 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 05/ 3/12 02:51 AM, jacob navia wrote:
>>> Le 02/05/12 16:35, James Kuyper a écrit :
>>>> On 05/02/2012 08:40 AM, Jens Gustedt wrote:
>>>>> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>>
>>>>>> It can where the type can be deduced, the standard uses an example:
>>
>>>>>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>>
>>>>> You mean the C++ states this, I suppose. Could you translate that into
>>>>> something for C? int[2]?
>>
>>>> std::initializer_list<>     is a relatively new standard library template.
>>>> It's too new for me to be very familiar with it; I stopped paying close
>>>> attention to the C++ standard around the time they started preparing the
>>>> 2003 standard. Key sections mentioning initializer lists seem to be
>>>> 8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
>>>> should be adapted to C; I think that C might need to take a simpler
>>>> approach to the cases where C++ relies upon initializer lists.
>>
>> <snip>
>>
>>> And what would the users gain from such a construct?
>>
>> A trivial example might be something like:
>>
>>     auto in  = fopen("x", "r" );
>>     auto out = fopen("y", "w+" );
>>
>>     char buf[64];
>>
>>     // what does fread return?
>>     //
>>     auto toWrite = fread( buf, sizeof(buf), 1, in );
>>
>>     if( toWrite )
>>     {
>>       auto written = fwrite( buf, sizeof(buf), 1, out );
>>
>>       if( written != toWrite ) { /* report error */ }
>>     }
>>
>>> In C++ with the template stuff it is maybe necessary, but in C???
>>
>> I agree the feature is much more important to C++ than to C, but handy
>> none the lass.
>
> Handy perhaps, but detrimental to readability and troubleshooting.
> Now I have to infer the type of each 'auto' variable by remembering
> the return type of each function, as well as any conversions that may
> happen under the hood.

Why?  Isn't the point not having to know?

> Without knowing exactly what 'fread' returns,
> it's not clear whether the return type is a int, size_t, or even bool,
> and from the context of the next 'if' statement, 'toWrite' could
> easily be interpreted as the name of a boolean variable when it's
> actually a 'size_t'.

But does it matter if the logic is clear?  Let the programmer focus on 
the logic and leave the types and conversions to the compiler.

> I would not label this a "gain" for C.  Your example is but a taste of
> how bad 'auto' would be if used liberally.

I agree it could be seen as auto abuse, but I given implicit int is no 
more, in the above example "auto" could be removed altogether...

-- 
Ian Collins

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

#20262

Fromgwowen <gwowen@gmail.com>
Date2012-05-03 00:56 -0700
Message-ID<74ff247a-593c-435d-9841-1d202e18b206@n22g2000yqb.googlegroups.com>
In reply to#20220
On May 2, 3:51 pm, jacob navia <ja...@spamsink.net> wrote:
> Excuse me but how should that work?
>
> auto foo = 45;
>
> What should that be?

It's an int.  We know this because the (C++) standard says how
literals acquire implicit types, because its important (mainly) for
function overloading.

"An integer literal is a sequence of digits that has no period or
exponent part. An integer literal may have a prefix that specifies its
base and a suffix that specifies its type. The type of an integer
literal depends on its form, value, and suffix. If it is decimal and
has no suffix, it has the first of these types in which its value can
be represented: int, long int;"

45U is an unsigned int.

> char, short, int, long long, unsigned char, unsigned short, unsigned int
> or unsigned long long?
>
> ALL those types qualify actually. Even float and double qualify also.

But the C++ standard says which one counts.  The C standard doesn't
because there's no where that it matters.  If you want a floating
point literal, use a decimal point.

auto f = 45.;  // That's a double

> And this:
>
> auto x = 'a';

"A character literal is one or more characters enclosed in single
quotes, as in ’x’, optionally preceded by the letter L, as in L’x’. A
character literal that does not begin with L is an ordinary character
literal, also referred to as a narrow-character literal. An ordinary
character literal that contains a single c-char has type char..."

> Is that a char? an int?

It's a char.  Again C++ has these rules, and they're pretty much ass
you'd expect (if it looks like a char, its a char...)

> In C++ with the template stuff it is maybe necessary, but in C???

I agree.  With the present simple type system, . But some of the
suggestions made here for C improvement (namespaces, function
overloading) will complicate the type system to the extent that there
may be some gain.  It really is easier to type:

auto it = container->first_element();

rather than

struct bobs_namespace::vector_of_float::iterator it = container-
>first_element();

and its makes it easier to change the type of container without
invalidating vast swathes of other code.

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

#20221

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2012-05-02 16:04 +0100
Message-ID<0.65331ed5aa0d6eb61d57.20120502160445BST.87mx5qoc8i.fsf@bsb.me.uk>
In reply to#20217
Jens Gustedt <jens.gustedt@loria.fr> writes:

> Am 05/02/2012 08:02 AM, schrieb Ian Collins:
>
>> It can where the type can be deduced, the standard uses an example:
>> 
>> auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
>
> You mean the C++ states this, I suppose. Could you translate that into
> something for C? int[2]?

I think Ian was just answering the assertion that you can't use auto
with an {} list.  There is no real translation into C because x1 is not
an array of ints (or even a std::vector<int>) but an object of a
specific type intended to be used as an argument to a constructor.  It's
a lovely feature (you can have native-looking initialisers for
user-defined types) but you don't get an array out it.

The type std::initializer_list<T> does implement std::begin(), giving
you a random-access iterator (specifically a const T *), but that's not
quite the same thing.  This C++:

  auto a = std::begin({1, 2, 3});

is very much like this C:

  int *a = (int[]){1, 2, 3};

which could be "tidied up" to

  auto a = (int[]){1, 2, 3};

if C had C++'s meaning of auto.  However, you'd probably want to do
something more like this:

  auto x[] = {1, 2};

where the size of the array is determined by the length of the list, and
the type by some rule applied to the types of the list members (the
"largest"? the "widest"? ...?).  Without other changes, or some
complexity in the type-guessing rule,

  auto s[] = {'a', 'b', 'c', '\0'};

(and by extension auto s[] = "abc";) would make the elements of s ints
not chars.

<snip>
-- 
Ben.

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

#20188

FromJames Kuyper <jameskuyper@verizon.net>
Date2012-05-01 17:14 -0400
Message-ID<4FA0522E.4040602@verizon.net>
In reply to#20183
On 05/01/2012 04:32 PM, Keith Thompson wrote:
...
> As I understand it, C++ introduced a new use for the "auto" keyword
> *without* breaking existing uses.
> 
> (The new form of "auto" lets you declare an object without explicitly
> specifying its type; the type is inferred from the initializer.)
> 
> For example:
> 
>     {
>         auto int x = 42; /* old-style "auto", useless but legal */
>         auto y = x;      /* new-style "auto" */
>     }
> 
> It's no more problematic than C's habitual re-use of "static".

The latest draft of the C++ standard that I currently have access to is
n3035, dated 2010-02-16.

In section C, it describes differences between C and C++. In section
C.1.5 it says "The keyword auto cannot be used as a storage class
specifier.". The rationale for this change is given as "Allowing the use
of auto to deduce the type of a variable from its initializer results in
undesired interpretations of auto as a storage class specifier in
certain contexts." It cites section 7.1.6.4, which describes the 'auto'
type specifier, as the basis for this prohibition.

In section 7.1.6.4p5 it says "A program that uses auto in a context not
explicitly allowed in this section is ill-formed.". I found no mention,
in that section, of using 'auto' with the meaning it has in C, only the
new meaning that it has in C++.

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

#20198

FromKeith Thompson <kst-u@mib.org>
Date2012-05-01 16:10 -0700
Message-ID<lnhavzts3w.fsf@nuthaus.mib.org>
In reply to#20188
James Kuyper <jameskuyper@verizon.net> writes:
> On 05/01/2012 04:32 PM, Keith Thompson wrote:
> ...
>> As I understand it, C++ introduced a new use for the "auto" keyword
>> *without* breaking existing uses.
>> 
>> (The new form of "auto" lets you declare an object without explicitly
>> specifying its type; the type is inferred from the initializer.)
>> 
>> For example:
>> 
>>     {
>>         auto int x = 42; /* old-style "auto", useless but legal */
>>         auto y = x;      /* new-style "auto" */
>>     }
>> 
>> It's no more problematic than C's habitual re-use of "static".
>
> The latest draft of the C++ standard that I currently have access to is
> n3035, dated 2010-02-16.
>
> In section C, it describes differences between C and C++. In section
> C.1.5 it says "The keyword auto cannot be used as a storage class
> specifier.". The rationale for this change is given as "Allowing the use
> of auto to deduce the type of a variable from its initializer results in
> undesired interpretations of auto as a storage class specifier in
> certain contexts." It cites section 7.1.6.4, which describes the 'auto'
> type specifier, as the basis for this prohibition.
>
> In section 7.1.6.4p5 it says "A program that uses auto in a context not
> explicitly allowed in this section is ill-formed.". I found no mention,
> in that section, of using 'auto' with the meaning it has in C, only the
> new meaning that it has in C++.

Then I stand corrected.

I would have thought that the new usage could coexist with the
old one (with "auto" having the new meaning if and only if the
declaration lacks an explicit type), but apparently the C++ committee
disagreed.  Probably there are ambiguous cases I haven't thought of,
or perhaps they just wanted to avoid potential confusion and felt
that the minor backward-incompatibility was a price worth paying.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20206

FromIan Collins <ian-news@hotmail.com>
Date2012-05-02 17:52 +1200
Message-ID<a0c0crFmc0U3@mid.individual.net>
In reply to#20188
On 05/ 2/12 09:14 AM, James Kuyper wrote:
> On 05/01/2012 04:32 PM, Keith Thompson wrote:
> ....
>> As I understand it, C++ introduced a new use for the "auto" keyword
>> *without* breaking existing uses.
>>
>> (The new form of "auto" lets you declare an object without explicitly
>> specifying its type; the type is inferred from the initializer.)
>>
>> For example:
>>
>>      {
>>          auto int x = 42; /* old-style "auto", useless but legal */
>>          auto y = x;      /* new-style "auto" */
>>      }
>>
>> It's no more problematic than C's habitual re-use of "static".
>
> The latest draft of the C++ standard that I currently have access to is
> n3035, dated 2010-02-16.

That's rather old, I believe N3225 was the last draft (Like C11, the 
actual standard is still overpriced).

> In section C, it describes differences between C and C++. In section
> C.1.5 it says "The keyword auto cannot be used as a storage class
> specifier.". The rationale for this change is given as "Allowing the use
> of auto to deduce the type of a variable from its initializer results in
> undesired interpretations of auto as a storage class specifier in
> certain contexts." It cites section 7.1.6.4, which describes the 'auto'
> type specifier, as the basis for this prohibition.
>
> In section 7.1.6.4p5 it says "A program that uses auto in a context not
> explicitly allowed in this section is ill-formed.". I found no mention,
> in that section, of using 'auto' with the meaning it has in C, only the
> new meaning that it has in C++.

That's why it gets a mention in the compatibility section!

-- 
Ian Collins

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

#20214

FromKeith Thompson <kst-u@mib.org>
Date2012-05-02 02:37 -0700
Message-ID<lnwr4usz30.fsf@nuthaus.mib.org>
In reply to#20206
Ian Collins <ian-news@hotmail.com> writes:
> On 05/ 2/12 09:14 AM, James Kuyper wrote:
[...]
>> The latest draft of the C++ standard that I currently have access to is
>> n3035, dated 2010-02-16.
>
> That's rather old, I believe N3225 was the last draft (Like C11, the 
> actual standard is still overpriced).

N3290 was newer, but it's no longer available.

The C++11 standard is now available for $30 from the ANSI store:

http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+14882-2012

They're still charging $285 for the C11 standard ($228 if you're a
member); my understanding is that that should drop to $30 as soon as
ANSI officially adopts ISO C11 as an ANSI standard.

(If you think $30 is still overpriced, I won't argue with you.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20215

FromJames Kuyper <jameskuyper@verizon.net>
Date2012-05-02 07:29 -0400
Message-ID<jnr5r2$cau$1@dont-email.me>
In reply to#20206
On 05/02/2012 01:52 AM, Ian Collins wrote:
> On 05/ 2/12 09:14 AM, James Kuyper wrote:
...
>> The latest draft of the C++ standard that I currently have access to is
>> n3035, dated 2010-02-16.
> 
...
>> In section C, it describes differences between C and C++. In section
>> C.1.5 it says "The keyword auto cannot be used as a storage class
>> specifier.". The rationale for this change is given as "Allowing the use
>> of auto to deduce the type of a variable from its initializer results in
>> undesired interpretations of auto as a storage class specifier in
>> certain contexts." It cites section 7.1.6.4, which describes the 'auto'
>> type specifier, as the basis for this prohibition.
>>
>> In section 7.1.6.4p5 it says "A program that uses auto in a context not
>> explicitly allowed in this section is ill-formed.". I found no mention,
>> in that section, of using 'auto' with the meaning it has in C, only the
>> new meaning that it has in C++.
> 
> That's why it gets a mention in the compatibility section!

Well, yes. Since section C is only informative, not normative, I was
trying to explain precisely why what it says in C.1.5 is in fact a
correct description of the normative text. In my experience, what C.1.5
says is occasionally less accurate than it could be, particularly in
it's explanation of the C side of C/C++ differences.
-- 
James Kuyper

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

#20156

FromRui Maciel <rui.maciel@gmail.com>
Date2012-05-01 12:19 +0100
Message-ID<jnogr3$7ur$1@speranza.aioe.org>
In reply to#20055
Rui Maciel wrote:

> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?

Here are a couple of suggestions:

- namespaces
They aren't necessarily required to write software, but they are handy and, 
depending on how they are implemented, they may be able to solve a 
considerable number of problems.  Let's consider a namespace implementation 
which provides a way for a programmer to specify a prefix to be used 
implicitly in declarations and definitions, and that lets programmers 
specify a set of identifier prefixes that are taken into accoun when parsing 
identifiers.  For example, consider the following declaration:

<code>
namespace foo
{
	int bar(void);
}
</code>

That would be equivalent to the following declaration:
<code>
int foo_bar(void);
</code>


then, with this declaration, the following code would be valid:
<code>
int main(void)
{
	using namespace foo;
	bar(void);

	return 0;
}
</code>

...which would be equivalent to:
<code>
int main(void)
{
	foo_bar(void);

	return 0;
}
</code>

Any ambiguity regarding the use of specific namespace prefixes would be 
signaled as a compiler error.  So, for example, the following code would 
fail to compile:
<code>
namespace foo
{
	int bar(void)
	{
		return some_constant;
	}
}

namespace baz
{
	int bar(void)
	{
		return some_other_constant;
	}
}

int main(void)
{
	using namespace foo, baz;
	foo_bar(void);	// good
	baz_bar(void);	// also good
	bar(void);		// compiler error: ambiguous identifier

	return 0;
}
</code>

This, inadvertently, would provide a way to add polymorphism to C, in a way 
which I believe is better than C11's generic.  For example:

<code>
namespace foo
{
	namespace int
	{
		bar(int);	// this would define foo_int_bar(int)
	}
	namespace float
	{
		bar(float);	// this would define foo_float_bar(float)
	}
	
	// The following would automatically include nested namespaces
	using namespace int, float;
}

int main(void)
{
	using namespace foo;	// this includes foo_int and foo_float
	bar(1);	// calls foo_int_bar(int)
	bar(1.0f);	// calls foo_float_bar(float)
	return 0;
}
</code>

Although the keyword "namespace" has been used in this example, any other 
keyword would do.  Maybe it would be better to use some other keyword such 
as "prefix", to avoid any compatibility problem with C++'s namespaces.


- include the standard library in a dedicated namespace.
There are some issues affecting C's standard library, and yet there is no 
way to fix them without breaking backward compatibility.  One way to avoid 
that mistake would be to include each version of the standard library in a 
dedicated namespace that would explicitly reflect the standard version.  For 
example:

<code>
#include <stdio.h>	
/* with C11, this could include c89/stdio.h, c99/stdio.h and c11/stdio.h, 
each one reflecting the standard library as defined by each standard. Each 
header would, in turn, enclose every definition in a dedicated namespace, 
similar to:

namespace std
{
	namespace c89 
	{
		// ...
	}
	namespace c99 
	{
		// ...
	}
	namespace c11 
	{
		// ...
	}
}
*/

int main(void)
{
	using namespace std;	// in a C11 implementation this would 
actually include namespace std and std_c11

	char *buffer;
	// some stuff happens
	gets(buffer);	// oops, compiler error. There is no such 
thing as a gets() in C11's standard library.
	std_c99_gets(buffer);	// but this function would be defined
	c99_gets(buffer);	// this would also be ok

	return 0;
}
</code>



Rui Maciel

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

Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13  Next page →

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

csiph-web