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

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

C Code Quality

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

Contents

  C Code Quality bartc <bc@freeuk.com> - 2017-05-26 01:01 +0100
    Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 03:18 +0100
      Re: C Code Quality "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-05-25 20:03 -0700
      Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-26 06:32 +0100
      Re: C Code Quality Richard Heathfield <rjh@cpax.org.uk> - 2017-05-26 07:24 +0100
      Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 11:33 +0100
        Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 15:16 +0200
          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 14:40 +0100
            Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:42 +0200
              Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:42 +0200
                Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:46 +0200
                  Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:09 +0200
                    Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 19:48 +0200
                Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 12:05 -0400
                  Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:10 +0200
                    Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 13:16 -0400
                      Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 02:18 +0200
                        Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 10:07 +0000
                          Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 12:21 +0200
                            Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 12:00 +0000
                              Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 14:23 +0200
                                Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 10:57 -0400
                                  Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:16 +0200
                                    Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 16:53 -0400
                                Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 15:23 +0000
                                  Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:25 +0200
                          Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 14:13 +0100
                            Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-29 14:48 +0100
                            Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:14 +0200
                              Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 16:57 -0400
                                Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 23:44 +0200
                                  Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 19:14 -0400
                                    Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 02:57 +0200
                                      Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 22:23 -0400
                                    Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-30 06:54 +0100
                                Re: C Code Quality asetofsymbols@gmail.com - 2017-05-29 15:06 -0700
                                  Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 00:23 +0200
                                    Re: C Code Quality asetofsymbols@gmail.com - 2017-05-29 15:33 -0700
                                    Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 19:15 -0400
                                      Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 02:55 +0200
                                        Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 22:24 -0400
                                    Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 15:24 -0700
                                      Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 00:48 +0200
                              Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:04 -0700
                                Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-30 14:21 +0000
                                Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 17:31 +0200
                                Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 17:48 +0200
                                Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:07 +0000
                                  Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-05 13:10 -0700
                          Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-30 23:46 +0200
                            Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:09 +0000
                Re: C Code Quality supercat@casperkitty.com - 2017-05-26 09:09 -0700
                  Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:11 +0200
                Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:18 +0200
                  Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 02:59 +0200
                    Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-27 14:52 +0200
                    Re: C Code Quality supercat@casperkitty.com - 2017-05-27 13:51 -0700
                      Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 22:36 +0100
                        Re: C Code Quality supercat@casperkitty.com - 2017-05-28 09:38 -0700
                Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-26 20:31 +0200
                  Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 19:47 +0100
                    Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-26 21:50 +0200
                      Re: C Code Quality supercat@casperkitty.com - 2017-05-26 13:06 -0700
                        Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 21:28 +0100
                        Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 23:46 +0100
            Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:22 +0200
              Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:32 +0200
                Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:07 +0200
                  Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 19:40 +0200
            Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:26 -0700
        Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 14:29 +0100
          Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:44 +0200
            Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:32 -0700
            Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 18:47 +0100
              Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:27 +0200
            Re: C Code Quality supercat@casperkitty.com - 2017-05-26 11:24 -0700
              Re: C Code Quality Ike Naar <ike@iceland.freeshell.org> - 2017-05-28 07:25 +0000
          Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:44 +0200
            Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:31 +0100
            Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-05-26 09:52 -0700
              Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:29 +0200
                Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 14:41 -0400
        Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:22 -0700
          Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-26 16:26 +0000
            Re: C Code Quality supercat@casperkitty.com - 2017-05-26 10:06 -0700
            Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:37 +0200
              Re: C Code Quality supercat@casperkitty.com - 2017-05-26 12:24 -0700
        Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-27 02:03 +0100
        Re: C Code Quality Noob <root@127.0.0.1> - 2017-05-28 00:07 +0200
          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 23:51 +0100
          Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-28 10:52 +0100
            Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 16:03 +0200
    Re: C Code Quality Philip Lantz <prl@canterey.us> - 2017-05-25 20:37 -0700
    Re: C Code Quality Philip Lantz <prl@canterey.us> - 2017-05-25 20:42 -0700
    C Code Quality asetofsymbols@gmail.com - 2017-05-25 23:58 -0700
    Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 12:53 +0200
      Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 12:32 +0100
        Re: C Code Quality mark.bluemel@gmail.com - 2017-05-26 06:21 -0700
        Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 15:25 +0200
          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 15:00 +0100
            Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:50 +0200
              Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:14 +0200
              Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:24 +0100
                Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-26 16:46 +0000
                Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:47 +0200
                  Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 19:31 +0100
              Re: C Code Quality Noob <root@127.0.0.1> - 2017-05-27 10:52 +0200
                Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-28 18:57 +0200
                  Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-28 20:00 +0100
                    Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-05-29 07:34 +1200
                    Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-29 11:32 +0200
                      Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 12:37 +0100
                        Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-29 14:01 +0200
                          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 13:47 +0100
                        Re: C Code Quality Reinhardt Behm <rbehm@hushmail.com> - 2017-05-29 20:15 +0800
                          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 14:23 +0100
                        Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-29 17:36 +0200
                          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 17:01 +0100
                            Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 07:05 -0700
                              Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-30 17:18 +0200
                                Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-30 21:31 +0200
                                  Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 12:49 -0700
                                    Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 13:52 -0700
                                    Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 12:55 +0200
                                      Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 13:15 +0100
                                        Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 05:42 -0700
                                          Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 15:40 +0100
                                            Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 10:52 -0700
                                            Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 00:00 +0100
                                              Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 01:11 +0100
                                                Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 02:21 +0100
                                                  Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-06-01 10:37 +0200
                                                    Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 11:28 +0100
                                                  Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 10:55 +0100
                                              Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 12:43 +0100
                                                Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 13:03 +0100
                                                  Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 14:44 +0100
                                                    Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-06-06 14:58 +0000
                                                      Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 17:23 +0100
                                                    Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 17:23 +0100
                                                  Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 17:14 +0000
                                                Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 16:54 +0000
                                                  Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 18:49 +0100
                                                    Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 18:28 +0000
                                                    Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-16 15:28 +0000
                                      Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 05:21 -0700
                                        Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 15:22 +0200
                                          Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 06:59 -0700
                                            Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 17:18 +0200
                                              Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 10:24 -0700
                                                Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:22 -0700
                                                  Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 22:32 +0100
                                                    Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 23:08 +0100
                                                      Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:22 +0200
                                                      Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 00:54 +0100
                                                        Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:00 -0700
                                                          Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 09:12 -0700
                                                            Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 10:09 -0700
                                                              Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 10:11 -0700
                                                      Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:31 -0700
                                                    Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:27 -0700
                                                      Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 11:04 +0100
                                                        Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:57 -0700
                                                          Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 12:05 -0700
                                                            Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-01 15:39 -0400
                                                            Re: C Code Quality supercat@casperkitty.com - 2017-06-01 13:39 -0700
                                                              Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 14:19 -0700
                                                                Re: C Code Quality supercat@casperkitty.com - 2017-06-01 16:33 -0700
                                                            Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:22 -0700
                                                              Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 17:44 -0700
                                                                Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-02 02:56 +0100
                                                          Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 21:24 +0100
                                                    Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:13 -0700
                                                      Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 14:01 +0100
                                                        Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 06:53 -0700
                                                          Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 15:13 +0100
                                                            Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 08:40 -0700
                                                              Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 17:18 +0100
                                                                Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 14:56 -0700
                                                Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-06-01 07:35 +1200
                                                Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-06-01 10:41 +0200
                                          Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:14 +0200
                                            Re: C Code Quality Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-31 09:02 -0700
                                              Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 19:45 +0200
                                            Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:17 +0000
                              Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-30 16:32 +0100
                                Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 12:38 -0700
                                  Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 13:00 -0700
                                  Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-06-02 10:58 -0700
                              Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-30 19:56 +0000
                                Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 23:06 +0100
                                  Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-30 23:02 +0000
                                    Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 04:14 +0100
                                      Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-31 08:38 +0000
                          Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-05-30 15:22 +1200
              Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 10:12 +0000
            Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 18:03 +0200
              Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:45 +0100
              Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 20:05 +0100
                Re: C Code Quality supercat@casperkitty.com - 2017-05-26 12:42 -0700
              Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 20:19 +0100
                Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 03:03 +0200
                  Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-05-26 20:37 -0700
            Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:17 -0700
    Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:15 -0700

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

