Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110663 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2017-05-26 01:01 +0100 |
| Last post | 2017-05-28 22:15 -0700 |
| Articles | 20 on this page of 205 — 28 participants |
Back to article view | Back to comp.lang.c
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 1 of 11 [1] 2 3 … 11 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-26 01:01 +0100 |
| Subject | C Code Quality |
| Message-ID | <pfKVA.123097$163.89978@fx36.am4> |
I'm of the opinion that C's preprocessor plus its 'anything goes'
approach to writing declarations and such, can lead to poor code that is
very hard to follow.
Most here seem to disagree.
When I was testing my experimental compiler a couple of months back with
100-200Kloc of other people's code and (as far as possible) other
compilers' headers, I thought I'd seen my fair share of brutal code and
it would be plain sailing from then on, but I was mistaken!
The first substantial program I try, I get an error here (code is from
LuaJIT sources):
typedef LJ_ALIGN(8) union TValue {
uint64_t u64; /* 64 bit pattern [comments trimmed]
lua_Number n; /* Number object
struct {
LJ_ENDIAN_LOHI(
GCRef gcr; /* GCobj referenc
, uint32_t it; /* Internal objec
)
};....
What's that LJ_ALIGN? Turns out it is a macro that for gcc is set to
some __attribute(...), and for MSVC to __declspec(...). For any other
compilers, tough luck. (I just set it to empty for now, but there are
other compiler-specific routines which look like they will be needed.)
(As for the ; followed by a comma in the body ... well it seems to
compile so ignore it...)
Next I get an error about VLAs (my compiler doesn't support them), but
I'm still doing headers. The culprit is this line:
LJ_STATIC_ASSERT(offsetof(Node, val) == 0);
Obviously a macro, but looking at it doesn't give any enlightenment:
extern void LJ_ASSERT_NAME(__LINE__)(int
STATIC_ASSERTION_FAILED [(cond)?1:-1])
I guess it's that int something[?:] that gives the VLA error, but
putting that aside, what is this code declaring? Expanding the macro
call using -E gives:
extern void lj_assert_229 ( int
STATIC_ASSERTION_FAILED [
( ( size_t ) & ( ( ( Node * ) 0 ) -> val ) == 0 ) ? 1 : - 1 ] ) ;
Sorry, still no clue. Comment that out for now, and I get an error in
this lot:
typedef enum {
#define MMENUM(name) MM_##name,
MMDEF(MMENUM)
#undef MMENUM
MM_MAX,
MM____ = MM_MAX,
MM_FAST = MM_eq
} MMS;
That's all I need, some PP bug to take care of my weekend! If I switch
to normal compilers, a number of them stumble over this:
static LJ_AINLINE void setlightudV(TValue *o, void *p)
{...
But that's an easy one, LJ_AINLINE expands to this for gcc:
inline __attribute__((always_inline))
Those compilers presumably have __GNUC__ set, in which case they ought
deal with it.
But, there's 40,000 lines of this stuff and I've only just started.
-------------------------------------------------------------
I'm just wondering why some (most?) C code bases are written in such a
horrible way, bristling with macro calls and hairy-looking
constructions. They just HAVE to pull out all the stops and misuse every
possible feature.
My own code just seems so gorgeous in comparison. It doesn't do anything
adventurous, and compiles effortlessly. I wonder which code-base someone
would rather try and understand...
I don't know, I must be much better at C coding than I'd thought! (Or
more likely decades of experience in not using macros.)
--
bartc
[toc] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-26 03:18 +0100 |
| Message-ID | <87mva0s6lp.fsf@bsb.me.uk> |
| In reply to | #110663 |
bartc <bc@freeuk.com> writes:
> I'm of the opinion that C's preprocessor plus its 'anything goes'
> approach to writing declarations and such, can lead to poor code that
> is very hard to follow.
>
> Most here seem to disagree.
I find that hard to believe. Can you cite anyone saying that C's
declaration syntax and pre-processor can not lead to poor code that is
very hard to follow?
> When I was testing my experimental compiler a couple of months back
> with 100-200Kloc of other people's code and (as far as possible) other
> compilers' headers, I thought I'd seen my fair share of brutal code
> and it would be plain sailing from then on, but I was mistaken!
>
> The first substantial program I try, I get an error here (code is from
> LuaJIT sources):
>
> typedef LJ_ALIGN(8) union TValue {
> uint64_t u64; /* 64 bit pattern [comments trimmed]
> lua_Number n; /* Number object
> struct {
> LJ_ENDIAN_LOHI(
> GCRef gcr; /* GCobj referenc
> , uint32_t it; /* Internal objec
> )
> };....
<snip>
> (As for the ; followed by a comma in the body ... well it seems to
> compile so ignore it...)
It obviously delimits the arguments to a macro.
> Next I get an error about VLAs (my compiler doesn't support them), but
> I'm still doing headers. The culprit is this line:
>
> LJ_STATIC_ASSERT(offsetof(Node, val) == 0);
>
> Obviously a macro, but looking at it doesn't give any enlightenment:
>
> extern void LJ_ASSERT_NAME(__LINE__)(int
> STATIC_ASSERTION_FAILED [(cond)?1:-1])
>
> I guess it's that int something[?:] that gives the VLA error,
Are you taking the mickey? You are writing a C compiler and you don't
know what this code is doing?
> but putting that aside, what is this code declaring? Expanding the
> macro call using -E gives:
>
> extern void lj_assert_229 ( int
> STATIC_ASSERTION_FAILED [
> ( ( size_t ) & ( ( ( Node * ) 0 ) -> val ) == 0 ) ? 1 : - 1 ] ) ;
>
> Sorry, still no clue.
It's declaring a function. What else could it be?
The ( size_t ) & ( ( ( Node * ) 0 ) -> val ) == 0 is the expansion of
offsetof(Node, val). The code is ensuring a diagnostic if val is not at
offset 0 in a Node object.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-05-25 20:03 -0700 |
| Message-ID | <87437c00-1d2d-47fa-a818-13324ebb68a0@googlegroups.com> |
| In reply to | #110667 |
Ben, you could be less disrespectful toward Bart, and still help him. You don't have to dip into the hate-laden waters of sidelong passive- aggressive insults. There is another way to be. You'll find it's a much happier, and much nicer way than what you're used to. You should check it out sooner rather than later. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-26 06:32 +0100 |
| Message-ID | <87shjsqj2u.fsf@gmail.com> |
| In reply to | #110667 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> LJ_STATIC_ASSERT(offsetof(Node, val) == 0); >> >> Obviously a macro, but looking at it doesn't give any enlightenment: >> >> extern void LJ_ASSERT_NAME(__LINE__)(int >> STATIC_ASSERTION_FAILED [(cond)?1:-1]) >> >> I guess it's that int something[?:] that gives the VLA error, > > Are you taking the mickey? You are writing a C compiler and you don't > know what this code is doing? That should disqualify you from putting "C programmer" on your resumé, let alone writing a C compiler. Dunning-Kreuger gotta Dunning-Kreuger.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-05-26 07:24 +0100 |
| Message-ID | <og8hgm$5c1$2@dont-email.me> |
| In reply to | #110667 |
On 26/05/17 03:18, Ben Bacarisse wrote: > Are you taking the mickey? You are writing a C compiler and you don't > know what this code is doing? BartC has been taking the mickey out of a good many people here for a substantial period of time. Are you seriously telling me you haven't spotted this? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-26 11:33 +0100 |
| Message-ID | <5wTVA.175619$C56.143023@fx34.am4> |
| In reply to | #110667 |
On 26/05/2017 03:18, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> I'm of the opinion that C's preprocessor plus its 'anything goes' >> approach to writing declarations and such, can lead to poor code that >> is very hard to follow. >> >> Most here seem to disagree. > > I find that hard to believe. Can you cite anyone saying that C's > declaration syntax and pre-processor can not lead to poor code that is > very hard to follow? See below. >> LJ_STATIC_ASSERT(offsetof(Node, val) == 0); >> >> Obviously a macro, but looking at it doesn't give any enlightenment: >> >> extern void LJ_ASSERT_NAME(__LINE__)(int >> STATIC_ASSERTION_FAILED [(cond)?1:-1]) >> >> I guess it's that int something[?:] that gives the VLA error, > > Are you taking the mickey? You are writing a C compiler and you don't > know what this code is doing? >> Sorry, still no clue. > > It's declaring a function. What else could it be? > > The ( size_t ) & ( ( ( Node * ) 0 ) -> val ) == 0 is the expansion of > offsetof(Node, val). The code is ensuring a diagnostic if val is not at > offset 0 in a Node object. /I/ say this is hard to follow. I'm guessing that you find this perfectly reasonable code and therefore implying that it is not a problem. (Maybe that is typical of your own code; I don't know.) 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. Of course, my POV is a little different. If my program can't process a a bit of code, then I HAVE to locate and trudge through all these macros and expansions to find what the bug is. So I will see a lot more ugly code than someone whose compiler just deals with it without a murmur and they never get to see the source. But, compare code which is a pleasure to look at (eg. some of Rick's programs) and to read through, and code like this. Just as bad are the sources to sqlite3 (the one-file version), and the sources to gcc's cc1 program (also the one-file version), where it is a challenge to find a page containing 'straight' C code that doesn't involve the preprocessor. What appears to be emerging is there are two versions of C used out there: * Over-the-top code that uses every possible gimmick that C allows to get a result, no matter how ugly the code ends up and how impossible it is to follow * And the far gentler sort of code that is typical of what I would write. That would also use a smaller subset of the language (minus all the hairy bits), yet would still work with any existing C compiler. As it happens, my own compiler seems to deal with that second version admirably. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-26 15:16 +0200 |
| Message-ID | <og99l7$gsj$1@dont-email.me> |
| In reply to | #110682 |
On 26/05/17 12:33, bartc wrote: > On 26/05/2017 03:18, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> >>> I'm of the opinion that C's preprocessor plus its 'anything goes' >>> approach to writing declarations and such, can lead to poor code that >>> is very hard to follow. >>> >>> Most here seem to disagree. >> >> I find that hard to believe. Can you cite anyone saying that C's >> declaration syntax and pre-processor can not lead to poor code that is >> very hard to follow? > > See below. You claimed that "most here seem to disagree", and were asked to justify that with a citation. Your response is to reference your own comment, newly written below? How does that make any kind of sense? > >>> LJ_STATIC_ASSERT(offsetof(Node, val) == 0); >>> >>> Obviously a macro, but looking at it doesn't give any enlightenment: >>> >>> extern void LJ_ASSERT_NAME(__LINE__)(int >>> STATIC_ASSERTION_FAILED [(cond)?1:-1]) >>> >>> I guess it's that int something[?:] that gives the VLA error, >> >> Are you taking the mickey? You are writing a C compiler and you don't >> know what this code is doing? > >>> Sorry, still no clue. >> >> It's declaring a function. What else could it be? >> >> The ( size_t ) & ( ( ( Node * ) 0 ) -> val ) == 0 is the expansion of >> offsetof(Node, val). The code is ensuring a diagnostic if val is not at >> offset 0 in a Node object. > > /I/ say this is hard to follow. I'm guessing that you find this > perfectly reasonable code and therefore implying that it is not a > problem. (Maybe that is typical of your own code; I don't know.) > > 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. Yes. Really, Bart, this is not only pretty clear, but it is a very common technique. There is no harm in these extra unused imports - they have names that will not clash with anything. It is a hack, but it is a very useful hack because it helps people spot errors at compile time, and it does not hinder anything else. C11 (synchronous with C++11) introduced _Static_assert to do the same job without this hack, and with a nicer error message. But for those that are still pre-C11, this sort of static assertion is a great idea and should be used regularly. > > So a successful compile would have hundreds of these useless functions. > > 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. > > > Of course, my POV is a little different. If my program can't process a a > bit of code, then I HAVE to locate and trudge through all these macros > and expansions to find what the bug is. So I will see a lot more ugly > code than someone whose compiler just deals with it without a murmur and > they never get to see the source. So what you are saying is that people writing software targeting the market's main compilers, should go out of their way to write weaker code with fewer safeguards in order to make life easier for /you/ when you are debugging your partially written compiler? > > But, compare code which is a pleasure to look at (eg. some of Rick's > programs) and to read through, and code like this. Just as bad are the > sources to sqlite3 (the one-file version), and the sources to gcc's cc1 > program (also the one-file version), where it is a challenge to find a > page containing 'straight' C code that doesn't involve the preprocessor. > > What appears to be emerging is there are two versions of C used out there: > > * Over-the-top code that uses every possible gimmick that C allows to > get a result, no matter how ugly the code ends up and how impossible it > is to follow > > * And the far gentler sort of code that is typical of what I would > write. That would also use a smaller subset of the language (minus all > the hairy bits), yet would still work with any existing C compiler. > > As it happens, my own compiler seems to deal with that second version > admirably. > 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!
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-26 14:40 +0100 |
| Message-ID | <jfWVA.76911$Rw1.72998@fx44.am4> |
| In reply to | #110697 |
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. 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! > 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? Except that enough still works to do some scary preprocessor stuff. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-26 16:42 +0200 |
| Message-ID | <og9emg$3ae$1@dont-email.me> |
| In reply to | #110701 |
On 26/05/17 15:40, bartc wrote:
> 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.
>
> Maybe you are used to these dodgy, underhand techniques, but I'm not.
It is not "dodgy" or "underhanded". Static assertions mean that if I
want to write a function "foo" that relies on CHAR_BIT being 8 and
"long" being 32 bit, then I can write:
static_assert(CHAR_BIT == 8, "You need a target that has 8-bit bytes");
static_assert(sizeof(long) == 4, "You need a target with 32-bit longs");
int foo(void) { ... }
That means I declare my assumptions clearly and explicitly. The
assumptions are documented in the code, and if the source is compiled on
a target that does not meat those assumptions, there is an immediate
compile-time failure.
It is an /excellent/ technique, and should be used widely.
Until C11, C did not have a built-in way to make this kind of assertion.
However, it is not hard to make an equivalent with a few macros. It is
better in every way to have such a macro, and make use of it, than to
put your assumptions in comments, or to put them in run-time assertions,
or just to leave them undocumented and unchecked.
C11 means clearer error messages when your static assertions fail, which
is nice - but static assertions should be used pre-C11.
>
>> 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...
I don't know what you have invented. Static assertions are not a
difficult concept. I suppose that since there were fairly good ways to
implement them with macros, the C (and C++) standards folks didn't
bother adding them to the languages until recently. People writing
quality code already knew how to do static assertions, but by making it
part of the language(s) then I suppose that will encourage others to use
them more.
>
>>> 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!
Having negligible overhead or side-effects means it is not /bad/. It is
/good/, because it has a useful function.
>
>> 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?
No - because your compiler and its limitations are irrelevant to
everyone except you, at the moment. And a major point of programming in
C is to use existing code - a compiler that won't handle large
proportions of existing c code is useless as a C compiler.
>
> Except that enough still works to do some scary preprocessor stuff.
>
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-05-26 17:42 +0200 |
| Message-ID | <m24lw7vd4g.fsf@despina.home> |
| In reply to | #110705 |
David Brown <david.brown@hesbynett.no> writes:
> On 26/05/17 15:40, bartc wrote:
>> 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.
>>
>> Maybe you are used to these dodgy, underhand techniques, but I'm not.
>
> It is not "dodgy" or "underhanded". Static assertions mean that if I
> want to write a function "foo" that relies on CHAR_BIT being 8 and
> "long" being 32 bit, then I can write:
>
> static_assert(CHAR_BIT == 8, "You need a target that has 8-bit bytes");
> static_assert(sizeof(long) == 4, "You need a target with 32-bit longs");
> int foo(void) { ... }
>
> That means I declare my assumptions clearly and explicitly. The
> assumptions are documented in the code, and if the source is compiled on
> a target that does not meat those assumptions, there is an immediate
> compile-time failure.
>
> It is an /excellent/ technique, and should be used widely.
Perhaps the correct implementation, instead of this kludge, would be to
write a specific pre-processor that would interpret those extensions to
the language.
Like PRO*C, Objective-C, or even C++ in the early days were implemented
as pre-processors.
> Until C11, C did not have a built-in way to make this kind of
> assertion.
This is not the problem. The problem is that to the day, C still
hasn't a clean way for the users to define new language elements.
This is something that Lisp has had since 1964 (since the invention of
lisp macros, *they have nothing in common with the C preprocessor
macros)).
Actually, there has been some experimental work in this direction, but
for C++, with the Meta-Object Protocol for C++ (search for C++ MOP or
OpenC++). But it has bitrotten, being a patch on an older now gcc.
I think I've seen some meta-programming system letting you write
compilation-time macros in C, but I can't put my finger on it.
> However, it is not hard to make an equivalent with a few macros. It is
> better in every way to have such a macro, and make use of it, than to
> put your assumptions in comments, or to put them in run-time assertions,
> or just to leave them undocumented and unchecked.
Or, again to avoid the kludges, you can put them in the run-time of a
separate program, written in C, that you will compile and RUN, before
compiling the actual program depending on those compilation-time checks.
This is what is done by systems such as GNU configure.
all:my-program
my-program:compilation-time-checks $(MY_PROGRAM_SOURCES:.c=.o) $(MY_PROGRAM_HEADERS)
$(CC) -o $@ $(MY_PROGRAM_SOURCES:.c=.o)
compilation-time-checks: $(COMPILATION_TIME_SOURCES:.c=.o) $(COMPILATION_TIME__HEADERS)
$(CC) -o $@ $(COMPILATION_TIME_SOURCES:.c=.o)
./compilation-time-checks
--
__Pascal J. Bourguignon
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-26 17:46 +0200 |
| Message-ID | <20170526174608.5c76ef1ba54990c0c43b4e73@gmail.com> |
| In reply to | #110717 |
On Fri, 26 May 2017 17:42:07 +0200 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > This is not the problem. The problem is that to the day, C still > hasn't a clean way for the users to define new language elements. > > This is something that Lisp has had since 1964 (since the invention of > lisp macros, *they have nothing in common with the C preprocessor > macros)). Programmers are so dumb that almost nobody would use LISP nowadays. What do CS professors teach to student after graduated? To forget LISP in order to get a job? :o)
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-05-26 19:09 +0200 |
| Message-ID | <m2mv9ztuin.fsf@despina.home> |
| In reply to | #110719 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes: > On Fri, 26 May 2017 17:42:07 +0200 > "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > >> This is not the problem. The problem is that to the day, C still >> hasn't a clean way for the users to define new language elements. >> >> This is something that Lisp has had since 1964 (since the invention of >> lisp macros, *they have nothing in common with the C preprocessor >> macros)). > > Programmers are so dumb that almost nobody would use LISP nowadays. What do > CS professors teach to student after graduated? To forget LISP in order to get > a job? :o) I fail to see the joke here. It's a sad state of afair. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-26 19:48 +0200 |
| Message-ID | <20170526194838.409aa9a063f3a253aedd7e4e@gmail.com> |
| In reply to | #110738 |
On Fri, 26 May 2017 19:09:20 +0200 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > I fail to see the joke here. It's a sad state of afair. It's a sad affair only for LISP promoters from the academic field since they failed to make an efficient language backed by business owners. Sometime people should realize they failed to not repeat the same mistakes and go forward but some don't want to see the truth by egocentrism and get locked in their own failure.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-26 12:05 -0400 |
| Message-ID | <260d5797-f4f2-c04f-a60d-ba8855e7cbc5@verizon.net> |
| In reply to | #110717 |
On 05/26/2017 11:42 AM, Pascal J. Bourguignon wrote:
> David Brown <david.brown@hesbynett.no> writes:
...
>> static_assert(CHAR_BIT == 8, "You need a target that has 8-bit bytes");
>> static_assert(sizeof(long) == 4, "You need a target with 32-bit longs");
>> int foo(void) { ... }
>>
>> That means I declare my assumptions clearly and explicitly. The
>> assumptions are documented in the code, and if the source is compiled on
>> a target that does not meat those assumptions, there is an immediate
>> compile-time failure.
>>
>> It is an /excellent/ technique, and should be used widely.
>
>
> Perhaps the correct implementation, instead of this kludge, would be to
> write a specific pre-processor that would interpret those extensions to
> the language.
Keep in mind that this "pre-processor" would have to correctly implement
the entirety of translation phases 1-6, and most of translation phase 7,
in order to correctly identify whether or not the static_assert should
be triggered. That being the case, why not implement the rest of
translation phase 7 as well, making it equivalent to any other C compiler?
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-05-26 19:10 +0200 |
| Message-ID | <m2inkntuhi.fsf@despina.home> |
| In reply to | #110722 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 05/26/2017 11:42 AM, Pascal J. Bourguignon wrote:
>> David Brown <david.brown@hesbynett.no> writes:
> ...
>>> static_assert(CHAR_BIT == 8, "You need a target that has 8-bit bytes");
>>> static_assert(sizeof(long) == 4, "You need a target with 32-bit longs");
>>> int foo(void) { ... }
>>>
>>> That means I declare my assumptions clearly and explicitly. The
>>> assumptions are documented in the code, and if the source is compiled on
>>> a target that does not meat those assumptions, there is an immediate
>>> compile-time failure.
>>>
>>> It is an /excellent/ technique, and should be used widely.
>>
>>
>> Perhaps the correct implementation, instead of this kludge, would be to
>> write a specific pre-processor that would interpret those extensions to
>> the language.
>
> Keep in mind that this "pre-processor" would have to correctly
> implement the entirety of translation phases 1-6, and most of
> translation phase 7, in order to correctly identify whether or not the
> static_assert should be triggered. That being the case, why not
> implement the rest of translation phase 7 as well, making it
> equivalent to any other C compiler?
Exactly. You're starting to understand Lisp.
--
__Pascal J. Bourguignon
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-26 13:16 -0400 |
| Message-ID | <fc5aabb8-e637-1c10-8b96-51c4fc819f89@verizon.net> |
| In reply to | #110739 |
On 05/26/2017 01:10 PM, Pascal J. Bourguignon wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > >> On 05/26/2017 11:42 AM, Pascal J. Bourguignon wrote: ... >>> Perhaps the correct implementation, instead of this kludge, would be to >>> write a specific pre-processor that would interpret those extensions to >>> the language. >> >> Keep in mind that this "pre-processor" would have to correctly >> implement the entirety of translation phases 1-6, and most of >> translation phase 7, in order to correctly identify whether or not the >> static_assert should be triggered. That being the case, why not >> implement the rest of translation phase 7 as well, making it >> equivalent to any other C compiler? > > Exactly. You're starting to understand Lisp. How could you justify calling it a "pre-processor" if it implements the entirety of translation phases 1-7?
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-05-27 02:18 +0200 |
| Message-ID | <m27f13tant.fsf@despina.home> |
| In reply to | #110741 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 05/26/2017 01:10 PM, Pascal J. Bourguignon wrote: >> "James R. Kuyper" <jameskuyper@verizon.net> writes: >> >>> On 05/26/2017 11:42 AM, Pascal J. Bourguignon wrote: > ... >>>> Perhaps the correct implementation, instead of this kludge, would be to >>>> write a specific pre-processor that would interpret those extensions to >>>> the language. >>> >>> Keep in mind that this "pre-processor" would have to correctly >>> implement the entirety of translation phases 1-6, and most of >>> translation phase 7, in order to correctly identify whether or not the >>> static_assert should be triggered. That being the case, why not >>> implement the rest of translation phase 7 as well, making it >>> equivalent to any other C compiler? >> >> Exactly. You're starting to understand Lisp. > > How could you justify calling it a "pre-processor" if it implements > the entirety of translation phases 1-7? You too are starting to see the light, without realizing it! Indeed, it's bad to have a pre-processor! What you need and want without knowing it, is a true circular meta-programming system. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-29 10:07 +0000 |
| Message-ID | <592bf242.7941421@news.xs4all.nl> |
| In reply to | #110774 |
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > > On 05/26/2017 01:10 PM, Pascal J. Bourguignon wrote: > >> Exactly. You're starting to understand Lisp. Maybe, but you clearly still don't understand C. > > How could you justify calling it a "pre-processor" if it implements > > the entirety of translation phases 1-7? > > You too are starting to see the light, without realizing it! > > Indeed, it's bad to have a pre-processor! What you need and want without > knowing it, is a true circular meta-programming system. No. What we want is a _programming_ language, not a language for _research_ into programming. LISP is great for academics, but for people with jobs, it is unusable. C is the other way 'round: it irritates the ivory tower, but it _works_. Richard
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-29 12:21 +0200 |
| Message-ID | <20170529122117.ddc0bd478fa3b4268abdecce@gmail.com> |
| In reply to | #110856 |
On Mon, 29 May 2017 10:07:01 GMT raltbos@xs4all.nl (Richard Bos) wrote: > LISP is great for academics, but for people with jobs, it is unusable. > C is the other way 'round: it irritates the ivory tower, but it _works_. It works so well that it is counterfeited by the Stroustrup language with exotic features to look smart in a fashion way.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-29 12:00 +0000 |
| Message-ID | <592c0d67.14890296@news.xs4all.nl> |
| In reply to | #110858 |
GOTHIER Nathan <nathan.gothier@gmail.com> wrote: > On Mon, 29 May 2017 10:07:01 GMT > raltbos@xs4all.nl (Richard Bos) wrote: > > > LISP is great for academics, but for people with jobs, it is unusable. > > C is the other way 'round: it irritates the ivory tower, but it _works_. > > It works so well that it is counterfeited by the Stroustrup language with > exotic features to look smart in a fashion way. *Shrug* And LISP has Scheme. Your point was? Richard
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web