Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #68344 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-08-25 14:14 -0700 |
| Last post | 2015-08-27 13:04 +0200 |
| Articles | 20 on this page of 291 — 30 participants |
Back to article view | Back to comp.lang.c
should c be a subset of c++? G G <gdotone@gmail.com> - 2015-08-25 14:14 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 14:43 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 15:26 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 09:51 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 10:46 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 20:55 +0100
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 13:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 00:04 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:01 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 12:11 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 06:31 -0700
Re: should c be a subset of c++? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-08-31 10:24 -0400
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 18:04 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 11:28 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 00:31 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 17:19 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-08-31 22:18 -0400
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 13:32 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 05:37 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 16:51 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 09:45 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:04 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 12:15 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:33 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 12:41 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 21:02 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 13:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-02 00:42 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 17:24 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 13:34 -0700
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-02 19:07 +0200
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-02 19:13 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 10:25 -0700
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 09:58 +0200
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 10:06 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 06:44 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 14:49 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 07:21 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 07:22 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 07:33 -0700
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-09-01 08:32 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 08:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-01 22:58 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 22:07 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-02 13:12 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 16:48 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 09:15 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:00 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 12:57 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 23:57 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-01 22:57 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 22:04 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-02 13:29 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 12:37 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:13 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-03 23:59 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-04 10:13 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 01:23 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-04 09:52 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 02:03 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-04 10:20 +0100
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 11:33 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 03:13 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-04 12:53 +0200
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:31 +0000
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 11:43 -0500
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 15:07 -0700
Re: should c be a subset of c++? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:36 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:57 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-09-08 10:36 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 06:02 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 16:53 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 09:59 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 21:13 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-09-04 22:20 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 13:45 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 22:21 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 14:53 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 00:48 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 20:02 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 13:10 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 05:31 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 15:46 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:19 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 14:34 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:14 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 17:39 +0200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-09-06 12:05 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:13 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 06:05 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 06:11 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 10:10 -0400
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 08:51 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 16:30 -0400
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 13:52 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 21:17 -0400
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-06 05:47 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 00:02 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 08:20 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 02:23 -0700
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:34 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 16:17 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:31 +0000
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-05 19:06 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 21:12 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:23 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 14:30 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:23 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 17:15 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:21 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:34 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 21:42 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 17:01 -0700
Re: should c be a subset of c++? "Osmium" <r124c4u102@comcast.net> - 2015-09-06 13:46 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:01 -0700
Re: should c be a subset of c++? "Osmium" <r124c4u102@comcast.net> - 2015-09-06 14:22 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:29 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:36 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 22:20 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 23:13 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:23 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-07 11:55 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 04:00 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-07 12:44 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-09-06 22:32 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:36 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 00:08 +0200
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-06 23:33 -0500
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-09-07 12:18 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 21:51 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 21:14 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:23 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 22:40 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:05 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 00:11 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 16:43 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:10 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 17:23 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:36 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 17:54 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 11:03 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 15:17 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-07 07:49 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 22:43 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 18:22 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 11:00 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 15:10 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 07:42 -0700
Re: should c be a subset of c++? Les Cargill <lcargill99@comcast.com> - 2015-09-07 10:26 -0500
Re: should c be a subset of c++? Ike Naar <ike@iceland.freeshell.org> - 2015-09-07 16:10 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 22:39 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 15:16 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 17:17 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 08:27 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 21:13 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 10:54 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 02:26 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 12:26 +0200
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-06 23:37 -0500
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 00:57 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 16:57 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:26 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 20:41 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:55 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:21 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 11:15 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 20:03 +0100
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 20:49 +0100
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-08 07:55 +0200
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:27 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 15:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 00:58 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 01:11 +0000
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-05 19:12 +0000
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-26 11:39 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 17:47 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-26 12:55 +1200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-26 07:14 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 03:54 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-26 12:01 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 04:07 -0700
Re: should c be a subset of c++? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-26 13:13 +0000
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 06:28 -0700
Re: should c be a subset of c++? Mark Storkamp <mstorkamp@yahoo.com> - 2015-08-26 09:05 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 07:18 -0700
Re: should c be a subset of c++? Ken Brody <kenbrody@spamcop.net> - 2015-08-26 13:31 -0400
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-26 18:52 +0100
Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 14:04 -0400
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 09:25 +1200
Re: should c be a subset of c++? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-26 21:37 +0000
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 14:49 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 13:16 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 18:47 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 14:46 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 19:58 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 11:31 +0200
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:40 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 03:34 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 12:54 +0200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-08-27 10:46 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 07:56 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 13:08 -0700
Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-08-27 16:36 -0400
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 08:49 +1200
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 10:24 +0200
Re: should c be a subset of c++? Les Cargill <lcargill99@comcast.com> - 2015-08-27 12:00 -0500
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 11:55 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 14:09 +0200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 15:14 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 11:38 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 07:17 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 16:24 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-27 18:58 +0200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 20:35 +0100
Re: should c be a subset of c++? fir <profesor.fir@gmail.com> - 2015-08-27 13:07 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 21:36 +0100
Re: should c be a subset of c++? fir <profesor.fir@gmail.com> - 2015-08-27 14:31 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 08:25 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 13:30 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 14:49 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-27 22:34 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:33 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 00:31 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 18:16 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 10:08 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:03 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 23:18 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:34 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 08:03 +1200
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 12:02 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 06:02 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 07:52 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 16:14 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 11:26 +1200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-08-28 18:06 -0700
Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-08-28 18:33 -0500
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 11:38 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 17:08 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 17:12 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 12:15 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 18:20 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 17:13 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 12:38 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:58 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 15:36 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:11 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 10:57 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:21 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:34 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 17:16 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 13:03 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 18:38 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 23:29 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-28 01:15 +0200
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:25 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:39 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 00:56 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 00:45 +0000
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 13:05 +1200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 10:46 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 11:38 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 05:23 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 13:51 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:20 -0700
Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-08-28 09:55 -0500
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 15:10 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 09:03 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 13:38 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 06:11 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 13:59 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:31 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 20:36 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 15:55 +0200
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 14:57 +0000
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 17:45 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 22:36 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 23:38 +0000
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-29 09:29 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 17:52 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 19:27 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-28 21:30 +0200
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 08:14 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 18:51 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 14:48 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 20:15 -0700
Re: should c be a subset of c++? Ayan <selfjam@gmail.com> - 2015-08-26 23:59 -0400
Re: should c be a subset of c++? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-27 12:03 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 03:33 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 13:04 +0200
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-27 12:54 +0200 |
| Message-ID | <mrmq63$ktd$1@dont-email.me> |
| In reply to | #68483 |
On 27/08/15 12:34, Malcolm McLean wrote: > On Thursday, August 27, 2015 at 9:40:45 AM UTC+1, David Brown wrote: >> >> A different language with some C++ features might make different >> decisions, of course, but you will find that if you add some >> sort of OOP support to your C language, the step towards adding >> more and more is not far off being inevitable if the language is >> used for a wide range of applications. >> > The main reason for C++ complexity is that class creates a new > type which can exist on the stack like a regular variable. So does "struct", or other C aggregate and pointer types. The difference is that C++ hides some of the complexity from the immediate users, which C exposes it and insists on manual handling of the complexity. (Whether that is a good thing or a bad thing is a matter of opinion, with supporters on both sides - but the complexity is there no matter what.) > That > unleashes a host of difficulties, which leads to more and more > language features being added to support them in a runaway > process by which the new features create new difficulties. > The language features have been added to give new possibilities, or to make old possibilities easier or more efficient. So templates were added to make the language more flexible, to allow new types of programming (especially for library or utility code), and faster (since it is possible for the compiler to make specialised functions, rather than indirect ones). Then "auto" was added to make templated types easier to use (amongst other reasons). Certainly some features make other features almost inevitable. Once you have classes, someone is going to want to make a "matrix" class. For that to work neatly and allow people to use the class in the nicest possible manner, such as "A = B + C", you've got to have operator overloading, function overloading, and some type of "friend" specifier (an alternative protection mechanism, such as Object Pascal's "everything in the same module is a friend", would also be possible). But as with any language, the features of C++ are optional - you don't have to use it just because it exists. The same applies to C - there are plenty of features of C that I would not dream of using in my own code. And there are plenty of features of both languages that are somewhat hard or complicated, and best suited to low-level or library code rather than application code. But that does not make features bad - it just means you have to know when they are appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-27 10:46 -0700 |
| Message-ID | <ln6140wrnt.fsf@kst-u.example.com> |
| In reply to | #68484 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But as with any language, the features of C++ are optional - you don't
> have to use it just because it exists. The same applies to C - there
> are plenty of features of C that I would not dream of using in my own
> code. And there are plenty of features of both languages that are
> somewhat hard or complicated, and best suited to low-level or library
> code rather than application code. But that does not make features bad
> - it just means you have to know when they are appropriate.
One problem with using a subset of a language (and this applies to
C, to C++, or to any language) is that the compiler isn't going to
diagnose code that goes outside your subset.
For example, let's say you're using a C99 compiler but you don't like
variable-length arrays. You still might write something like this:
{
const int len = 1024;
unsigned char buffer[len];
}
`buffer` is a VLA (because the name of a const-qualified object
is not a constant expression). But a conforming C compiler need
not, and probably will not, warn you that you've used a VLA.
(Invoking the compiler in C90 mode is not an answer; perhaps you
want to use long long and avoid implicit int.)
That's just one example, and probably not the best one.
Restricting yourself to a subset of a language, for the purpose
of avoiding features that you see as overly complicated, requires
discipline -- and unlike restricting to, say, ISO C99 or ISO C++11,
the compiler isn't going to help you maintain that discipline.
Third-party tools can help, but they have to exist first.
--
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]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-28 07:56 +1200 |
| Message-ID | <d498c4FrgntU6@mid.individual.net> |
| In reply to | #68500 |
Keith Thompson wrote: > > Restricting yourself to a subset of a language, for the purpose > of avoiding features that you see as overly complicated, requires > discipline -- and unlike restricting to, say, ISO C99 or ISO C++11, > the compiler isn't going to help you maintain that discipline. > Third-party tools can help, but they have to exist first. All software development requires discipline. Every coding standard I have seen contained rules that tools didn't enforce. That is why we have practices such as code review, pair programming and collective code ownership. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-27 13:08 -0700 |
| Message-ID | <6d188328-d83f-4d85-a0d6-6df981e5bb83@googlegroups.com> |
| In reply to | #68507 |
On Thursday, August 27, 2015 at 3:57:08 PM UTC-4, Ian Collins wrote:
> Keith Thompson wrote:
> >
> > Restricting yourself to a subset of a language, for the purpose
> > of avoiding features that you see as overly complicated, requires
> > discipline -- and unlike restricting to, say, ISO C99 or ISO C++11,
> > the compiler isn't going to help you maintain that discipline.
> > Third-party tools can help, but they have to exist first.
>
> All software development requires discipline. Every coding standard I
> have seen contained rules that tools didn't enforce. That is why we
> have practices such as code review, pair programming and collective code
> ownership.
Reminds me of the scene where Leah Brahms and Geordi LaForge are
discussing the changes he's made to her design on the Enterprise
engines.
http://www.chakoteya.net/nextgen/190.htm
LEAH: The matter-antimatter ratio has been changed. The mixture
isn't as rich as regulations dictate.
LAFORGE: Experience has shown me that too high a ratio diminishes
efficiency. I worked with the mixture until I got the right
balance.
LEAH: The magnetic plasma transfer to the warp field generators
doesn't correspond to the recommended specs.
LAFORGE: Right. Again, I adjusted the flow. Sometimes things happen
a little differently here is space than they do on the
drawing board.
LEAH: Is that a criticism, Commander?
LAFORGE: No, of course not. It's just a well known fact. There's
theory and there's application. They don't always jibe.
LEAH: You've charted a completely new swap-out schedule for
main components replacement.
LAFORGE: You bet. I found the Starfleet estimates for the MTBF units
to be unrealistic. I simply determined my own schedule based
on observation and experience.
LEAH: Is that going to be your only defence, Commander, that same
tired rhetoric? Out here in the field we learn things you
designers couldn't possibly understand.
It's been my experience.
-----
And on a side-note, how exactly does one change the ratio of matter
and anti-matter? We learn from this episode that there is only one
ratio:
http://www.chakoteya.net/nextgen/119.htm
COMPUTER: Last question on the hyperspace physics test. If the matter
and antimatter tanks on a Galaxy class starship are nine
tenths depleted, calculate the intermix ratio necessary to
reach a starbase a hundred light years away at warp factor
eight. Begin.
(Wesley is straight in with 1:1. Oliana runs out of time)
COMPUTER: Time elapsed. You now have one hour free before the next
test.
MORDOCK: I must admit, Wesley, you have a very fast mind.
WESLEY: Once as I realised it was a trick question, there was only
one answer.
MORDOCK: Yes, there is only one ratio with matter antimatter...
One to one.
I suppose you could increase the matter rate to a higher ratio, and just
slowly fill up the warp core with tiny particles. :-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-27 16:36 -0400 |
| Message-ID | <mrnsa2$vpn$1@dont-email.me> |
| In reply to | #68507 |
On 08/27/2015 03:56 PM, Ian Collins wrote: > Keith Thompson wrote: >> >> Restricting yourself to a subset of a language, for the purpose >> of avoiding features that you see as overly complicated, requires >> discipline -- and unlike restricting to, say, ISO C99 or ISO C++11, >> the compiler isn't going to help you maintain that discipline. >> Third-party tools can help, but they have to exist first. > > All software development requires discipline. Every coding standard I > have seen contained rules that tools didn't enforce. That is why we > have practices such as code review, pair programming and collective code > ownership. That's all the more reason to avoid making things more difficult by creating new things you need to be disciplined about. You shouldn't restrict yourself to a subset of a given language without strong reasons to avoid the rest of that language, and if you do have such a reason, it also qualifies as a reason to avoid using that language, so you won't need to exercise that discipline. It's perfectly natural and normal to avoid using parts of a language that are irrelevant to what you're doing - there's correspondingly no need to be disciplined about it. For example, people who don't need to work with complex numbers can easily avoid that by never #including <complex.h>, never using the keywords _Complex (or _Imaginary), and never using the corresponding functions from the math library - it's trivial and requires no discipline. However, when people say they want to avoid using C++ because they don't like some of it's features, it must be the case that they see accidentally using those features as a dangerous possibility, requiring discipline to avoid. Personally, I don't understand the danger - but if they need to maintain discipline to avoid using a dangerous feature, then avoiding the language itself to avoid the need to maintain discipline can be a reasonable thing to do. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-28 08:49 +1200 |
| Message-ID | <d49berFrgntU8@mid.individual.net> |
| In reply to | #68514 |
James Kuyper wrote: > On 08/27/2015 03:56 PM, Ian Collins wrote: >> Keith Thompson wrote: >>> >>> Restricting yourself to a subset of a language, for the purpose >>> of avoiding features that you see as overly complicated, requires >>> discipline -- and unlike restricting to, say, ISO C99 or ISO C++11, >>> the compiler isn't going to help you maintain that discipline. >>> Third-party tools can help, but they have to exist first. >> >> All software development requires discipline. Every coding standard I >> have seen contained rules that tools didn't enforce. That is why we >> have practices such as code review, pair programming and collective code >> ownership. > > That's all the more reason to avoid making things more difficult by > creating new things you need to be disciplined about. You shouldn't > restrict yourself to a subset of a given language without strong reasons > to avoid the rest of that language, and if you do have such a reason, it > also qualifies as a reason to avoid using that language, so you won't > need to exercise that discipline. The argument applies to C as well as C++. A common rule in both embedded C and C++ is "No dynamic allocation". Another in embedded C would be "No VLAs". Both require discipline and neither qualifies as a reason to avoid using that language. > It's perfectly natural and normal to avoid using parts of a language > that are irrelevant to what you're doing - there's correspondingly no > need to be disciplined about it. For example, people who don't need to > work with complex numbers can easily avoid that by never #including > <complex.h>, never using the keywords _Complex (or _Imaginary), and > never using the corresponding functions from the math library - it's > trivial and requires no discipline. I agree. > However, when people say they want to avoid using C++ because they don't > like some of it's features, it must be the case that they see > accidentally using those features as a dangerous possibility, requiring > discipline to avoid. Personally, I don't understand the danger - but if > they need to maintain discipline to avoid using a dangerous feature, > then avoiding the language itself to avoid the need to maintain > discipline can be a reasonable thing to do. One of the most common embedded C++ rules is "No exceptions" which is enforceable through compiler options on every compiler I've used for embedded work. The are a number of other common exclusions (excluding run time type identification) which are also enforceable through compiler options. Other exclusions tend to be matters of style, or reflections of a team's philosophy or comfort zone. A good example of the latter is a team of C programmers who want some extra language features such as functions overloading. So you could argue these guidelines aren't restricting C++, that are extending C :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-28 10:24 +0200 |
| Message-ID | <mrp5o0$lkg$1@dont-email.me> |
| In reply to | #68500 |
On 27/08/15 19:46, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> But as with any language, the features of C++ are optional - you don't
>> have to use it just because it exists. The same applies to C - there
>> are plenty of features of C that I would not dream of using in my own
>> code. And there are plenty of features of both languages that are
>> somewhat hard or complicated, and best suited to low-level or library
>> code rather than application code. But that does not make features bad
>> - it just means you have to know when they are appropriate.
>
> One problem with using a subset of a language (and this applies to
> C, to C++, or to any language) is that the compiler isn't going to
> diagnose code that goes outside your subset.
>
> For example, let's say you're using a C99 compiler but you don't like
> variable-length arrays. You still might write something like this:
>
> {
> const int len = 1024;
> unsigned char buffer[len];
> }
>
> `buffer` is a VLA (because the name of a const-qualified object
> is not a constant expression). But a conforming C compiler need
> not, and probably will not, warn you that you've used a VLA.
> (Invoking the compiler in C90 mode is not an answer; perhaps you
> want to use long long and avoid implicit int.)
>
> That's just one example, and probably not the best one.
>
> Restricting yourself to a subset of a language, for the purpose
> of avoiding features that you see as overly complicated, requires
> discipline -- and unlike restricting to, say, ISO C99 or ISO C++11,
> the compiler isn't going to help you maintain that discipline.
> Third-party tools can help, but they have to exist first.
>
This is true of any restrictions you make on your code - the compiler
cannot (in general) spot when you break those restrictions. But that
should not stop you applying such restrictions to the code you write!
After all, consider some of the other restrictions you would typically
make on your code, so that you only write a subset of the source code
the compiler will accept, and which the compiler is unlikely to be able
to enforce:
1. You use a subset of source code that avoids undefined behaviour.
2. You use a subset of text in comments, that consists of correctly
spelled words.
3. You use a subset of source code that actually does what you want it
to do.
Adding new "rules", such as "don't use VLA's", is no different.
And for a number of such rules, tools /do/ exist - compilers can warn
about some things, and third-party checkers such as cppcheck or pclint
can do more. For the really enthusiastic user, you can write plugins
for gcc (and, I think, llvm) to do more checking. And of course code
reviews offer other possibilities.
The only disadvantage I see in being restrictive in the type of code you
write, is that it may cause you problems when dealing with someone
else's code because they use features or constructs that are unfamiliar
to you.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-08-27 12:00 -0500 |
| Message-ID | <mrnfh4$8e7$1@dont-email.me> |
| In reply to | #68483 |
Malcolm McLean wrote: > On Thursday, August 27, 2015 at 9:40:45 AM UTC+1, David Brown wrote: >> >> A different language with some C++ features might make different >> decisions, of course, but you will find that if you add some >> sort of OOP support to your C language, the step towards adding >> more and more is not far off being inevitable if the language is >> used for a wide range of applications. >> > The main reason for C++ complexity is that class creates a new > type which can exist on the stack like a regular variable. That > unleashes a host of difficulties, which leads to more and more > language features being added to support them in a runaway > process by which the new features create new difficulties. > > The canonical "OO" programming systems like Smalltalk and Lisp are... interpreted ( mostly ). I have to wonder if much of the advocacy for OO comes from that and less the design/development paradigm. IMO, the number and variety of "objects" required to do most things is pretty small, if you include state machines* and don't worry about what they call "UX". *and in OO, what people do for state machines can be pretty hilarious - such as "each state is a class." -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-27 11:55 +0100 |
| Message-ID | <mrmq7o$l30$1@dont-email.me> |
| In reply to | #68478 |
On 27/08/2015 09:40, David Brown wrote: > On 27/08/15 03:47, Rick C. Hodgin wrote: >> With such a complex compiler like C++, people look at the task before >> them and then go and take up fishing instead thinking, "Ah, how much >> more fun we'll have casting those lines, rather than writing those >> lines." > > Anyone seriously interested in writing a competitive C (or C++) today > compiler has three choices. You can use some or all of gcc. You can > use some or all of clang. > When you are writing compilers for fun, educational purposes, or some > other reason, Fun compilers can be viable; see below. I guess I could write an actual C compiler given enough inclination. (It would be a pretty crappy one, but it would work.) But there is absolutely no way I could write a C++ compiler. The language is just utterly impossible. Most of it isn't even a proper language, but consists of an elaborate set of language-building features. Why build in a feature - flexible arrays for example - when you can instead add dozens of features to allow the programmer to construct his own DIY version! (A large-scale version of C's macro system perhaps.) But I doubt that any amount of debate will convince anyone here. Not when I complain about an 11GB download for MSVC, and people are just bemused by the size instead of being concerned (as happened in a recent thread). > I did a quick check of the sizes of the C and C++ gcc compilers on my > system. The main C++ binary, cc1plus, is /massive/ - it is 107 MB > (including debugging symbols, which are not necessary in the binary but > perhaps a useful indication of the complexity involved). It's a big, > complex tool. > > But for comparison, the main C binary, cc1, is 101 MB. That is a mere > 6% smaller. That is the sort of difference C or C++ makes in real-world > compilers. Where do you get the 100MB size from? On my mingw gcc, there is a basic 1.8MB gcc executable, plus a 12MB cc1 file, and a 13MB cc1plus file. I don't believe that 1MB difference is simply the difference between the front ends. I think the requirements of having to compile C++ influence the C compiler too. Tiny C is about 0.15MB and does a pretty good job. But then it can be lean and streamlined because it only concerns itself with C. (As for performance, in the case of one of my recent interpreter projects, using my own 'toy' compiler made it 27% slower than gcc, and 15% slower than clang. Not a lot really! When I add in a runtime-switchable ASM layer, then I can get 40% faster than gcc and 53% faster than clang!) > But remember, pretty much all of C++'s features are there because people > find them useful. If they are the only way to implement the flexible array example from above, then you could be right! (But I've created languages with flexible arrays without needing to add classes, multiple inheritance, overloading, templates or any of that stuff.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-27 14:09 +0200 |
| Message-ID | <mrmuic$4e3$1@dont-email.me> |
| In reply to | #68485 |
On 27/08/15 12:55, Bartc wrote: > On 27/08/2015 09:40, David Brown wrote: >> On 27/08/15 03:47, Rick C. Hodgin wrote: > >>> With such a complex compiler like C++, people look at the task before >>> them and then go and take up fishing instead thinking, "Ah, how much >>> more fun we'll have casting those lines, rather than writing those >>> lines." >> >> Anyone seriously interested in writing a competitive C (or C++) today >> compiler has three choices. You can use some or all of gcc. You can >> use some or all of clang. > >> When you are writing compilers for fun, educational purposes, or some >> other reason, > > Fun compilers can be viable; see below. > > I guess I could write an actual C compiler given enough inclination. (It > would be a pretty crappy one, but it would work.) But there is > absolutely no way I could write a C++ compiler. I am sure you code - it's not /that/ hard, especially if you are happy with pretty crap code generation :-) There are technical reasons for C++ grammar being harder to parse than C grammar, but it is certainly possible. And once you have got that in place, there is nothing to hinder you making a working compiler if you are already happy with making a C compiler. After all, it is possible - sub-optimal, but possible - to simply translate the C++ into C. So you could translate the parsed C++ code directly into the internal representation you use for parsed C. > > The language is just utterly impossible. No, it is not "utterly impossible". Let's dispense with the hyperbolas, exaggerations, and "10 orders of magnitude harder". C++ is a bigger and more complex language than C - but most serious C compilers are also C++ compilers, and a great many people manage to write perfectly good working C++ code despite being far less competent programmers than you (and I'm not being sarcastic here). You /choose/ to use C, rather than C++. That's fine. I am sure you have perfectly good reasons for it - and perhaps some less good reasons. There are plenty of situations where C is a better choice than C++. But C++ is not "utterly impossible" - it is a real language, with real compilers and real users, and people use it to write real code. Once you (and a few others here) have got past the silliness and absurdities, it will be possible to think a little more about what makes the languages different, where they /should/ differ, and where the programming community as a whole might benefit from closer ties. > Most of it isn't even a proper > language, but consists of an elaborate set of language-building > features. Why build in a feature - flexible arrays for example - when > you can instead add dozens of features to allow the programmer to > construct his own DIY version! (A large-scale version of C's macro > system perhaps.) I don't follow your complaint. Are you telling us that it is a terrible idea for C++ to provide building blocks like classes and templates that lets people make a wide variety of container types, when they could simply have added variable length arrays (which for some reason that is beyond my comprehension, seems to be the most hated feature of C99)? C++ has taken the path that the language should have the features required to write such things as a library, and make them easily and efficiently used by applications. And they are only DIY if you want them to be - there standard template language is pretty standard, but if you want specialised containers then you can do so. > > But I doubt that any amount of debate will convince anyone here. Not > when I complain about an 11GB download for MSVC, and people are just > bemused by the size instead of being concerned (as happened in a recent > thread). It is not C++ that makes MSVC an 11 GB download. People in groups like c.l.c and c.l.c++ are not concerned because it is not a C or C++ problem, it is a Windows and MS problem. > >> I did a quick check of the sizes of the C and C++ gcc compilers on my >> system. The main C++ binary, cc1plus, is /massive/ - it is 107 MB >> (including debugging symbols, which are not necessary in the binary but >> perhaps a useful indication of the complexity involved). It's a big, >> complex tool. >> >> But for comparison, the main C binary, cc1, is 101 MB. That is a mere >> 6% smaller. That is the sort of difference C or C++ makes in real-world >> compilers. > > Where do you get the 100MB size from? On my mingw gcc, there is a basic > 1.8MB gcc executable, plus a 12MB cc1 file, and a 13MB cc1plus file. As I said, those executables include the debugging symbols, since it was built from source, and I had not striped the binaries. On Linux, the symbols do not cause any slowdown since they are not loaded - on windows, the symbols would be loaded as part of the exe file before being ignored, so striping is more important. And I felt that including the symbols was an additional indicator of complexity. The striped versions are 17.5 MB and 18.5 MB - perhaps because they are 64-bit binaries, and cover 32-bit and 64-bit code generation while your mingw version is probably 32-bit (host and target). > > I don't believe that 1MB difference is simply the difference between the > front ends. I think the requirements of having to compile C++ influence > the C compiler too. Given that a fair comparison would require a compiler that comes in two versions - a C version and a C++ version - matching in features, optimisations and code generation, it is hard to do any better than gcc. During compilation of the cc1 binary, the code knows (through pre-processor symbols) that it is dealing with C only, and anything significantly C++-only (or only for Go, Fortran, Java, or Ada) will be omitted. I am sure this is not done as completely as it could be - the emphasis is on maintainable code for all languages rather than raw C compiler speed or size - but I do not expect the "C++ influence" to be a particularly significant part of the cc1 binary. > > Tiny C is about 0.15MB and does a pretty good job. But then it can be > lean and streamlined because it only concerns itself with C. > It is also a very much simpler compiler, with an emphasis on the size of the compiler rather than the size or speed of the generated code. It does not have close to the feature range of gcc, the flexibility, or the optimisations. There are three key reasons why gcc's binaries are much bigger than TCC's. First is flexibility - mainline gcc supports eight source languages directly, with some support for a few others. It supports several dozen targets, many with dozens of variations. It even supports dozens of human languages for its warnings and errors. It includes emulators for integer and floating point operations on the target systems, so that any compile-time calculations match identically to the results you would get on the target, even for cross-compilation. All this costs space, and run-time, even when configured for a single language and target. The second is optimisation - gcc aims to produce as high quality code as possible. This follows a law of diminishing returns - getting the last few percent of speed out of the last few source code constructs will take a lot more code space than getting the first few percent of speed. The third is features - I don't think I even need to bother listing things here. Sure, tcc does a good job at what it aims to do. But it does not aim to complete with or replace gcc - it aims to be a workable C compiler in minimal space. It is only comparable to gcc in the way that a bicycle is comparable to a vehicle that can double as a bus, a lorry, a tractor, and a racing car, with attachments for converting it to a plane or a submarine. > (As for performance, in the case of one of my recent interpreter > projects, using my own 'toy' compiler made it 27% slower than gcc, and > 15% slower than clang. Not a lot really! When I add in a > runtime-switchable ASM layer, then I can get 40% faster than gcc and 53% > faster than clang!) > >> But remember, pretty much all of C++'s features are there because people >> find them useful. > > If they are the only way to implement the flexible array example from > above, then you could be right! (But I've created languages with > flexible arrays without needing to add classes, multiple inheritance, > overloading, templates or any of that stuff.) > I think you have figured out the heart of the conspiracy. All people wanted was VLA's to make C the perfect language for all purposes, but Bjarne Stroustrup had his evil plans: <http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html>
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-27 15:14 +0100 |
| Message-ID | <mrn5sq$hl$1@dont-email.me> |
| In reply to | #68487 |
On 27/08/2015 13:09, David Brown wrote: > On 27/08/15 12:55, Bartc wrote: >> I guess I could write an actual C compiler given enough inclination. (It >> would be a pretty crappy one, but it would work.) But there is >> absolutely no way I could write a C++ compiler. > > I am sure you code - it's not /that/ hard, especially if you are happy > with pretty crap code generation :-) I don't mean poor code, but just in general (such as error reporting). My compilers actually out-performed C compilers until the 90s. Now gcc might be up to double the speed of my code. My compilers however don't have a register optimiser. (There was such a project, but I lost interest. I found that by careful use of ASM, I wouldn't just get a bit closer to gcc speed, but far exceed it.) >> The language is just utterly impossible. > > No, it is not "utterly impossible". > > Let's dispense with the hyperbolas, exaggerations, and "10 orders of > magnitude harder". I didn't say that. I said one to two orders. > C++ is a bigger and more complex language than C - > but most serious C compilers are also C++ compilers, and a great many > people manage to write perfectly good working C++ code despite being far > less competent programmers than you (and I'm not being sarcastic here). > > You /choose/ to use C, rather than C++. That's fine. I am sure you > have perfectly good reasons for it - and perhaps some less good reasons. > There are plenty of situations where C is a better choice than C++. > > But C++ is not "utterly impossible" - it is a real language, with real > compilers and real users, and people use it to write real code. And real people choose not to use it. Why is that? I just think it's a horrible language (C# is a much better take on it, if you like that sort of thing.) (BTW could /you/ create a C++ compiler from scratch? Ie. not relying on other people's efforts.) >> Most of it isn't even a proper >> language, but consists of an elaborate set of language-building >> features. Why build in a feature - flexible arrays for example - when >> you can instead add dozens of features to allow the programmer to >> construct his own DIY version! (A large-scale version of C's macro >> system perhaps.) > > I don't follow your complaint. Are you telling us that it is a terrible > idea for C++ to provide building blocks like classes and templates that > lets people make a wide variety of container types, when they could > simply have added variable length arrays (which for some reason that is > beyond my comprehension, seems to be the most hated feature of C99)? I don't mean C's VLAs, but flexible arrays, strings etc in general. What you might expect of a language the next level up from C. Language building features as you find in C++ I don't really agree what, not when they are part of the normal language available to everyone. (Because they they will get abused and people will delight in writing impenetrable code. A bit like they like to do with C's macros.) >> Tiny C is about 0.15MB and does a pretty good job. But then it can be >> lean and streamlined because it only concerns itself with C. >> > > It is also a very much simpler compiler, with an emphasis on the size of > the compiler rather than the size or speed of the generated code. It > does not have close to the feature range of gcc, the flexibility, or the > optimisations. > > There are three key reasons why gcc's binaries are much bigger than > TCC's. First is flexibility - mainline gcc supports eight source > languages directly, with some support for a few others. It supports > several dozen targets, many with dozens of variations. It even supports > dozens of human languages for its warnings and errors. I don't believe that all the targets, all the front-ends, and all possible human languages for messages are lumped together in that one executable. Perhaps some of the other 1200MB that I haven't yet mentioned has something to do with it! And also, why would a distribution specifically for Windows include targets that are irrelevant to Windows? > It includes > emulators for integer and floating point operations on the target > systems, so that any compile-time calculations match identically to the > results you would get on the target, even for cross-compilation. All > this costs space, and run-time, even when configured for a single > language and target. Sure. The last floating point emulation package I did occupied 4KB of code! (Well, either 4KB or 8KB. This would be for x86.) > The second is optimisation - gcc aims to produce as high quality code as > possible. This follows a law of diminishing returns - getting the last > few percent of speed out of the last few source code constructs will > take a lot more code space than getting the first few percent of speed. Yes, getting the best possible code is difficult. But difficulty doesn't necessary mean colossal amounts of code. Algorithms don't usually run to a million lines of source. > Sure, tcc does a good job at what it aims to do. But it does not aim to > complete with or replace gcc - it aims to be a workable C compiler in > minimal space. It is only comparable to gcc in the way that a bicycle > is comparable to a vehicle that can double as a bus, a lorry, a tractor, > and a racing car, with attachments for converting it to a plane or a > submarine. If someone was to come out with a C compiler that produced as good code as gcc, but was a tenth the size and worked ten times as fast, would you still consider it a bicycle? Or does being big, slow and cumbersome guarantee that something is better? TCC isn't far off: it's one hundredth the size, compiles a hundred times faster, but it's code might be half the speed as gcc. I wouldn't quickly dismiss such an achievement. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-28 11:38 +0200 |
| Message-ID | <mrpa38$3de$1@dont-email.me> |
| In reply to | #68488 |
On 27/08/15 16:14, Bartc wrote: > On 27/08/2015 13:09, David Brown wrote: >> On 27/08/15 12:55, Bartc wrote: > >>> I guess I could write an actual C compiler given enough inclination. (It >>> would be a pretty crappy one, but it would work.) But there is >>> absolutely no way I could write a C++ compiler. >> >> I am sure you code - it's not /that/ hard, especially if you are happy >> with pretty crap code generation :-) > > I don't mean poor code, but just in general (such as error reporting). The same thing applies (perhaps even more so, as good error reporting with C++ is probably harder that good object code generation, assuming you start from a working C compiler). > >>> The language is just utterly impossible. >> >> No, it is not "utterly impossible". >> >> Let's dispense with the hyperbolas, exaggerations, and "10 orders of >> magnitude harder". > > I didn't say that. I said one to two orders. You did say "utterly impossible" (and yes, I know it wasn't /you/ who said "10 orders of magnitude"). Lets look at /real/ figures. The C11 standard is about 700 pages. The C++11 standard is about 1300 pages. While they are not directly equivalent, that gives a pretty good and entirely objective starting point. > >> C++ is a bigger and more complex language than C - >> but most serious C compilers are also C++ compilers, and a great many >> people manage to write perfectly good working C++ code despite being far >> less competent programmers than you (and I'm not being sarcastic here). >> >> You /choose/ to use C, rather than C++. That's fine. I am sure you >> have perfectly good reasons for it - and perhaps some less good reasons. >> There are plenty of situations where C is a better choice than C++. >> >> But C++ is not "utterly impossible" - it is a real language, with real >> compilers and real users, and people use it to write real code. > > And real people choose not to use it. Why is that? I just think it's a > horrible language (C# is a much better take on it, if you like that sort > of thing.) Of course some people choose to use it, and some people choose something different. And of course some people think it is horrible, and others think it is great. But because so many people happily and successfully use it, it is clear that "C++ is a horrible language" and "utterly impossible" are nothing more than exaggerated personal opinion. There is nothing wrong with personal opinions, as long as you don't pretend that they are facts. I don't remember ever being in an eating place with less pleasant food than McDonald's. But it would be a bit unreasonable for me to claim that Big Mac's are "totally inedible". > > (BTW could /you/ create a C++ compiler from scratch? Ie. not relying on > other people's efforts.) Given enough time, yes. And it would take me longer than creating a C compiler from scratch. But I would not do so - I think making either a C compiler or a C++ compiler from scratch is a silly idea these days, and certainly not something that makes sense for a single person to do. (I have only ever made interpreters for a couple of very simple domain-specific languages, and helped and advised a little on some embedded compilers, especially around code generation and optimisation. But I know enough of the principles of compiler design to know the basics, I have long experience in assembly programming, and I know where to go to get the information I need to write a full compiler. This makes me confident in saying that I /could/ write one - and also confident in saying I should not do so!) > >>> Most of it isn't even a proper >>> language, but consists of an elaborate set of language-building >>> features. Why build in a feature - flexible arrays for example - when >>> you can instead add dozens of features to allow the programmer to >>> construct his own DIY version! (A large-scale version of C's macro >>> system perhaps.) >> >> I don't follow your complaint. Are you telling us that it is a terrible >> idea for C++ to provide building blocks like classes and templates that >> lets people make a wide variety of container types, when they could >> simply have added variable length arrays (which for some reason that is >> beyond my comprehension, seems to be the most hated feature of C99)? > > I don't mean C's VLAs, but flexible arrays, strings etc in general. What > you might expect of a language the next level up from C. > > Language building features as you find in C++ I don't really agree what, > not when they are part of the normal language available to everyone. > (Because they they will get abused and people will delight in writing > impenetrable code. A bit like they like to do with C's macros.) Certainly there can be advantages in making such features (arrays, lists, strings, maps, etc.) a direct part of the language - rather than making the building blocks part of the language and then having the user-level features as part of the library. It goes both ways - C++ gives you more flexibility, and thus more scope for writing /good/ code and more scope for writing /bad/ code. Many other high-level languages make lists, strings, and maps fundamental parts of the language. It's a different choice, a different balance - and has different pros and cons. If you want to look at a "next level up from C", then C++ doesn't seem to suit what you want in a language. An obvious alternative to consider would be D - and there are other newer languages like Go and Rust (neither of which I am familiar with). Just because C++ does not fit what /you/ want, does not make it fundamentally flawed or some sort of terrible language! > >>> Tiny C is about 0.15MB and does a pretty good job. But then it can be >>> lean and streamlined because it only concerns itself with C. >>> >> >> It is also a very much simpler compiler, with an emphasis on the size of >> the compiler rather than the size or speed of the generated code. It >> does not have close to the feature range of gcc, the flexibility, or the >> optimisations. >> >> There are three key reasons why gcc's binaries are much bigger than >> TCC's. First is flexibility - mainline gcc supports eight source >> languages directly, with some support for a few others. It supports >> several dozen targets, many with dozens of variations. It even supports >> dozens of human languages for its warnings and errors. > > I don't believe that all the targets, all the front-ends, and all > possible human languages for messages are lumped together in that one > executable. Perhaps some of the other 1200MB that I haven't yet > mentioned has something to do with it! No, of course they are not all included in the executable - but making a compiler that is flexible enough to support all that inevitably makes it a lot bigger than one that is more specialised. (And I don't think you'll find anyone claiming that gcc is a model of efficient design - it is a massive project that stretches back 20 years or so, with thousands of contributors.) > > And also, why would a distribution specifically for Windows include > targets that are irrelevant to Windows? It won't /include/ those targets, but the structure for supporting different targets and hosts is there, even though most of the detail is disabled through conditional compilation, macros, static inlines, and makefiles. > >> It includes >> emulators for integer and floating point operations on the target >> systems, so that any compile-time calculations match identically to the >> results you would get on the target, even for cross-compilation. All >> this costs space, and run-time, even when configured for a single >> language and target. > > Sure. The last floating point emulation package I did occupied 4KB of > code! (Well, either 4KB or 8KB. This would be for x86.) It is not that kind of emulation... gcc includes a whole library to simulate integer and (especially) floating point hardware for different targets. When you write in your code "x = (y * 123.4) / 492.1;", the most efficient object code would involve a single multiply by the constant 123.4/492.1. But will that give /exactly/ the results you would expect from doing the calculations as written, to within the rules specified by the C standards and/or IEEE standards and/or modified by compiler flags? gcc has libraries to let it figure this out, and do the calculations as they would be done on the target, even if the target is not the same as the host. While this clearly makes most difference during cross-compilation, it can even apply to using a 64-bit Windows gcc to compiler for 32-bit Windows. By passing this sort of thing through the library, gcc can be sure of the results - even though in the huge majority of cases for native compilation the results are exactly the same as you would get by doing the calculations directly. > >> The second is optimisation - gcc aims to produce as high quality code as >> possible. This follows a law of diminishing returns - getting the last >> few percent of speed out of the last few source code constructs will >> take a lot more code space than getting the first few percent of speed. > > Yes, getting the best possible code is difficult. But difficulty doesn't > necessary mean colossal amounts of code. Algorithms don't usually run to > a million lines of source. Sometimes, sometimes not. If you want answers, just browse some of the source code for gcc. Look at which files or directories have the largest line count, and try to see what might be the purpose of them. (About have the code lines are in the "testsuite" directory, which would not be part of the compiler binary.) I had a quick look in the main "gcc" source directory for gcc 4.9, which I have lying around (this is the compiler itself - not target libraries, include files, etc.). There are about 30 MB of files here. The directory of C specific files is 1.4 MB, and there is of course common directories and a "c-family" directory. The "cp" directory for C++ is 5.6 MB. It is smaller than the "fortran" directory, and a small fraction of the size of the "ada" directory. > >> Sure, tcc does a good job at what it aims to do. But it does not aim to >> complete with or replace gcc - it aims to be a workable C compiler in >> minimal space. It is only comparable to gcc in the way that a bicycle >> is comparable to a vehicle that can double as a bus, a lorry, a tractor, >> and a racing car, with attachments for converting it to a plane or a >> submarine. > > If someone was to come out with a C compiler that produced as good code > as gcc, but was a tenth the size and worked ten times as fast, would you > still consider it a bicycle? If it doesn't have the features of gcc that I use (which go well beyond the simple act of native-code compilation), then it still would not do the job. It might be a motorcycle rather than a bicycle :-) > > Or does being big, slow and cumbersome guarantee that something is better? Of course not - but being really small and fast /does/ guarantee limited capabilities. (Though being big and slow does not guarantee that you have any extra useful features.) There is one serious competitor to gcc - clang/llvm. It is also big, slow and cumbersome compared to something like tcc - but smaller and significantly faster than gcc. It is comparable to gcc in features in some areas, lagging greatly in others, and leading in a few points. I will be quite happy to move to it when I feel it is ready for my usage, unless of course gcc has moved beyond it again in the meantime. (The two projects push each other - the competition has encouraged a lot of improvements on both sides.) But when choosing a compiler, I don't care much about the size of the compiler. I might care more if I had to use 11 GB MSVC packages, but a few hundred MB installation size is not an issue. I don't care much about compile times (again, within reason), because they programs I work with don't tend to be so big. But I /do/ care about features - static warning analysis, support for modern standards, useful extensions, helpful error messages. I /do/ care about generating small and fast code. I /do/ care about a serious emphasis on code correctness, with an open attitude to bugs and extensive test suites. I /do/ care about additional features such as convenient generation of makefile dependencies. I /do/ care about a support community, and a development community. And I /do/ care about support for a wide variety of targets. And I /do/ care about good C++ support - even though most of my work is in C for now, C++ is becoming much more relevant for me. If gcc has to be big, slow and cumbersome to achieve that, then that's fine by me. > > TCC isn't far off: it's one hundredth the size, compiles a hundred times > faster, but it's code might be half the speed as gcc. I wouldn't quickly > dismiss such an achievement. > I don't dismiss the achievement of TCC - but it has achieved the goal of making a reasonable and practical simple C compiler in a very small package. /That/ is its goal. The author aimed to make a bicycle, not a bus/lorry/racing car. And sometimes a bicycle is exactly what you need. But no one would seriously consider TCC as an alternative to gcc for normal usage.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-27 07:17 -0700 |
| Message-ID | <f6eb921d-f919-4013-b37c-7fcc0994f27b@googlegroups.com> |
| In reply to | #68485 |
On Thursday, August 27, 2015 at 6:55:38 AM UTC-4, Bart wrote: > (As for performance, in the case of one of my recent interpreter > projects, using my own 'toy' compiler made it 27% slower than gcc, and > 15% slower than clang. Not a lot really! When I add in a > runtime-switchable ASM layer, then I can get 40% faster than gcc and 53% > faster than clang!) I wanted to compliment your complement of skills here, Bart. That is awesome performance. When I read this I actually though to myself, "That is awesome!" :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-27 16:24 +0100 |
| Message-ID | <mrn9vq$gv4$1@dont-email.me> |
| In reply to | #68489 |
On 27/08/2015 15:17, Rick C. Hodgin wrote: > On Thursday, August 27, 2015 at 6:55:38 AM UTC-4, Bart wrote: >> (As for performance, in the case of one of my recent interpreter >> projects, using my own 'toy' compiler made it 27% slower than gcc, and >> 15% slower than clang. Not a lot really! When I add in a >> runtime-switchable ASM layer, then I can get 40% faster than gcc and 53% >> faster than clang!) > > I wanted to compliment your complement of skills here, Bart. That is > awesome performance. When I read this I actually though to myself, > "That is awesome!" :-) Well, interpreters are rather specialised applications. But it is the case that without trying very hard, it's easy for a naive code generator to produce output that is half the speed of gcc -O3 code - in general. (There will be the odd benchmark that performs a lot worse, and some code that will be nearly up there with gcc.) But with real applications, and especially ones that spend a lot of time in calls to external libraries, then the difference narrows. Still, I do get a kick out of writing some ASM and wiping the floor with gcc despite its millions of lines of code, hundreds of contributors and years of development. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-08-27 18:58 +0200 |
| Message-ID | <20150827185838.15ade349@maxa-pc> |
| In reply to | #68491 |
On Thu, 27 Aug 2015 16:24:11 +0100 Bartc <bc@freeuk.com> wrote: > > Still, I do get a kick out of writing some ASM and wiping the floor > with gcc despite its millions of lines of code, hundreds of > contributors and years of development. > Depends on program and gcc version. I find that it is not easy to wipe the floor with gcc writing asm. Sure , hand written asm is more compact but question is if it can always be faster... Care to give code examples ?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-27 20:35 +0100 |
| Message-ID | <mrnomf$gk6$1@dont-email.me> |
| In reply to | #68498 |
On 27/08/2015 17:58, Melzzzzz wrote: > On Thu, 27 Aug 2015 16:24:11 +0100 > Bartc <bc@freeuk.com> wrote: > >> >> Still, I do get a kick out of writing some ASM and wiping the floor >> with gcc despite its millions of lines of code, hundreds of >> contributors and years of development. >> > > Depends on program and gcc version. I find that it is not easy to wipe > the floor with gcc writing asm. > Sure , hand written asm is more compact but question is if it can > always be faster... > > Care to give code examples ? This was in a specific context of writing interpreters. They are rather special applications also because it's worthwhile spending a lot of time optimising them (because it can benefit potentially thousands of apps at the same time). And an interpreter can always run a bit faster. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-08-27 13:07 -0700 |
| Message-ID | <b7ecbea8-17ef-4fb2-b9cf-dacae4dd71cb@googlegroups.com> |
| In reply to | #68485 |
W dniu czwartek, 27 sierpnia 2015 12:55:38 UTC+2 użytkownik Bart napisał: > > If they are the only way to implement the flexible array example from > above, then you could be right! (But I've created languages with > flexible arrays without needing to add classes, multiple inheritance, > overloading, templates or any of that stuff.) > which year and how do you implemented them? its amazing that languages had no simple form of flexible arrays i was recently saing about.. (the one with simple pointer and realloc) (to complete with the one with fixups, and tis one with adding removing physical pages to virtual reserve) I thing people didnt do that becouse they just were thinking it is impossible..until i discovered (at least for myslef) this is quite possible
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-27 21:36 +0100 |
| Message-ID | <mrnsa5$vqq$1@dont-email.me> |
| In reply to | #68508 |
On 27/08/2015 21:07, fir wrote: > W dniu czwartek, 27 sierpnia 2015 12:55:38 UTC+2 użytkownik Bart napisał: >> >> If they are the only way to implement the flexible array example from >> above, then you could be right! (But I've created languages with >> flexible arrays without needing to add classes, multiple inheritance, >> overloading, templates or any of that stuff.) >> > > which year and how do you implemented them? Probably late 1980s, but this was with interpreted languages where such things are simpler. The point is that a language can choose to directly provide such a feature rather than a toolkit so that people have to implement it themselves. > its amazing that languages had no simple form of flexible arrays i was recently saing about.. > (the one with simple pointer and realloc) When you get into it, it's not so straightforward, so all the more reason why the language should take more of a hand (and not have to drag in the heavy guns of OO). For example, suppose you have such an array, but you copy it to another, or set up a pointer/slice to it; when and how does the memory then get freed? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-08-27 14:31 -0700 |
| Message-ID | <25d481ec-1d01-46aa-8abd-69cf51e2fdac@googlegroups.com> |
| In reply to | #68515 |
code acceses this array by pointer (named 'table' for example) this pointer is always 'synchronised' (same with this table length) so it will be just working... if clients know the name of the teble they also know the pointer and size field - evwrything will be fine for sure one there only wait for c compiler that began tu support this resizable arays for coders
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-28 08:25 +1200 |
| Message-ID | <d49a1mFrgntU7@mid.individual.net> |
| In reply to | #68485 |
Bartc wrote: > On 27/08/2015 09:40, David Brown wrote: > > Fun compilers can be viable; see below. > > I guess I could write an actual C compiler given enough inclination. (It > would be a pretty crappy one, but it would work.) But there is > absolutely no way I could write a C++ compiler. > > The language is just utterly impossible. Obvious nonsense, compilers exist and people use them. Moving on... > But I doubt that any amount of debate will convince anyone here. Not > when I complain about an 11GB download for MSVC, and people are just > bemused by the size instead of being concerned (as happened in a recent > thread). The Visual Studio professional 2015 ISO is 3.7GB. Don't forget you are downloading the house to get at the kitchen sink. >> I did a quick check of the sizes of the C and C++ gcc compilers on my >> system. The main C++ binary, cc1plus, is /massive/ - it is 107 MB >> (including debugging symbols, which are not necessary in the binary but >> perhaps a useful indication of the complexity involved). It's a big, >> complex tool. >> >> But for comparison, the main C binary, cc1, is 101 MB. That is a mere >> 6% smaller. That is the sort of difference C or C++ makes in real-world >> compilers. > > Where do you get the 100MB size from? On my mingw gcc, there is a basic > 1.8MB gcc executable, plus a 12MB cc1 file, and a 13MB cc1plus file. My un-stripped binary sizes are similar to Davids (111MB and 120MB). My full gcc4.9.2 (compressed) filesystem occupies 159MB. >> But remember, pretty much all of C++'s features are there because people >> find them useful. > > If they are the only way to implement the flexible array example from > above, then you could be right! (But I've created languages with > flexible arrays without needing to add classes, multiple inheritance, > overloading, templates or any of that stuff.) C++ made the sensible design choice to place such components in the library, not the core language. Having the mechanisms that make this possible is one of the greatest strengths of C++. Your language would have had your design of a flexible array (and I guess, string), if it didn't match what a user wanted, tough. Complex number are another good example where the core C language had to be changed to support something which is a trivial library class in C++. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web