#110753

On 26/05/2017 19:31, Patrick.Schluter wrote:
> Le 26.05.2017 à 17:42, Pascal J. Bourguignon a écrit :

>> Perhaps the correct implementation, instead of this kludge, would be to
>> write a specific pre-processor that would interpret those extensions to
>> the language.
>>
>
> Use the D language in that case. It has removed the pre-processor and
> replaced it with a very powerful template system (much better than C++
> one) and also provides CTFE (compile time function evaluation). The
> mixin feature, combined with "static if" allows for really neat compile
> time introspection.
> Here just a little example to show what is possible with string mixins
>
> string LanIdx2Lan(LANIDX lan)
> {
>   switch(lan) {
>     foreach(e; __traits(allMembers, LANIDX))
>     static if(e != "sh")
>       mixin(`case LANIDX.`~e~`: return "`~e~`";`);
>     default: return "LANIDX.UNDEFINED";
>   }
> }
>
> LANIDX is an enum defining ISO-639-1 language codes
> enum LANIDX { en, de, hr, sh=hr, hu } for example (in my real code there
> are 41 different codes).
>
> What that function above does is take all members of the enum type, loop
> over it and generates the switch()/case to transform the enum value to
> its string representation.
> The static if says to skip the enum entry sh as it has the same value as
> another entry and it would generate a collision.
>
> The function above is strictly equivalent to
>
> string LanIdx2Lan(LANIDX lan)
> {
>   switch(lan) {
>     case LANIDX.en: return "en";
>     case LANIDX.de: return "de";
>     case LANIDX.hr: return "hr";
>     case LANIDX.hu: return "hu";
>     default: return "LANIDX.UNDEFINED";
>   }
> }
>
> only that the very tedious listing of cases has been generated by the
> compiler.

