Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #25009 > unrolled thread
| Started by | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| First post | 2012-08-26 03:57 -0600 |
| Last post | 2012-09-07 06:18 -0700 |
| Articles | 20 on this page of 226 — 44 participants |
Back to article view | Back to comp.lang.c
C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 03:57 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-26 12:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 13:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:34 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:44 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) jacob navia <jacob@spamsink.net> - 2012-08-26 12:32 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 05:11 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 14:16 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Varun Tewari <tewari.varun@gmail.com> - 2012-08-26 09:38 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-08-27 06:29 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Barry Schwarz <schwarzb@dqel.com> - 2012-08-26 10:03 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 14:00 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) jacob navia <jacob@spamsink.net> - 2012-08-26 19:54 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:00 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 14:19 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 23:50 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 09:43 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:24 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 10:21 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 10:57 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 09:42 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 15:59 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:26 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 23:41 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 10:40 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:34 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 12:40 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 14:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 15:32 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 16:04 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 17:57 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 18:45 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-28 18:08 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 20:44 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 14:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 22:36 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 16:56 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 18:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-08-28 15:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 19:09 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 19:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 09:25 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 12:39 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 09:41 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 10:19 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 10:44 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 12:24 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:13 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 08:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 14:49 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Adrian Ratnapala <raka@scooter.fritz.box> - 2012-08-30 04:44 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> - 2012-08-30 00:20 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 09:01 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-29 16:19 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:17 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-07 14:22 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-09-10 17:21 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:03 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 05:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 20:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 00:07 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-29 21:51 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 15:24 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 22:47 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 16:59 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-28 17:07 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-08-27 16:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 00:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-27 16:15 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:20 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 15:05 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 14:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-27 14:29 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-26 21:08 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey@Carter.net> - 2012-08-27 21:47 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-27 22:34 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 12:24 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 21:02 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 21:15 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:00 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Melzzzzz <mel@zzzzz.com> - 2012-08-28 23:12 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 17:30 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Melzzzzz <mel@zzzzz.com> - 2012-08-28 23:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 10:09 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 18:01 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 12:03 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Dombo <dombo@disposable.invalid> - 2012-09-02 22:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 16:25 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-28 23:03 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 08:02 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 10:12 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 20:36 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-29 12:08 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 13:49 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 19:16 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 14:34 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 19:41 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 14:05 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-29 17:53 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 09:47 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 10:17 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-31 05:59 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-31 14:29 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-01 06:45 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-30 08:05 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 14:54 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 18:13 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-30 18:39 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Garrett Hartshaw <ghartshaw@gmail.com> - 2012-08-30 13:49 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-30 14:07 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-31 11:13 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-31 13:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-09-03 10:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-31 10:55 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-31 00:18 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-30 17:30 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-31 14:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-31 19:34 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-31 17:24 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nobody <nobody@nowhere.com> - 2012-09-02 01:10 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 05:57 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-07 14:17 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 19:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Garrett Hartshaw <ghartshaw@gmail.com> - 2012-08-30 22:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-31 14:53 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 19:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-05 23:44 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 23:08 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-06 07:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-06 09:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Dombo <dombo@disposable.invalid> - 2012-09-02 23:16 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 20:27 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-30 13:57 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-30 12:25 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-31 11:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-31 11:58 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) "io_x" <a@b.c.invalid> - 2012-09-01 19:09 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 20:49 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 20:09 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 22:33 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 21:43 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 23:23 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 17:21 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 09:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-30 13:53 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 18:51 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Les Cargill <lcargill99@comcast.com> - 2012-08-31 21:15 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 23:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Luca Risolia <luca.risolia@studio.unibo.it> - 2012-08-30 02:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 09:11 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 08:46 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> - 2012-08-30 08:39 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 21:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 12:18 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-28 13:00 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Ike Naar <ike@iceland.freeshell.org> - 2012-08-28 22:47 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-28 19:32 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 20:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-28 16:55 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-26 19:49 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:41 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 21:01 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Ceriousmall <divadsmall@gmail.com> - 2012-08-27 04:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-27 08:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-01 10:35 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-01 12:47 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:08 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-09-11 11:14 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-11 15:14 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 01:01 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 04:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 06:31 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 10:16 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 07:27 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 07:58 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 04:24 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 16:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 10:21 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 18:59 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 14:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 20:36 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 16:57 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-13 11:36 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 12:03 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-13 13:30 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 21:32 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-13 15:13 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-13 07:33 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-14 03:35 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 12:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:35 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:31 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:33 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-13 14:16 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 14:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 05:15 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-14 03:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-14 13:58 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-14 08:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-14 08:33 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:37 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:36 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:38 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:49 -0800
Re: C as a Subset of C++ (or C++ as a superset of C) Ian Collins <ian-news@hotmail.com> - 2012-12-18 12:11 +1300
Re: C as a Subset of C++ (or C++ as a superset of C) "io_x" <a@b.c.invalid> - 2012-09-13 12:04 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-12 11:42 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-13 13:00 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:07 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-05 14:57 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-05 15:29 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kaz Kylheku <kaz@kylheku.com> - 2012-09-01 22:45 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-09-02 01:07 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:35 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Kaz Kylheku <kaz@kylheku.com> - 2012-09-02 21:35 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:30 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) mike3 <mike4ty4@yahoo.com> - 2012-09-12 15:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 05:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:18 -0700
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-12 07:27 -0700 |
| Message-ID | <c72bc4b4-4ad4-426b-9452-8c3b68e93448@s2g2000vbj.googlegroups.com> |
| In reply to | #26239 |
On Sep 12, 3:16 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 09/12/2012 09:31 AM, Nick Keighley wrote: > > > On Sep 12, 12:40 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> > > wrote: > ... > >>>> Yes, we badly need one programming language that does everything. > ... > > ... is there a current langauage thate meets your > > criteria? > > I believe that "we badly need" implies that he knows of no such language. ok. is there one that matches most of the requirement? I'm dubious that a language can have address safety, generics, metacode and builtit serialization whilst still preserving the low level access that is one of C's powers.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-12 07:58 -0700 |
| Message-ID | <561f2b10-b099-49ea-8499-11500135936e@googlegroups.com> |
| In reply to | #26238 |
בתאריך יום רביעי, 12 בספטמבר 2012 14:31:18 UTC+1, מאת Nick Keighley: > On Sep 12, 12:40 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> > >> I'd say it needs essentially C syntax - loops, curly brackets, non-flow >> control non-arithemtical functionality implemented as functions rather than >> the core language. That's generally been accepted. > > > by whom? You seem to saying we need a single low level procedural > language. I'm not sure your wish-list is consistent. lets call it > Single Procedural Language (SPL) > Most modern new languages go for curly braces and a superfically at least C-like syntax. But there are exceptions, of course. If there were no exceptions at all then saying "we need essential C-like syntax" would be as fatuous as saying "we should standardise on Arabic numerals".
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-13 04:24 -0700 |
| Message-ID | <93683db3-8f6e-429f-9bdf-f75bfcdf8b4e@s14g2000vba.googlegroups.com> |
| In reply to | #26241 |
On Sep 12, 3:58 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > בתאריך יום רביעי, 12 בספטמבר 2012 14:31:18 UTC+1, מאת Nick Keighley:> On Sep 12, 12:40 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> > >> I'd say it needs essentially C syntax - loops, curly brackets, non-flow > >> control non-arithemtical functionality implemented as functions rather than >> the core language. That's generally been accepted. > > > by whom? You seem to saying we need a single low level procedural > > language. I'm not sure your wish-list is consistent. lets call it > > Single Procedural Language (SPL) > > Most modern new languages go for curly braces and a superfically at least > C-like syntax. but considerable differences in semantics > But there are exceptions, of course. If there were no exceptions > at all then saying "we need essential C-like syntax" would be as fatuous as > saying "we should standardise on Arabic numerals". it wasn't the syntax I had a problem with. It was the semantic wish- list. I suspect C-like syntax isn't the "best possible" syntax but its well known and widely used. I'm not sure what SPL is for.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-09-12 16:21 +0100 |
| Message-ID | <k2q9at$m7p$1@dont-email.me> |
| In reply to | #26237 |
"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message news:7073a8f9-488c-4f6a-9a32-42e8f2b161cc@googlegroups.com... > בתאריך יום רביעי, 12 בספטמבר 2012 09:01:53 UTC+1, מאת Nick Keighley: >> On Sep 11, 11:14 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> >> >> oh. I assumed you were proposing Lisp *as* the universal hammer. Which >> blub are you proposing then? PL/I was the last attempt. >> > I'd say it needs essentially C syntax - loops, curly brackets, non-flow > control non-arithemtical functionality implemented as functions rather > than the core language. That's generally been accepted. Not by everyone. Or it's been forced on them. A number of syntax styles are possible for a given language, of which C-style is one, characterised by too much punctuation and lots of curly braces. > Also the proliferation of integer types is unacceptable. Proliferation? Typically there are 8 combinations of signed/unsigned, and width (8,16,32,64 bits). For discrete int variables, you might only use one or two. For packed arrays and structs, you need to have the choice. > But C itself isn't a good universal language, because of the buffer > overflow and wild pointer issue. Also because of the difficulties in > representing higher-level contructs, like classes, graphs, and metacode. > Even structs have no way of serialising without writing special functions > for each case. No, C is hopeless. There are plenty of improvements that can be made(**), but you will just end up with some ghastlier version of C++. I don't believe a single universal language can be created that will please everyone. (** I recently finished designing a low-level implementation language that pretty much does what C does. When I listed the differences (mostly improvements in my view!) from C, I stopped when I got to 100. And that didn't include syntax which is utterly different. But then, it's not hard to tidy up a language that's 40 years old.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-12 10:21 -0700 |
| Message-ID | <bfbe86f3-a190-48c4-be35-ab22ec5b3876@googlegroups.com> |
| In reply to | #26242 |
בתאריך יום רביעי, 12 בספטמבר 2012 16:22:06 UTC+1, מאת Bart: > "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message > > > Proliferation? Typically there are 8 combinations of signed/unsigned, and > width (8,16,32,64 bits). For discrete int variables, you might only use one > or two. For packed arrays and structs, you need to have the choice. > Consider this int16 *readaudiosamples(void *context); void playaudiosamples(short *wave, int N);
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-09-12 18:59 +0100 |
| Message-ID | <k2qij0$l5b$1@dont-email.me> |
| In reply to | #26245 |
"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message news:bfbe86f3-a190-48c4-be35-ab22ec5b3876@googlegroups.com... > בתאריך יום רביעי, 12 בספטמבר 2012 16:22:06 UTC+1, מאת Bart: >> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message >> >> >> Proliferation? Typically there are 8 combinations of signed/unsigned, and >> width (8,16,32,64 bits). For discrete int variables, you might only use >> one >> or two. For packed arrays and structs, you need to have the choice. >> > Consider this > > int16 *readaudiosamples(void *context); > void playaudiosamples(short *wave, int N); What about it? Audio probably *is* best handled as blocks of 16-bit data. But the example uses 3 different int denotations, with probably two different widths; is that the trouble? I've already made the point that C could be improved, with regard to managing these various different types. But I doubt whether you're seriously proposing using actual C syntax, rather than C-style, as the basis for your universal language. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-12 14:01 -0400 |
| Message-ID | <5050CE07.3000307@verizon.net> |
| In reply to | #26242 |
On 09/12/2012 11:21 AM, BartC wrote: > "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message > news:7073a8f9-488c-4f6a-9a32-42e8f2b161cc@googlegroups.com... ... >> Also the proliferation of integer types is unacceptable. > > Proliferation? Typically there are 8 combinations of signed/unsigned, and > width (8,16,32,64 bits). I count a lot more than 8. There's a minimum of 12 integer types that must be distinct on all implementations (even though one pair of them must have the same size, alignment requirement and representation, and other pairs might also match): _Bool [unsigned | (plain) | signed] char: 3 [unsigned | signed] [short | int | long | long long]: 8 Each of the following types could be the same as one of the above, or a distinct extended integer type: [u]intN_t: none mandatory [u]int_leastN_t: 8 mandatory [u]int_fastN_t: 8 mandatory [u]intmax_t: 2 [u]intprt_t: 2 size_t, ptrdiff_t, wchar_t, char16_t, char32_t atomic_ versions of all of the above: total of 37 mandatory. sig_atomic_t, wint_t That's a total of 74 mandatory types that are required to be integers, and in principle they could all be distinct types. In addition, all of the following types could be integer types (though they don't have to be), and don't have to be the same as any of the above: fpos_t, cnd_t, thrd_t, tss_t, mtx_t, clock_t, time_t, max_align_t, mbstate_t, wctrans_t, wctype_t The important thing is not that they could all be distinct - that's highly unlikely - in all likelihood they span not much more than a dozen distinct types. The important point is that it's difficult, in general, to determine which ones are the same. It used to be impossible, but the new _Generic feature of C2011 makes it possible, at least at run time, if not at compile time. However, it's still not easy)
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-09-12 20:36 +0100 |
| Message-ID | <k2qpem$4ki$1@dont-email.me> |
| In reply to | #26248 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5050CE07.3000307@verizon.net... > On 09/12/2012 11:21 AM, BartC wrote: >> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message >> news:7073a8f9-488c-4f6a-9a32-42e8f2b161cc@googlegroups.com... > ... >>> Also the proliferation of integer types is unacceptable. >> >> Proliferation? Typically there are 8 combinations of signed/unsigned, and >> width (8,16,32,64 bits). > > I count a lot more than 8. There's a minimum of 12 integer types that > must be distinct on all implementations (even though one pair of them > must have the same size, alignment requirement and representation, and > other pairs might also match): > _Bool > [unsigned | (plain) | signed] char: 3 > [unsigned | signed] [short | int | long | long long]: 8 > > Each of the following types could be the same as one of the above, or a > distinct extended integer type: > [u]intN_t: none mandatory > [u]int_leastN_t: 8 mandatory > [u]int_fastN_t: 8 mandatory > [u]intmax_t: 2 > [u]intprt_t: 2 > size_t, ptrdiff_t, wchar_t, char16_t, char32_t > atomic_ versions of all of the above: total of 37 mandatory. > sig_atomic_t, wint_t > > That's a total of 74 mandatory types that are required to be integers, > and in principle they could all be distinct types. This is just C trying to make things difficult. I thought Malcolm was suggesting the use of a single int type instead of the four common widths supported by many CPUs (plus signed/unsigned variations). Perhaps dealing with all my eight types isn't a big deal after all.. In your list, I wouldn't include _Bool as an 'int' type; it can be considered a type in it's own right. While the char types are just synonyms for ints, really (unless they behave in any way differently to an int of the same width and sign?). And on typical machines I use, char is 8 bits, short is 16 bits, int is 32 bits, and long long is 64 bits. 'long' seems to be either 32 or 64 bits. (Maybe there are machines that use odd sizes such as 24/48 bits, or that support 96/128-bit ints, but not 'typical'.) Everything else is imposed by the language (including all those UINT_MINs and INT_MAXs). I doubt a 'universal' language would use the same approach. (I use 'int' and 'word' for signed/unsigned integers of natural width; int:N and word:N for specific bitwidths, and int*N and byte*N for specific bytewidths; while 'byte' is a synonym for word:8. For value ranges, I use int.min, word.max and so on.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-12 16:57 -0400 |
| Message-ID | <5050F71F.80902@verizon.net> |
| In reply to | #26250 |
On 09/12/2012 03:36 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5050CE07.3000307@verizon.net... ... >> I count a lot more than 8. There's a minimum of 12 integer types that >> must be distinct on all implementations (even though one pair of them >> must have the same size, alignment requirement and representation, and >> other pairs might also match): >> _Bool >> [unsigned | (plain) | signed] char: 3 >> [unsigned | signed] [short | int | long | long long]: 8 >> >> Each of the following types could be the same as one of the above, or a >> distinct extended integer type: >> [u]intN_t: none mandatory >> [u]int_leastN_t: 8 mandatory >> [u]int_fastN_t: 8 mandatory >> [u]intmax_t: 2 >> [u]intprt_t: 2 >> size_t, ptrdiff_t, wchar_t, char16_t, char32_t >> atomic_ versions of all of the above: total of 37 mandatory. >> sig_atomic_t, wint_t >> >> That's a total of 74 mandatory types that are required to be integers, >> and in principle they could all be distinct types. > > This is just C trying to make things difficult. > > I thought Malcolm was suggesting the use of a single int type instead of the In a C context, 'int' is the name of a specific type, and a component (usually optional) of the names of several other types, but it is not an adjective. The adjective you're looking for is "integer", not "int". > four common widths supported by many CPUs (plus signed/unsigned variations). > Perhaps dealing with all my eight types isn't a big deal after all.. Malcolm does indeed believe in having a single integer type. I don't. I agree with him that there are too many integer types, but he would trim the type system far more than I would, if either of us had to the power to do so without worrying about backwards compatibility. > In your list, I wouldn't include _Bool as an 'int' type; it can be > considered a type in it's own right. It is considered a type in it's own right, but like most other types, that type is also defined by the standard as being a member of a specific type category, the standard unsigned integer types (6.2.5p6). As a result, it is also a member of several other standard-defined type categories: unsigned integer types, integer types, basic types, real types, arithmetic types, and scalar types. (6.2.5) > ... While the char types are just synonyms > for ints, really (unless they behave in any way differently to an int of the > same width and sign?). The char types are integer types (6.2.5p17). The [u]int8_t and [u]int_*8_t types are likely to be typedefs for char types on any machine with CHAR_BIT==8, but calling 'unsigned char" a synonym for uint_least8_t reverses the roles of the two types. > And on typical machines I use, char is 8 bits, short is 16 bits, int is 32 > bits, and long long is 64 bits. I've already acknowledged that the 12 integer types that a conforming implementation of C is required to support as distinct types need not have distinct characteristics. In fact, plain char is required to have exactly the same characteristics as either "signed char" or "unsigned char". The important point is that, while some of them might be implemented identically, the standard still requires that they all be treated as distinct types, and there's no guarantees as to which pairs of types are implemented identically. For the full set of types I listed above, many of them are likely to be aliases for one of the 12 mandatory types. On implementations with extended integer types, many pairs of the other types I listed are likely to be aliases for the same extended integer type. However, the key point is that there's no pairs in that list which are guaranteed to be aliases for the same type; portable code must assume that any two of them might be distinct types. ... > (I use 'int' and 'word' for signed/unsigned integers of natural width; int:N > and word:N for specific bitwidths, and int*N and byte*N for specific > bytewidths; while 'byte' is a synonym for word:8. For value ranges, I use I strongly recommend against using non-standard definitions for terms defined by the C standard such as 'int' and 'byte' in this newsgroup - it can only lead to confusion. 'int' is a C standard type, which need not have what you consider the "natural width". The C standard defines 'byte' as an "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment"; if CHAR_BIT != 8, that doesn't match your definition. The standard doesn't define a meaning for 'word', so that's one you can freely muck around with.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-09-13 11:36 +0100 |
| Message-ID | <k2scv4$9n6$1@dont-email.me> |
| In reply to | #26259 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5050F71F.80902@verizon.net... > On 09/12/2012 03:36 PM, BartC wrote: >> (I use 'int' and 'word' for signed/unsigned integers of natural width; >> int:N >> and word:N for specific bitwidths, and int*N and byte*N for specific >> bytewidths; while 'byte' is a synonym for word:8. For value ranges, I use > > I strongly recommend against using non-standard definitions for terms > defined by the C standard such as 'int' and 'byte' in this newsgroup - > it can only lead to confusion. That was an example of a different approach (in my own language) to dealing with families of integer types. But this morning I had better luck in finding the datatypes used by Go (a modern language with C-style syntax) and that uses: uint8, uint16, uint32, uint64 int8, int16, int32, int64 While C# uses: byte, ushort, uint, ulong of sizes 8, 16, 32, 64 sbyte, short, int, long of sizes 8, 16, 32, 64 All pretty much corresponding to the 8 integer types that I said were typical. So where is size_t and ptr_diff_t amongst that lot? See, it's possible to manage without it! So C's approach *does* seem untidy. However, the context in this subthread was whether C was a suitable starting point for a hypothetical universal language. Since such a language would need to incorporate, amongst many other extremes, the type handling of Ada, with that of Python, plus all the manipulations allowed by C, then that's obviously a non-starter. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-13 12:03 +0100 |
| Message-ID | <0.ab886e10d5b5b755b446.20120913120318BST.87wqzyi3rd.fsf@bsb.me.uk> |
| In reply to | #26293 |
"BartC" <bc@freeuk.com> writes: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5050F71F.80902@verizon.net... >> On 09/12/2012 03:36 PM, BartC wrote: > >>> (I use 'int' and 'word' for signed/unsigned integers of natural width; >>> int:N >>> and word:N for specific bitwidths, and int*N and byte*N for specific >>> bytewidths; while 'byte' is a synonym for word:8. For value ranges, I use >> >> I strongly recommend against using non-standard definitions for terms >> defined by the C standard such as 'int' and 'byte' in this newsgroup - >> it can only lead to confusion. > > That was an example of a different approach (in my own language) to dealing > with families of integer types. But this morning I had better luck in > finding the datatypes used by Go (a modern language with C-style syntax) and > that uses: > > uint8, uint16, uint32, uint64 > int8, int16, int32, int64 Go also has int, uint and uintptr with implementation-defined widths. > While C# uses: > > byte, ushort, uint, ulong of sizes 8, 16, 32, 64 > sbyte, short, int, long of sizes 8, 16, 32, 64 (C# has a type char which is also considered to be an integral type.) > All pretty much corresponding to the 8 integer types that I said were > typical. > > So where is size_t and ptr_diff_t amongst that lot? See, it's possible to > manage without it! So C's approach *does* seem untidy. Go has some of these. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-09-13 13:30 +0100 |
| Message-ID | <k2sjli$gfh$1@dont-email.me> |
| In reply to | #26295 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:0.ab886e10d5b5b755b446.20120913120318BST.87wqzyi3rd.fsf@bsb.me.uk... > "BartC" <bc@freeuk.com> writes: >> That was an example of a different approach (in my own language) to >> dealing >> with families of integer types. But this morning I had better luck in >> finding the datatypes used by Go (a modern language with C-style syntax) >> and >> that uses: >> >> uint8, uint16, uint32, uint64 >> int8, int16, int32, int64 > > Go also has int, uint and uintptr with implementation-defined widths. OK, int and uint are described a few lines further down. They are just integers with default width for that machine (which I suspect will be either 32 or 64 bits). That's even closer to my approach (no width specified it uses a default, currently 32 bits). uintptr will follow from that. (That could be said to be similar to what C does with it's int and intxx_t, except that I believe that intxx_t types are defined in terms of ints (short, long int etc) instead of the other way around.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-13 21:32 +0100 |
| Message-ID | <0.3de265f1672a51263216.20120913213234BST.87a9wtirz1.fsf@bsb.me.uk> |
| In reply to | #26301 |
"BartC" <bc@freeuk.com> writes: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:0.ab886e10d5b5b755b446.20120913120318BST.87wqzyi3rd.fsf@bsb.me.uk... >> "BartC" <bc@freeuk.com> writes: >>> That was an example of a different approach (in my own language) to >>> dealing >>> with families of integer types. But this morning I had better luck in >>> finding the datatypes used by Go (a modern language with C-style syntax) >>> and >>> that uses: >>> >>> uint8, uint16, uint32, uint64 >>> int8, int16, int32, int64 >> >> Go also has int, uint and uintptr with implementation-defined widths. > > OK, int and uint are described a few lines further down. They are just > integers with default width for that machine (which I suspect will be either > 32 or 64 bits). > > That's even closer to my approach (no width specified it uses a default, > currently 32 bits). > > uintptr will follow from that. I wasn't commenting on your approach (I don't know what that is). I thought you were citing Go as an example of a language that did without implementation-defined integer sizes. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-09-13 15:13 -0700 |
| Message-ID | <lnboh9y3j5.fsf@nuthaus.mib.org> |
| In reply to | #26301 |
"BartC" <bc@freeuk.com> writes:
[...]
> OK, int and uint are described a few lines further down. They are just
> integers with default width for that machine (which I suspect will be either
> 32 or 64 bits).
>
> That's even closer to my approach (no width specified it uses a default,
> currently 32 bits).
>
> uintptr will follow from that.
>
> (That could be said to be similar to what C does with it's int and intxx_t,
> except that I believe that intxx_t types are defined in terms of ints
> (short, long int etc) instead of the other way around.)
The word "int" is not a collective term for the types short, int, and
long. Yes the word does appear in some forms of the names of the types
(short int, long int), but IMHO it's best *not* to think of "short int"
as a phrase in which "short" modifies "int". short int, int, and long
int are all *integer* types.
"int" is a single type (also known as "signed int"). "short" and "long"
are distinct types, whichever of their several names you use.
To address your point, the intN_t and uintN_t types are defined
as typedefs, i.e., as aliases for existing types. In most
implementations, the chosen existing types are predefined types
such as char, short, int, long, or long long, or their signed
or unsigned variants. They can also be defined as typedefs for
implementation-defined "extended" types, but I don't know of any
compiler that does so. Types such as short, int, and long are built
into the language, and syntactically, their names are composed of
keywords. See section 6.2.5 of the C standard for more information
about predefined types.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-13 07:33 -0400 |
| Message-ID | <k2sgau$s07$1@dont-email.me> |
| In reply to | #26293 |
On 09/13/2012 06:36 AM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5050F71F.80902@verizon.net... >> On 09/12/2012 03:36 PM, BartC wrote: > >>> (I use 'int' and 'word' for signed/unsigned integers of natural width; >>> int:N >>> and word:N for specific bitwidths, and int*N and byte*N for specific >>> bytewidths; while 'byte' is a synonym for word:8. For value ranges, I use >> >> I strongly recommend against using non-standard definitions for terms >> defined by the C standard such as 'int' and 'byte' in this newsgroup - >> it can only lead to confusion. > > That was an example of a different approach (in my own language) to dealing > with families of integer types. I strongly recommend conspicuously labeling all uses of such a different approach in a C-oriented forum to prevent any possibility of confusion with C's standard-defined terms that have the same spelling. For instance, instead of 'int', write something like mylanguage::int. ... > So where is size_t and ptr_diff_t amongst that lot? See, it's possible to > manage without it! So C's approach *does* seem untidy. C90's integer types have sizes that vary from one implementation to another, which is why a typedef is needed for a type like C99's int32_t, that has the same size on all platforms (or at least, on all platforms where there is any supported integer type of that size). The example you gave appeared to be of languages where the basic types have a fixed size, which would remove the need for such typedefs. However, by the same token, that creates the need for other typedefs: one for the natural int type for a given platform, regardless of what size that type is - call it natural_int or nint, corresponding to C's built-in 'int' type (in C99, int_fast16_t is a clumsier representation of roughly the same idea). Either way, if you have multiple similar types, you sometimes need to have the type chosen vary with context, and you then need something like C's typedef to record which of those types was chosen. And that's where things like size_t and ptrdiff_t come in. > However, the context in this subthread was whether C was a suitable starting > point for a hypothetical universal language. Since such a language would > need to incorporate, amongst many other extremes, the type handling of Ada, > with that of Python, plus all the manipulations allowed by C, then that's > obviously a non-starter. If you're giving those languages as examples because you consider them to be the best in each of those areas, you're probably aiming too high. An "everything" language will necessarily involve a lot of compromises; you'll be lucky if it handles types as well as the average language; it's not likely to handle them as well as the language (whichever one that is) that handles types best. The same is likely to be true of every other desirable feature of the language. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-14 03:35 -0700 |
| Message-ID | <cbf52647-f8dc-4b77-b480-24d5d1be7995@t30g2000vbu.googlegroups.com> |
| In reply to | #26298 |
On Sep 13, 12:33 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 09/13/2012 06:36 AM, BartC wrote: <snip> > > However, the context in this subthread was whether C was a suitable starting > > point for a hypothetical universal language. Since such a language would > > need to incorporate, amongst many other extremes, the type handling of Ada, > > with that of Python, plus all the manipulations allowed by C, then that's > > obviously a non-starter. > > If you're giving those languages as examples because you consider them > to be the best in each of those areas, you're probably aiming too high. > An "everything" language will necessarily involve a lot of compromises; > you'll be lucky if it handles types as well as the average language; > it's not likely to handle them as well as the language (whichever one > that is) that handles types best. The same is likely to be true of every > other desirable feature of the language. which leaves me wondering what purpose this "everything language" serves
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-14 12:21 +0100 |
| Message-ID | <0.778354c15e3849f02530.20120914122102BST.87txv0g89t.fsf@bsb.me.uk> |
| In reply to | #26338 |
Nick Keighley <nick_keighley_nospam@hotmail.com> writes: > On Sep 13, 12:33 pm, James Kuyper <jameskuy...@verizon.net> wrote: >> On 09/13/2012 06:36 AM, BartC wrote: > > <snip> > >> > However, the context in this subthread was whether C was a suitable starting >> > point for a hypothetical universal language. Since such a language would >> > need to incorporate, amongst many other extremes, the type handling of Ada, >> > with that of Python, plus all the manipulations allowed by C, then that's >> > obviously a non-starter. >> >> If you're giving those languages as examples because you consider them >> to be the best in each of those areas, you're probably aiming too high. >> An "everything" language will necessarily involve a lot of compromises; >> you'll be lucky if it handles types as well as the average language; >> it's not likely to handle them as well as the language (whichever one >> that is) that handles types best. The same is likely to be true of every >> other desirable feature of the language. > > which leaves me wondering what purpose this "everything language" > serves Yes, me too. When I first saw Malcolm's post I thought he was being sarcastic, but it seems not. I can understand the remark if it's born of frustration: why do we have so many similar languages? but not if it born of a desire to fix the situation with one universal language. For example, from a technical point of view, having both Java and C# is daft, but we have both because of the way businesses work. There is also a reason to be frustrated when new languages repeat the mistakes of previous ones. I hope never to see a new programming language that thinks a character is a byte, or one that has no high-level concurrency control, but I am certain I'll be disappointed! So I can imagine having fewer languages, but the language design space is too vast to covered by only a few data points. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Jan G" <gbn2012@world.net> |
|---|---|
| Date | 2012-09-30 03:35 -0600 |
| Message-ID | <k493nv$2nf$2@speranza.aioe.org> |
| In reply to | #26342 |
Ben Bacarisse wrote: > I can understand the remark Not to be obtuse but how about you shut up a bit?
[toc] | [prev] | [next] | [standalone]
| From | "Jan G" <gbn2012@world.net> |
|---|---|
| Date | 2012-09-30 03:31 -0600 |
| Message-ID | <k493di$249$2@speranza.aioe.org> |
| In reply to | #26338 |
Nick Keighley wrote: > which leaves me wondering what purpose this "everything language" > serves Or you won't have you being just a someone putting a part in a car?
[toc] | [prev] | [next] | [standalone]
| From | "Jan G" <gbn2012@world.net> |
|---|---|
| Date | 2012-09-30 03:33 -0600 |
| Message-ID | <k493nu$2nf$1@speranza.aioe.org> |
| In reply to | #26338 |
Nick Keighley wrote: > On Sep 13, 12:33 pm, James Kuyper <jameskuy...@verizon.net> wrote: >> On 09/13/2012 06:36 AM, BartC wrote: > > <snip> > >>> However, the context in this subthread was whether C was a suitable >>> starting point for a hypothetical universal language. Since such a >>> language would need to incorporate, amongst many other extremes, >>> the type handling of Ada, with that of Python, plus all the >>> manipulations allowed by C, then that's obviously a non-starter. >> >> If you're giving those languages as examples because you consider >> them to be the best in each of those areas, you're probably aiming >> too high. An "everything" language will necessarily involve a lot of >> compromises; you'll be lucky if it handles types as well as the >> average language; it's not likely to handle them as well as the >> language (whichever one that is) that handles types best. The same >> is likely to be true of every other desirable feature of the >> language. > > which leaves me wondering what purpose this "everything language" > serves Do you want a union? Do you want a leader?
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web