What does the reader see, this last switch or the first one?

Because the one with all the possibilities spelled out is a lot clearer! 
(And usually you'd want different handling code for various sets of 
cases anyway.)

-- 
bartc

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

#110758

Le 26.05.2017 à 20:47, bartc a écrit :
> On 26/05/2017 19:31, Patrick.Schluter wrote:
>> Le 26.05.2017 à 17:42, Pascal J. Bourguignon a écrit :
> 
>>> Perhaps the correct implementation, instead of this kludge, would be to
>>> write a specific pre-processor that would interpret those extensions to
>>> the language.
>>>
>>
>> Use the D language in that case. It has removed the pre-processor and
>> replaced it with a very powerful template system (much better than C++
>> one) and also provides CTFE (compile time function evaluation). The
>> mixin feature, combined with "static if" allows for really neat compile
>> time introspection.
>> Here just a little example to show what is possible with string mixins
>>
>> string LanIdx2Lan(LANIDX lan)
>> {
>>   switch(lan) {
>>     foreach(e; __traits(allMembers, LANIDX))
>>     static if(e != "sh")
>>       mixin(`case LANIDX.`~e~`: return "`~e~`";`);
>>     default: return "LANIDX.UNDEFINED";
>>   }
>> }
>>
>> LANIDX is an enum defining ISO-639-1 language codes
>> enum LANIDX { en, de, hr, sh=hr, hu } for example (in my real code there
>> are 41 different codes).
>>
>> What that function above does is take all members of the enum type, loop
>> over it and generates the switch()/case to transform the enum value to
>> its string representation.
>> The static if says to skip the enum entry sh as it has the same value as
>> another entry and it would generate a collision.
>>
>> The function above is strictly equivalent to
>>
>> string LanIdx2Lan(LANIDX lan)
>> {
>>   switch(lan) {
>>     case LANIDX.en: return "en";
>>     case LANIDX.de: return "de";
>>     case LANIDX.hr: return "hr";
>>     case LANIDX.hu: return "hu";
>>     default: return "LANIDX.UNDEFINED";
>>   }
>> }
>>
>> only that the very tedious listing of cases has been generated by the
>> compiler.
> 
> What does the reader see, this last switch or the first one?
> 
The first form is what is in the source file. I've showed the second 
form only for illustration.

> Because the one with all the possibilities spelled out is a lot clearer! 
> (And usually you'd want different handling code for various sets of 
> cases anyway.)

My example showed only for 4 values, in my real code there are 41 
values. I gave also only one of the transformations function, in my real 
project there are 4 different transformations using switch/case and 
another enum which values are constructed from the values of this enum. 
There are also 7 lookup tables which entries derive from the enunm.
The fun part is that the initial project is in C and there it is half a 
day of work when I have to add or remove an entry in that enum.
The C code I use at work is around 300 lines header and 400 lines C 
code. The D program using the same values and transformations are around 
100 lines (of which 50 are used to define the one and only enum from 
which everything else is derived).
So, the big difference is: if I add a value in my enum. In D I'm 
finished as all other functions, enums and table are generated at 
compile time from it. In C, I have to edit the 4 functions with 
switch/case, update the other enum and update the different lookup 
tables. Checking and rechecking to make sure I haven't forgotten 
something. Tedious work in which more than once, errors were introduced 
(incidentaly the sh=hr in the enum came from one of these inconsistent 
edition some years ago and now I'm stuck with it).

So there are sometimes more important criteria to code than the 
necessity to write it in a way that even the last noob can understand it.

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

#110760

On Friday, May 26, 2017 at 2:50:46 PM UTC-5, Patrick.Schluter wrote:
> So, the big difference is: if I add a value in my enum. In D I'm 
> finished as all other functions, enums and table are generated at 
> compile time from it. In C, I have to edit the 4 functions with 
> switch/case, update the other enum and update the different lookup 
> tables. Checking and rechecking to make sure I haven't forgotten 
> something. Tedious work in which more than once, errors were introduced 
> (incidentaly the sh=hr in the enum came from one of these inconsistent 
> edition some years ago and now I'm stuck with it).

In C, it is possible to arrange things so that a single #define of the form

#define ALL_STOOGES \
   STOOGE(MOE) \
   STOOGE(LARRY) \ 
   STOOGE(CURLY) \ 
   STOOGE(SHEMP) \ 
   STOOGE(JOE) \ 
   // Leave this line blank

followed by some "magic", will automatically define a variety of compile-
time symbols, e.g. compile-time constants

   STOOGE_MOE_INDEX == 0
   STOOGE_CURLY_MASK == 4 (i.e. 1<<2)
   NUM_STOOGES == 5

as well as objects like

   char * STOOGE_NAMES[5] = {"MOE", "LARRY", "CURLY", "SHEMP", "JOE"};

etc.  The stuff after the definition, that makes everything work, is ugly,
but all of the identifiers are automatically synchronized to the list of
stooges.

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

#110761

On 26/05/2017 21:06, supercat@casperkitty.com wrote:
> On Friday, May 26, 2017 at 2:50:46 PM UTC-5, Patrick.Schluter wrote:
>> So, the big difference is: if I add a value in my enum. In D I'm
>> finished as all other functions, enums and table are generated at
>> compile time from it. In C, I have to edit the 4 functions with
>> switch/case, update the other enum and update the different lookup
>> tables. Checking and rechecking to make sure I haven't forgotten
>> something. Tedious work in which more than once, errors were introduced
>> (incidentaly the sh=hr in the enum came from one of these inconsistent
>> edition some years ago and now I'm stuck with it).
>
> In C, it is possible to arrange things so that a single #define of the form
>
> #define ALL_STOOGES \
>    STOOGE(MOE) \
>    STOOGE(LARRY) \
>    STOOGE(CURLY) \
>    STOOGE(SHEMP) \
>    STOOGE(JOE) \
>    // Leave this line blank
>
> followed by some "magic", will automatically define a variety of compile-
> time symbols, e.g. compile-time constants
>
>    STOOGE_MOE_INDEX == 0
>    STOOGE_CURLY_MASK == 4 (i.e. 1<<2)
>    NUM_STOOGES == 5
>
> as well as objects like
>
>    char * STOOGE_NAMES[5] = {"MOE", "LARRY", "CURLY", "SHEMP", "JOE"};
>
> etc.  The stuff after the definition, that makes everything work, is ugly,
> but all of the identifiers are automatically synchronized to the list of
> stooges.

For stuff like this, my non-C language uses this feature (I've added the 
dummy weights column to make a better example):

  global tabledata() []ichar typequalnames, []int weights =
     (const_qual,    $,      10),
     (volatile_qual, $,      20),
     (restrict_qual, $,      30),
     (atomic_qual,   $,      40)
  end

When converted to C, it generates the following definitions:

  enum {const_qual = 1};
  enum {volatile_qual = 2};
  enum {restrict_qual = 3};
  enum {atomic_qual = 4};

  char * typequalnames[4]={"const_qual","volatile_qual",
                           "restrict_qual","atomic_qual"};

  int32  weights[4]={10,20,30,40};

So all always in-sync too. And no macros needed.

(The "$" turns the last enum name into a string; 'global' makes this 
data available to other modules without needing to put it into a header.

In generated multiple C files, which don't use headers, the enums are 
duplicated in each file, but the arrays are non-initialised externs in 
all but their 'home' module.)

-- 
bartc

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

#110766

On 26/05/2017 21:06, supercat@casperkitty.com wrote:
> On Friday, May 26, 2017 at 2:50:46 PM UTC-5, Patrick.Schluter wrote:
>> So, the big difference is: if I add a value in my enum. In D I'm
>> finished as all other functions, enums and table are generated at
>> compile time from it. In C, I have to edit the 4 functions with
>> switch/case, update the other enum and update the different lookup
>> tables. Checking and rechecking to make sure I haven't forgotten
>> something. Tedious work in which more than once, errors were introduced
>> (incidentaly the sh=hr in the enum came from one of these inconsistent
>> edition some years ago and now I'm stuck with it).
>
> In C, it is possible to arrange things so that a single #define of the form
>
> #define ALL_STOOGES \
>    STOOGE(MOE) \
>    STOOGE(LARRY) \
>    STOOGE(CURLY) \
>    STOOGE(SHEMP) \
>    STOOGE(JOE) \
>    // Leave this line blank
>
> followed by some "magic", will automatically define a variety of compile-
> time symbols, e.g. compile-time constants
>
>    STOOGE_MOE_INDEX == 0
>    STOOGE_CURLY_MASK == 4 (i.e. 1<<2)
>    NUM_STOOGES == 5
>
> as well as objects like
>
>    char * STOOGE_NAMES[5] = {"MOE", "LARRY", "CURLY", "SHEMP", "JOE"};
>
> etc.  The stuff after the definition, that makes everything work, is ugly,
> but all of the identifiers are automatically synchronized to the list of
> stooges.

This is an example along these lines from the project I'm testing at the 
minute. Look the enum def below:

/* Metamethods. */
#define MMDEF(_) \
   _(index) _(newindex) _(gc) _(mode) _(eq) \
   /* Only the above (fast) metamethods are negative cached (max. 8). */ \
   _(len) _(lt) _(le) _(concat) _(call) \
   /* The following must be in ORDER ARITH. */ \
   _(add) _(sub) _(mul) _(div) _(mod) _(pow) _(unm) \
   /* The following are used in the standard libraries. */ \
   _(metatable) _(tostring)

typedef enum {
#define MMENUM(name)    MM_##name,
MMDEF(MMENUM)
#undef MMENUM
   MM_MAX,
   MM____ = MM_MAX,
   MM_FAST = MM_eq
} MMS;

All this faffing around is so that the following enums get defined (-E 
expansion shown):

typedef enum {
MM_index, MM_newindex, MM_gc, MM_mode, MM_eq, MM_len, MM_lt, MM_le, 
MM_concat, MM_call, MM_add, MM_sub, MM_mul, MM_div, MM_mod, MM_pow, 
MM_unm, MM_metatable, MM_tostring,
   MM_MAX,
   MM____ = MM_MAX,
   MM_FAST = MM_eq
} MMS;

I think the point of this is so that later on, MMDEF can be used in just 
one more place to do this:

  #define MMNAME(name)    "__" #name
    const char *metanames = MMDEF(MMNAME);
  #undef MMNAME

Which I guess is to have a list of names of those enums**.

The whole thing looks awful. I think there are better ways to handle it 
if macros have to be used, But I would have done it without macros in 
the interests of clarity.

(** No point in guessing. The -E expansion is:

   const char *metanames = "__" "index" "__" "newindex" "__" "gc" "__" 
"mode" "__" "eq" "__" "len" "__" "lt" "__" "le" "__" "concat" "__" 
"call" "__" "add" "__" "sub" "__" "mul" "__" "div" "__" "mod" "__" "pow" 
"__" "unm" "__" "metatable" "__" "tostring";

So the macros are doing a good job of hiding what is actually in the code.)


-- 
bartc

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

#110711

bartc <bc@freeuk.com> writes:

> On 26/05/2017 14:16, David Brown wrote:
>> On 26/05/17 12:33, bartc wrote:
>
>> Yes.  Really, Bart, this is not only pretty clear, but it is a very
>> common technique.
>
> I'm sorry, but it stinks. This is abuse of the language.

If the language is abused so commonly, it's because it is so lacking in
features that are needed by the users!

Why compilation-time asserts weren't available?
Why had we to wait until 2011 to get them?
(When in other programming languages they've been available for-ever,
eg. in Common Lisp you'd just do
   (eval-when (:compile-toplevel) (assert <expression>))
).



> Maybe you are used to these dodgy, underhand techniques, but I'm not.
>
>> C11 (synchronous with C++11)
>> introduced _Static_assert to do the same job without this hack, and with
>> a nicer error message.
>
> Is that the same thing I've just invented myself and added within the
> last 20 minutes? It'll save some effort later on then! But it hasn't
> taken me 40 years to get around to it...
>
>>> Is this considered good coding practice? Apparently so.
>>
>> Yes - the minimal compiler cost of all these unused (and non-existent)
>> functions is tiny compared to the benefits of static assertions.
>
> Having a low overhead doesn't make it good!

Of course, it's a kludge.  But what else can be done by users of a
language that cannot be improved by the users themselves, (like,
eg. Common Lisp), but for which the users have to wait years for
commitees to decide to add new features, and then years for compiler
writers to implement them.  Why didn't you implement _Static_assert
already?  Or choose to implement a saner programming language?

In the meantime, users will continue writing kludge, because all kinds
of language features and meta-programming is needed, even if they don't
know it yet.


>> It is fine that a compiler in development can only handle some kinds of
>> code.  But if you can't handle normal C code like other compilers, then
>> the fault is the half-finished nature of your compiler, not the C code
>> in question!
>
> Well, if the limitations of my compiler encourage a better style of
> coding, then that is a good thing isn't it?

Indeed, you can implement a saner subset of C, for civilized C
programmers.  The only problem is that you still want to compile C code
found in the wild, written by savages :-)


> Except that enough still works to do some scary preprocessor stuff.

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#110716

On Fri, 26 May 2017 17:22:14 +0200
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> Indeed, you can implement a saner subset of C, for civilized C
> programmers.  The only problem is that you still want to compile C code
> found in the wild, written by savages :-)

He should have the french gene, never do the same as your neighbor but do it
unique and worse! :o)

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

#110736

GOTHIER Nathan <nathan.gothier@gmail.com> writes:

> On Fri, 26 May 2017 17:22:14 +0200
> "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
>
>> Indeed, you can implement a saner subset of C, for civilized C
>> programmers.  The only problem is that you still want to compile C code
>> found in the wild, written by savages :-)
>
> He should have the french gene, never do the same as your neighbor but do it
> unique and worse! :o)

If it was worse, US corporations wouldn't keep buying out French
companies.

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#110742

On Fri, 26 May 2017 19:07:34 +0200
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> If it was worse, US corporations wouldn't keep buying out French
> companies.

US investors only want to pump dividends from french companies that's all. They
don't care about the quality of products made by and sold to nationalist peons.
French exports in the US are insignificants and only thrive in the world via
so-called ex-colonies.

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

#110713

On Friday, May 26, 2017 at 8:40:39 AM UTC-5, Bart wrote:
> On 26/05/2017 14:16, David Brown wrote:
> > Yes - the minimal compiler cost of all these unused (and non-existent)
> > functions is tiny compared to the benefits of static assertions.
> 
> Having a low overhead doesn't make it good!

The first time a function prototype is encountered requires a compiler to
create a symbol table entry and attach a list of parameters.  Subsequent
occurrences of the same prototype require a compiler to ensure that the
parameters match, but do not require that the compiler allocate any
additional storage.  No occurrences of the prototype require a compiler to
generate any code or allocate any storage within the target application.

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

#110700

On 26/05/2017 11:33, bartc wrote:

>>> LJ_STATIC_ASSERT(offsetof(Node, val) == 0);

> Presumably it's trying to force an error, and doing that by means of
> attempting to define a function with an illegal array length as
> parameter. But if there is no error, then it just declares a meaningless
> function, of an imported function that is never used.
>
> So a successful compile would have hundreds of these useless functions.
>
> Is this considered good coding practice? Apparently so.

I've just added such an assert feature to the version of the C language 
that I compile. It's used like this:

  MCC_ASSERT(sizeof(int)==4,"int size error");

The given message is shown when the const expression in the first part 
has value 0.

I started at 2.08 and got the above working at 2.17, about ten minutes. 
(For file-scope only; perhaps 5 more minutes to allow it within 
functions too, but within the LJ project it seemed to used at file scope.)

So, no mysterious macros, no generating hundreds of anonymous functions 
- complete with pointer-array parameters of length 1 - as a by-product 
of doing these checks.

(I assume there are reasons why a normal assert() can't be used, but 
I've never used it so wouldn't know.)

-- 
bartc

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

#110706

On 26/05/17 15:29, bartc wrote:
> On 26/05/2017 11:33, bartc wrote:
> 
>>>> LJ_STATIC_ASSERT(offsetof(Node, val) == 0);
> 
>> Presumably it's trying to force an error, and doing that by means of
>> attempting to define a function with an illegal array length as
>> parameter. But if there is no error, then it just declares a meaningless
>> function, of an imported function that is never used.
>>
>> So a successful compile would have hundreds of these useless functions.
>>
>> Is this considered good coding practice? Apparently so.
> 
> I've just added such an assert feature to the version of the C language
> that I compile. It's used like this:
> 
>  MCC_ASSERT(sizeof(int)==4,"int size error");
> 
> The given message is shown when the const expression in the first part
> has value 0.
> 
> I started at 2.08 and got the above working at 2.17, about ten minutes.
> (For file-scope only; perhaps 5 more minutes to allow it within
> functions too, but within the LJ project it seemed to used at file scope.)
> 
> So, no mysterious macros, no generating hundreds of anonymous functions
> - complete with pointer-array parameters of length 1 - as a by-product
> of doing these checks.

And no compatibility with existing compilers, or existing C standards,
and breaking the rules for the use of identifiers.

If you want to implement _Static_assert from C11, why not call it
_Static_assert ?

> 
> (I assume there are reasons why a normal assert() can't be used, but
> I've never used it so wouldn't know.)
> 

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

#110714

On Friday, May 26, 2017 at 9:45:01 AM UTC-5, David Brown wrote:
> On 26/05/17 15:29, bartc wrote:
> > I've just added such an assert feature to the version of the C language
> > that I compile. It's used like this:
> > 
> >  MCC_ASSERT(sizeof(int)==4,"int size error");
> And no compatibility with existing compilers, or existing C standards,
> and breaking the rules for the use of identifiers.
> 
> If you want to implement _Static_assert from C11, why not call it
> _Static_assert ?

Nowadays one may as well use the name _Static assert, though if the name
were preceded by an underscore and were part of a package which could be
implemented on any compiler using a header file, but could be handled by
intrinsics in MCC, I think _MCC_ASSERT would be perfectly reasonable.  Not
all compilers natively support _Static_assert, and a header file should
only define _Static_assert as a macro if that header exists to serve as
a substitute for a C11 header, rather than as a means of defining other
macros.

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

#110743

On 26/05/2017 15:44, David Brown wrote:
> On 26/05/17 15:29, bartc wrote:

>> I've just added such an assert feature to the version of the C language
>> that I compile. It's used like this:
>>
>>  MCC_ASSERT(sizeof(int)==4,"int size error");
>>
>> The given message is shown when the const expression in the first part
>> has value 0.

>> So, no mysterious macros, no generating hundreds of anonymous functions
>> - complete with pointer-array parameters of length 1 - as a by-product
>> of doing these checks.
>
> And no compatibility with existing compilers, or existing C standards,
> and breaking the rules for the use of identifiers.
>
> If you want to implement _Static_assert from C11, why not call it
> _Static_assert ?

Because I'd never heard of it? (It's in the standard, but it's one of 
those uninteresting features I pay little attention to.)

But, since what I came up with seems to be exactly the same, I've now 
changed the name to _Static_assert, and made it work inside functions.

However, using _Static_assert will lose compatibility with lccwin, DMC, 
Tiny C and old MSVC (I assume new MSVC has it). A similar problem to 
what you said was wrong with my version.

-- 
bartc

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

#110747

On 26/05/17 19:47, bartc wrote:
> On 26/05/2017 15:44, David Brown wrote:
>> On 26/05/17 15:29, bartc wrote:
> 
>>> I've just added such an assert feature to the version of the C language
>>> that I compile. It's used like this:
>>>
>>>  MCC_ASSERT(sizeof(int)==4,"int size error");
>>>
>>> The given message is shown when the const expression in the first part
>>> has value 0.
> 
>>> So, no mysterious macros, no generating hundreds of anonymous functions
>>> - complete with pointer-array parameters of length 1 - as a by-product
>>> of doing these checks.
>>
>> And no compatibility with existing compilers, or existing C standards,
>> and breaking the rules for the use of identifiers.
>>
>> If you want to implement _Static_assert from C11, why not call it
>> _Static_assert ?
> 
> Because I'd never heard of it? (It's in the standard, but it's one of
> those uninteresting features I pay little attention to.)

How can you claim never to have heard of it?  I had mentioned it several
times before you implemented it.  And if you are making a C compiler,
you /read/ the standard.  /All/ of the standard.  Not just bits of it,
or things that sound fun, or old versions.

> 
> But, since what I came up with seems to be exactly the same, I've now
> changed the name to _Static_assert, and made it work inside functions.
> 
> However, using _Static_assert will lose compatibility with lccwin, DMC,
> Tiny C and old MSVC (I assume new MSVC has it). A similar problem to
> what you said was wrong with my version.
> 

If those compilers have extensions that provide the same feature under a
different name, then it can certainly make sense to add support for them
as an extension - but it does not make sense to use /only/ a
non-standard name when a standard one exists.

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

#110746

On Friday, May 26, 2017 at 9:45:01 AM UTC-5, David Brown wrote:
> And no compatibility with existing compilers, or existing C standards,
> and breaking the rules for the use of identifiers.

If an implementation writer wants his implementation to define identifiers
when an implementation-supplied header file is included, but not otherwise,
and wants code employing those identifiers to be usable on other systems if
it includes a "compatibility" header file, which naming standard should it
use:

1. Use names with a non-underscore prefix that is unlikely to appear in
   user code, and specify that code which includes the header must not
   use that prefix for other purposes.

2. Use names with an underscore prefix, which would be guaranteed not
   to conflict with any user code running on that writer's implementation,
   but might cause compatibility with other systems if they conflict with
   names declared thereon.

As far as the Standard is concerned, if code uses #include <acme.h>, a
compiler would be allowed to do anything it likes with it, so defining
names in the user namespace should be permissible.  What advantages or
disadvantages do you see to each approach?

As a simple example, suppose a compiler has an intrinsic called
__ACME_INTRINSIC_EITHER(x,y) which will be equivalent to either x or y,
chosen in Unspecified fashion.  Given code like:

    z = __ACME_INTRINSIC_EITHER_VALUE(
          x << (y & 31), 
          (x <= 31) ? x<<y : 0
        );

a compiler would be free to generate a shift-left instruction for both
ARM cores (where x<<33 would naturally yield zero) and x86 cores (where
it would yield x<<1).  If the convention is that a compiler should pick
the first absent any reason to favor the second, the header file could
say

    #ifdef __ACME_INTRINSIC_SUPPORTS_EITHER_VALUE
    #define whateverprefix_ACC_EITHER_VALUE(x,y) __ACME_INTRINSIC_EITHER_VALUE
    #else
    #define whateverprefix_EITHER_VALUE(x,y) (x)
    #endif

Code which used whateverprefix_EITHER_VALUE() would only benefit from doing
so on compilers with real support for the intrinsic, but use of that feature
should not hurt compatibility with other implementations.

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

#110814

On 2017-05-26, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
>     z = __ACME_INTRINSIC_EITHER_VALUE(
>           x << (y & 31), 
>           (x <= 31) ? x<<y : 0
>         );

Is (x <= 31) a typo for (y <= 31) ?

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

#110718

bartc <bc@freeuk.com> writes:

> On 26/05/2017 11:33, bartc wrote:
>
>>>> LJ_STATIC_ASSERT(offsetof(Node, val) == 0);
>
>> Presumably it's trying to force an error, and doing that by means of
>> attempting to define a function with an illegal array length as
>> parameter. But if there is no error, then it just declares a meaningless
>> function, of an imported function that is never used.
>>
>> So a successful compile would have hundreds of these useless functions.
>>
>> Is this considered good coding practice? Apparently so.
>
> I've just added such an assert feature to the version of the C
> language that I compile. It's used like this:
>
>  MCC_ASSERT(sizeof(int)==4,"int size error");
>
> The given message is shown when the const expression in the first part
> has value 0.

Notice that if #if could be used in macro expansions, we could have
defined those macros as expanding to:

    #if sizeof(int)==4
        /* ok */
    #else
    #   error "int size error"
    #endif

which would have been clean from the start.  But I'm just dreaming of
alternate realities…



> I started at 2.08 and got the above working at 2.17, about ten
> minutes. (For file-scope only; perhaps 5 more minutes to allow it
> within functions too, but within the LJ project it seemed to used at
> file scope.)
>
> So, no mysterious macros, no generating hundreds of anonymous
> functions - complete with pointer-array parameters of length 1 - as a
> by-product of doing these checks.
>
> (I assume there are reasons why a normal assert() can't be used, but
> I've never used it so wouldn't know.)

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#110728

On 26/05/2017 16:44, Pascal J. Bourguignon wrote:
> bartc <bc@freeuk.com> writes:
>
>> On 26/05/2017 11:33, bartc wrote:
>>
>>>>> LJ_STATIC_ASSERT(offsetof(Node, val) == 0);
>>
>>> Presumably it's trying to force an error, and doing that by means of
>>> attempting to define a function with an illegal array length as
>>> parameter. But if there is no error, then it just declares a meaningless
>>> function, of an imported function that is never used.
>>>
>>> So a successful compile would have hundreds of these useless functions.
>>>
>>> Is this considered good coding practice? Apparently so.
>>
>> I've just added such an assert feature to the version of the C
>> language that I compile. It's used like this:
>>
>>  MCC_ASSERT(sizeof(int)==4,"int size error");
>>
>> The given message is shown when the const expression in the first part
>> has value 0.
>
> Notice that if #if could be used in macro expansions, we could have
> defined those macros as expanding to:
>
>     #if sizeof(int)==4
>         /* ok */
>     #else
>     #   error "int size error"
>     #endif
>
> which would have been clean from the start.  But I'm just dreaming of
> alternate realities…

sizeof in #if has been discussed recently, and I remember now I 
implemented it in my experimental C compiler, so this is possible too 
(but for simple types only):

#if sizeof(int)==8
     #message "OK"
#else
     #error "int size error"
#endif

Output (as my ints have 4 bytes):

#ERROR:"int size error"

(#message is another extension used for debugging.)

This is not a serious implementation of C, but it shows how easy some 
features are to add.

-- 
bartc

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

#110734

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> Notice that if #if could be used in macro expansions, we could have
> defined those macros as expanding to:
>
>     #if sizeof(int)==4
>         /* ok */
>     #else
>     #   error "int size error"
>     #endif
>
> which would have been clean from the start.  But I'm just dreaming of
> alternate realities…

The preprocessor doesn't evaluate sizeof.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

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

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

csiph-web