Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90795 > unrolled thread
| Started by | The Doctor <doctor@doctor.nl2k.ab.ca> |
|---|---|
| First post | 2016-07-22 17:29 +0000 |
| Last post | 2016-07-23 12:35 -0700 |
| Articles | 19 on this page of 219 — 33 participants |
Back to article view | Back to comp.lang.c
GCC vs Clang The Doctor <doctor@doctor.nl2k.ab.ca> - 2016-07-22 17:29 +0000
Re: GCC vs Clang Luuk <luuk@invalid.lan> - 2016-07-22 20:17 +0200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 21:09 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 12:22 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 23:20 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 14:56 -0700
Re: GCC vs Clang jameskuyper@verizon.net - 2016-07-22 15:27 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 00:59 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 20:33 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 12:18 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 12:54 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 13:48 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:54 +0200
Killfiles: Learn how they work. They are your friend! (Was: GCC vs Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-23 21:14 +0000
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:10 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 05:20 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 15:43 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 07:09 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-23 22:08 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:21 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 14:38 +0100
Re: GCC vs Clang Mark Storkamp <mstorkamp@yahoo.com> - 2016-07-25 09:30 -0500
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 15:41 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 16:33 +0200
Re: GCC vs Clang Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 07:46 -0700
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 11:02 -0400
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:00 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:25 -0700
Re: GCC vs Clang Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2016-07-22 20:42 +0000
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 23:09 +0200
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 10:50 -0400
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:53 +0100
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:50 +0000
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 11:07 -0400
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:16 +0100
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-27 07:27 +0000
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 08:29 +0100
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-27 12:29 -0400
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:44 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-22 22:18 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 14:43 -0700
Re: GCC vs Clang Melzzzzz <mel@zzzzz.com> - 2016-07-23 00:02 +0200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-09 17:20 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 10:34 +0200
Re: GCC vs Clang Siri Cruise <chine.bleu@yahoo.com> - 2016-08-10 02:18 -0700
Re: GCC vs Clang cross@spitfire.i.gajendra.net (Dan Cross) - 2016-08-10 15:31 +0000
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:31 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 15:14 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 16:57 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 17:24 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-25 15:29 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 16:00 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-25 16:31 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 17:06 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-26 07:52 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 08:20 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-26 16:23 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 07:17 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 00:56 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:17 +0000
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-27 09:36 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-27 10:04 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-27 20:42 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 20:29 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-27 12:08 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:43 +0000
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 07:32 +1200
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-27 13:23 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 17:13 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 07:10 +0200
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-26 17:19 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 08:28 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 00:53 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 02:04 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 08:41 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 17:37 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 12:07 -0700
Re: GCC vs Clang? jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-25 22:57 +0200
Re: GCC vs Clang? David Brown <david.brown@hesbynett.no> - 2016-07-26 14:08 +0200
Re: GCC vs Clang? raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:18 +0000
Re: GCC vs Clang? jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-27 22:01 +0200
Re: GCC vs Clang? raltbos@xs4all.nl (Richard Bos) - 2016-07-28 09:56 +0000
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-27 12:38 -0400
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 07:38 +1200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 20:54 +0100
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 08:16 +1200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 23:55 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 07:20 +0100
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 19:35 +1200
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:47 +0000
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 19:35 +1200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-09 17:00 -0700
Re: GCC vs Clang eva galois <eva.galois@yandex.ru> - 2016-08-09 21:15 -0400
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 10:42 +0200
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:52 +0000
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-10 06:59 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 16:52 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 11:22 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-10 11:31 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 14:01 +0100
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-10 07:12 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 17:09 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 09:40 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-10 09:55 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 22:51 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 09:36 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 17:52 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 11:49 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 20:28 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 13:06 -0700
Re: GCC vs Clang Tim Prince <tprince@computer.org> - 2016-08-10 18:14 -0400
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-10 21:53 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 10:35 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 11:00 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 09:36 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 18:54 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 12:11 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 20:42 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 19:53 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 12:41 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 20:21 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 13:11 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 21:46 +0200
Re: GCC vs Clang Gareth Owen <gwowen@gmail.com> - 2016-08-11 20:49 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 13:57 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 23:10 +0200
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 09:07 +0100
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 10:50 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 13:47 -0700
Re: GCC vs Clang "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-14 16:29 -0400
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 23:00 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 14:04 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 14:11 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 15:29 -0700
Re: GCC vs Clang "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-14 18:13 -0400
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-15 00:14 -0700
Keith's subtle use of the word "vendor" (Was: GCC vs Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-15 08:04 +0000
Re: Keith's subtle use of the word "vendor" (Was: GCC vs Clang) fir <profesor.fir@gmail.com> - 2016-08-15 01:15 -0700
Re: Keith's subtle use of the word "vendor" (Was: GCC vs Clang) jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-17 16:50 +0200
Re: Keith's subtle use of the word "vendor" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-15 07:27 -0600
Re: Keith's subtle use of the word "vendor" Richard Heathfield <rjh@cpax.org.uk> - 2016-08-15 15:00 +0100
Re: Keith's subtle use of the word "vendor" James Kuyper <jameskuyper@verizon.net> - 2016-08-15 10:29 -0400
Re: Keith's subtle use of the word "vendor" Mark Storkamp <mstorkamp@yahoo.com> - 2016-08-15 10:22 -0500
Re: Keith's subtle use of the word "vendor" jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-15 17:46 +0200
Re: Keith's subtle use of the word "vendor" Richard Heathfield <rjh@cpax.org.uk> - 2016-08-15 17:41 +0100
Re: Keith's subtle use of the word "vendor" jameskuyper@verizon.net - 2016-08-15 09:47 -0700
Re: Keith's subtle use of the word "vendor" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-15 11:11 -0600
Re: Keith's subtle use of the word "vendor" "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-15 13:28 -0400
Re: Keith's subtle use of the word "vendor" fir <profesor.fir@gmail.com> - 2016-08-15 10:05 -0700
Re: GCC vs Clang (was Re: Keith's subtle use of the word "vendor") Keith Thompson <kst-u@mib.org> - 2016-08-15 11:52 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-15 18:00 +0000
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:34 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:48 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:56 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 12:10 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 12:18 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") mark.bluemel@gmail.com - 2016-08-17 08:44 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-15 09:38 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-08-17 08:24 +0000
Re: GCC vs Clang Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 17:44 +0200
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-08-15 17:25 +1200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:09 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:16 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:28 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 10:50 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:30 -0700
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 14:16 +0100
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 07:28 -0700
Re: GCC vs Clang Ike Naar <ike@iceland.freeshell.org> - 2016-08-14 18:05 +0000
Re: GCC vs Clang Melzzzzz <mel@zzzzz.com> - 2016-08-14 20:18 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 11:54 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 12:05 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 21:16 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 12:37 -0700
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 20:59 +0100
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 13:48 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 13:58 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:53 -0700
Re: GCC vs Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-14 11:34 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 14:07 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-14 12:36 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 14:03 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-15 09:48 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-15 11:46 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-15 10:45 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:11 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:06 -0700
Re: GCC vs Clang James Kuyper <jameskuyper@verizon.net> - 2016-08-11 15:16 -0400
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:02 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 22:20 +0100
Re: GCC vs Clang Gareth Owen <gwowen@gmail.com> - 2016-08-12 16:58 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 17:05 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-11 23:24 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 22:58 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 16:08 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 00:21 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 17:29 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 12:23 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 11:43 +0100
Re: GCC vs Clang jameskuyper@verizon.net - 2016-08-13 08:37 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 13:58 -0700
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-11 16:28 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-12 01:12 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-08-12 20:15 +1200
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 12:29 +0200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-12 12:45 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 04:30 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 08:09 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 14:49 +0200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-12 05:00 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 15:03 +0200
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 08:22 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-12 09:14 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 10:23 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-12 11:29 -0700
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-12 05:19 -0700
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 10:53 -0400
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:55 +0000
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 12:35 -0700
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-08-11 13:58 -0700 |
| Message-ID | <u9ppqb5m4fs5596s3vffoeihor08qcl192@4ax.com> |
| In reply to | #92115 |
On Thu, 11 Aug 2016 10:35:19 +0100, BartC <bc@freeuk.com> wrote: >On 11/08/2016 05:53, Geoff wrote: >> On Wed, 10 Aug 2016 20:28:32 +0100, BartC <bc@freeuk.com> wrote: >> > >>> But clang as provided isn't that. Fine, but they haven't bothered to >>> point that out anywhere, leaving it to users to waste time finding these >>> things out for themselves. >>> >>> I think it took me a couple of years to find out, as it was silently >>> piggy-backing itself onto my mingw installation! >>> >>> So clang as provided doesn't have any standard headers. It has no >>> libraries, and apparently it has no linker of its own. Yet clang.exe is >>> a 49MB executable! The whole download is over 400MB. > >> Your arguments are specious. You are deliberately whining. >> >> I went here: http://llvm.org/builds/ from Keith's link. >> >> I downloaded and ran the installer, opened my VS2010 Ultimate, >> selected my little hello.sln project, set the project to use clang, >> just as they describe on the page above, compiled and ran the program. > >That doesn't contradict what I said. > >Try deleting, disabling or hiding your 'VS2010 Ultimate'. Does clang >still compile .c files? > Yes. As a matter of fact, about 2 minutes of the six was spent writing a hello.c file and compiling it from the command line before I opened VS2010 to do it in a project. It produced an "a.exe" file just fine. >Your link says this: "The current installer integrates with MSVC 2010, >2012, 2013 and 14 CTP." > They have a small bit of catching up to do, VS2015 is out. Microsoft has plans to use clang/LLVM as their compiler back-end anyway. >Actually I've never seen that page before as I looked at the Releases >page with the enticingly named "Clang for Windows" links. > You don't do much reading do you. Keith told you exactly where to look. >Nevertheless, I've just downloaded the version on the page above. >Installing that required me to uninstall my old clang (it doesn't allow >multiple versions in different paths). > >When it was finished, I found Clang now no longer worked at all! Not >even piggy-backing on top of gcc/tdm. And there is even some MSVC >version in there somewhere. > >So, instead of a 438MB 64-bit clang installation that worked (even if in >collaboration with gcc/TDM), I now have a 647MB 32-bit clang that >doesn't work at all! I'm really glad I followed your advice.... I installed it and clicked the "Add LLVM to the system path for all users" during the install and it worked just fine. Yes, clang detects and replaces other versions and asks for permission to replace before proceeding. So, you're clearly dealing with the PEBKAC problem.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-11 16:28 -0700 |
| Message-ID | <7ed4b3db-62d1-4613-ab0a-84c7f921334c@googlegroups.com> |
| In reply to | #92162 |
On Thursday, August 11, 2016 at 11:58:53 PM UTC+3, Geoff wrote: > > They have a small bit of catching up to do, VS2015 is out. Microsoft > has plans to use clang/LLVM as their compiler back-end anyway. > I heard that Microsoft has plans to use clang as their compiler front-end*. I didn't hear that Microsoft has similar plans for back-end. Or, may be, you mean Visual Studio IDE back-end? What is front and what is back depends of point of view. -------------- * - More than plans by now, googling suggests that "Clang with Microsoft CodeGen" is a shipping product for several months.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-08-12 01:12 -0700 |
| Message-ID | <bd0rqblo10ujb41utg6i9srb8j4sgfdibg@4ax.com> |
| In reply to | #92176 |
On Thu, 11 Aug 2016 16:28:04 -0700 (PDT), already5chosen@yahoo.com wrote: >Or, may be, you mean Visual Studio IDE back-end? I probably did. At any rate the clang compiler will be used by the VS IDE to do the compiling. I don't know what will happen with Microsoft's compiler. Interesting aside: "where clang" yields the path to the clang executable which is "C:\Program Files (x86)\LLVM\bin\clang.exe" on my system. Looking into "C:\Program Files (x86)\LLVM\bin\" one finds: clang.exe, clang++.exe clang-cl.exe all identical and all 58.27MB in size. What a waste. At least Bart and I can agree on the stupid waste of space the suite can be.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-12 20:15 +1200 |
| Message-ID | <e15esnFeqnkU1@mid.individual.net> |
| In reply to | #92180 |
On 08/12/16 08:12 PM, Geoff wrote: > On Thu, 11 Aug 2016 16:28:04 -0700 (PDT), already5chosen@yahoo.com > wrote: > >> Or, may be, you mean Visual Studio IDE back-end? > > I probably did. At any rate the clang compiler will be used by the VS > IDE to do the compiling. I don't know what will happen with > Microsoft's compiler. They have an option to use clang as the front end with their code generator. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-12 12:29 +0200 |
| Message-ID | <nok8f1$quv$1@dont-email.me> |
| In reply to | #92180 |
On 12/08/16 10:12, Geoff wrote: > On Thu, 11 Aug 2016 16:28:04 -0700 (PDT), already5chosen@yahoo.com > wrote: > >> Or, may be, you mean Visual Studio IDE back-end? > > I probably did. At any rate the clang compiler will be used by the VS > IDE to do the compiling. I don't know what will happen with > Microsoft's compiler. > > Interesting aside: > "where clang" yields the path to the clang executable which is > "C:\Program Files (x86)\LLVM\bin\clang.exe" on my system. > > Looking into "C:\Program Files (x86)\LLVM\bin\" one finds: > clang.exe, clang++.exe clang-cl.exe all identical and all 58.27MB in > size. What a waste. > Windows does not have symbolic links or hard links (at least, not proper ones). On a *nix system, this would be one file and two links - the direct translation of the same structure into Windows gives three copies of the file. The Windows alternative would be to make them three separate small programs, each of which then called the single copy of the main program. That changes a waste of disk space into a waste of developers' time and effort. Since Windows is a very minor platform for clang, and disk space is rarely at a premium, they choose the simple method. > At least Bart and I can agree on the stupid waste of space the suite > can be. > Yes. But that's not new in the Windows world - it's just the way Windows works.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-12 12:45 +0200 |
| Message-ID | <nok9ce$tn2$1@dont-email.me> |
| In reply to | #92184 |
Le 12/08/2016 à 12:29, David Brown a écrit : > Windows does not have symbolic links or hard links (at least, not proper > ones). Windows has symbolic links since at least 10 years, since NTFS supports suymbolic links since windows VISTA. See: https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa365680(v=vs.85).aspx See also the API CreateSymbolicLink https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa363866(v=vs.85).aspx Of course it has no "proper" ones since "proper" can only happen in *nix. OBVIOUSLY! :-)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-12 04:30 -0700 |
| Message-ID | <5530810c-9471-4e84-b6b6-0353e73dc346@googlegroups.com> |
| In reply to | #92186 |
On Friday, August 12, 2016 at 11:45:41 AM UTC+1, jacobnavia wrote: > Le 12/08/2016 à 12:29, David Brown a écrit : > > Windows does not have symbolic links or hard links (at least, not proper > > ones). > > Windows has symbolic links since at least 10 years, since NTFS supports > suymbolic links since windows VISTA. > > Of course it has no "proper" ones since "proper" can only happen in *nix. > OBVIOUSLY! > Horrid things that introduce cycles into search graphs and make you lose track of what is private and what is a copy. Trees are what you need. As I said before, trees are where it's at. Trees.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-12 08:09 -0700 |
| Message-ID | <f46f58f3-75fb-440a-a032-50097d165154@googlegroups.com> |
| In reply to | #92187 |
On Friday, August 12, 2016 at 6:30:53 AM UTC-5, Malcolm McLean wrote:
> Horrid things that introduce cycles into search graphs and make you lose track
> of what is private and what is a copy.
> Trees are what you need. As I said before, trees are where it's at. Trees.
Symbolic links can be useful if programs are prepared to deal with them;
difficulties arise if programs that know nothing about links expect that
recursively enumerating a directory will give a list of everything that
can be accessed via that directory.
What would probably be just as helpful in many cases for C, though, would
be a defined ability to concatenate strings to form #include paths. It
would seem much cleaner to say:
#include "apipaths.h" // Local file specifying paths to everything
#include WOOZLEAPI_PATH "config.h"
#include WOOZLEAPI_PATH "lights.h"
#include WOOZLEAPI_PATH "buttons.h"
#include FNORDAPI_PATH "config.h"
#include FNORDAPI_PATH "serial.h"
#include FNORDAPI_PATH "i2c.h"
than to either hard-coding paths within #include statements or having a
compiler search a list of include paths and grab the first thing it sees
with any given name. If file and path names contain only characters that
will fit within non-literal tokens it may be possible to do the path
concatenation with the preprocessor, but that seems rather clunky compared
do being able to simply have each API specify a macro name for its path.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-12 14:49 +0200 |
| Message-ID | <nokgkq$lfi$1@dont-email.me> |
| In reply to | #92186 |
On 12/08/16 12:45, jacobnavia wrote: > Le 12/08/2016 à 12:29, David Brown a écrit : >> Windows does not have symbolic links or hard links (at least, not proper >> ones). > > Windows has symbolic links since at least 10 years, since NTFS supports > suymbolic links since windows VISTA. > > See: > https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa365680(v=vs.85).aspx > > See also the API CreateSymbolicLink > https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa363866(v=vs.85).aspx > > > Of course it has no "proper" ones since "proper" can only happen in *nix. > OBVIOUSLY! > > :-) > My knowledge was a bit out of date (since using Linux as my main platform at work and at home, I haven't kept up with "power" usage of Windows as much as I used to. But apart from the slightly bizarre restriction that you must be Administrator (not merely a user with administrator rights) in order to create links, it looks like both soft and hard links work on NTFS like on *nix systems. Interestingly, this also means that we can't be sure that the three "copies" of the clang binary really are copies - if they are hardlinked together, they would appear the same, but the 55 MB would be shared. A difference, however, is that on *nix systems hard and soft links are used regularly, and programs (and distros) are aware of them and make use of them. You can easily make soft links with any *nix file manager - on Windows, you can make "shortcuts" which are not the same thing at all. But thanks for correcting me here.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-12 05:00 -0700 |
| Message-ID | <a2c288b5-6b9a-410d-acef-637f6ea2ec6d@googlegroups.com> |
| In reply to | #92184 |
On Friday, August 12, 2016 at 1:30:00 PM UTC+3, David Brown wrote: > On 12/08/16 10:12, Geoff wrote: > > On Thu, 11 Aug 2016 16:28:04 -0700 (PDT), already5chosen@yahoo.com > > wrote: > > > >> Or, may be, you mean Visual Studio IDE back-end? > > > > I probably did. At any rate the clang compiler will be used by the VS > > IDE to do the compiling. I don't know what will happen with > > Microsoft's compiler. > > > > Interesting aside: > > "where clang" yields the path to the clang executable which is > > "C:\Program Files (x86)\LLVM\bin\clang.exe" on my system. > > > > Looking into "C:\Program Files (x86)\LLVM\bin\" one finds: > > clang.exe, clang++.exe clang-cl.exe all identical and all 58.27MB in > > size. What a waste. > > > > Windows does not have symbolic links or hard links (at least, not proper > ones). I wonder what's difference between symbolic links and "proper symbolic links". https://en.wikipedia.org/wiki/NTFS_symbolic_link > On a *nix system, this would be one file and two links - the > direct translation of the same structure into Windows gives three copies > of the file. The Windows alternative would be to make them three > separate small programs, each of which then called the single copy of > the main program. More commonly - three separate small programs that load and run the same DLL. But I still don't see what's wrong with "improper symbolic links". > That changes a waste of disk space into a waste of > developers' time and effort. Since Windows is a very minor platform for > clang, and disk space is rarely at a premium, they choose the simple method. > Disk space is at premium for people that refuse to use rotating media for anything, but archives. And this set of people probably includes majority of software developers. > > > > At least Bart and I can agree on the stupid waste of space the suite > > can be. > > > > Yes. But that's not new in the Windows world - it's just the way > Windows works. No, it's not how Windows works. It's how Windows is sometimes mistreated by developers that have main focus on other platforms.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-12 15:03 +0200 |
| Message-ID | <nokheo$oaa$1@dont-email.me> |
| In reply to | #92188 |
On 12/08/16 14:00, already5chosen@yahoo.com wrote: > On Friday, August 12, 2016 at 1:30:00 PM UTC+3, David Brown wrote: >> On 12/08/16 10:12, Geoff wrote: <snip> >>> At least Bart and I can agree on the stupid waste of space the >>> suite can be. >>> >> >> Yes. But that's not new in the Windows world - it's just the way >> Windows works. > > No, it's not how Windows works. It's how Windows is sometimes > mistreated by developers that have main focus on other platforms. > Yes, it is the way the Windows ecosystem works. It is not the way it /has/ to work (I've now learned that the OS itself supports links properly), but it is the way it /does/ work. Look in the directories for any reasonably large program on Windows - it will contain dozens of DLLs, many of which are exactly the same as other copies of the same DLL in other program directories. The Windows Way is to provide multiple copies of the same files, libraries, or systems, rather than to have a common source and shared versions. (To be fair, it is better than the old Windows Way, which was that each program installation copied its DLLs into the Windows system directories with a total disregard for what might have been there before, including incompatible versions with the same filename.) I think it is reasonable to argue that the reason Windows software is like this is mainly historical, and developments such as links and even long file names should make it entirely feasible to have a more efficient system such as commonly found on *nix. But it takes time to change that sort of thing, especially when MS themselves are one of the worst sinners in this regard. It is (almost) only developers who have their main focus on other platforms that would even consider using links or shared libraries. Of course, some Windows users are going to be upset if they see installation instructions such as "first make sure you have the GTK libraries installed before installing this program".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-12 08:22 -0700 |
| Message-ID | <2c83dfac-49cf-4c4b-9782-fe4e3c0be7ff@googlegroups.com> |
| In reply to | #92191 |
On Friday, August 12, 2016 at 8:03:31 AM UTC-5, David Brown wrote: > I think it is reasonable to argue that the reason Windows software is > like this is mainly historical, and developments such as links and even > long file names should make it entirely feasible to have a more > efficient system such as commonly found on *nix. The Unix way may be more space-efficient, but the Windows way makes it possible to support some programs that expect that "int" will be 32 bits, some that expect it to be 64 bits, and even some that expect it to be 16 bits, since each executable will include its own set of libraries.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-12 09:14 -0700 |
| Message-ID | <lntweqoth2.fsf@kst-u.example.com> |
| In reply to | #92197 |
supercat@casperkitty.com writes:
> On Friday, August 12, 2016 at 8:03:31 AM UTC-5, David Brown wrote:
>> I think it is reasonable to argue that the reason Windows software is
>> like this is mainly historical, and developments such as links and even
>> long file names should make it entirely feasible to have a more
>> efficient system such as commonly found on *nix.
>
> The Unix way may be more space-efficient, but the Windows way makes it
> possible to support some programs that expect that "int" will be 32 bits,
> some that expect it to be 64 bits, and even some that expect it to be
> 16 bits, since each executable will include its own set of libraries.
That's possible on Linux too (well, at least for 32 and 64 bits).
On my system, gcc has "-m32", "-mx32", and "-m64" options. 16-bit int
is not supported as far as I know.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-12 10:23 -0700 |
| Message-ID | <395b1cf7-3bd2-4464-937c-708b410710dd@googlegroups.com> |
| In reply to | #92198 |
On Friday, August 12, 2016 at 10:33:24 AM UTC-5, Keith Thompson wrote: > That's possible on Linux too (well, at least for 32 and 64 bits). > On my system, gcc has "-m32", "-mx32", and "-m64" options. 16-bit int > is not supported as far as I know. Does it use macros to rename standard-library functions like "sscanf" to indicate whether they expect "%d" to overwrite 4 or 8 bytes, does it bundle standard-library functions into executables, or does it have some other way of handling such issues?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-12 11:29 -0700 |
| Message-ID | <lnpopdq1rh.fsf@kst-u.example.com> |
| In reply to | #92202 |
supercat@casperkitty.com writes:
> On Friday, August 12, 2016 at 10:33:24 AM UTC-5, Keith Thompson wrote:
>> That's possible on Linux too (well, at least for 32 and 64 bits).
>> On my system, gcc has "-m32", "-mx32", and "-m64" options. 16-bit int
>> is not supported as far as I know.
>
> Does it use macros to rename standard-library functions like "sscanf"
> to indicate whether they expect "%d" to overwrite 4 or 8 bytes, does
> it bundle standard-library functions into executables, or does it have
> some other way of handling such issues?
It uses separate shared libraries.
$ ldd hello-m*
hello-m32:
linux-gate.so.1 => (0xf779e000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75be000)
/lib/ld-linux.so.2 (0xf77a1000)
hello-m64:
linux-vdso.so.1 => (0x00007ffea198d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0b2c8ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0b2cca2000)
hello-mx32:
linux-vdso.so.1 => (0xfff9a000)
libc.so.6 => /libx32/libc.so.6 (0xf7406000)
/libx32/ld-linux-x32.so.2 (0xf77d0000)
$
Most of the header files are the same (I think the compiler predefines
some macros that some of the gcc-specific headers test).
--
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 | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-12 05:19 -0700 |
| Message-ID | <c1717519-4edb-41f0-8f5c-34a5674d713d@googlegroups.com> |
| In reply to | #92180 |
On Friday, August 12, 2016 at 11:12:59 AM UTC+3, Geoff wrote: > On Thu, 11 Aug 2016 16:28:04 -0700 (PDT), already5chosen@yahoo.com > wrote: > > >Or, may be, you mean Visual Studio IDE back-end? > > I probably did. At any rate the clang compiler will be used by the VS > IDE to do the compiling. I don't know what will happen with > Microsoft's compiler. > First, let me use a present tens rather than future tens. According to my understanding (didn't have VS 2015 myself) the current situation is like that: clang/llvm is used by VS 2015 IDE as default (or only?) compiler (both a front end and a back end) for non-Windows targets. clang front end with Microsoft's own back end (i.e. Code generator) can be used as a compiler for Windows desktop target. By now it's not a default. As to future plans, according to my understanding, clang front/Microsoft back end is going to become a Visual Studio default for Windows desktop application pretty soon, esp. for C language (as opposed to C++). But Microsoft indicated no plans to abandon their own code generator (C2) in favor of llvm. That's my understanding. Then again, I don't follow Visual Studio development too closely. Also I don't try to read between the lines.
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2016-07-25 10:53 -0400 |
| Message-ID | <nn594h$cnr$2@dont-email.me> |
| In reply to | #90819 |
On 7/22/2016 5:18 PM, BartC wrote: > On 22/07/2016 18:29, The Doctor wrote: >> Which is the better compiler? > > My experience of using Clang is that it is not complete: it assumes a gcc > installation (so that it can make use of gcc's header files and possibly > libraries too). > > So if you could only install one, gcc would make more sense... Strange... My FreeBSD system has "clang", but no "gcc". -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-23 09:55 +0000 |
| Message-ID | <57933dbd.5655125@news.xs4all.nl> |
| In reply to | #90795 |
The Doctor <doctor@doctor.nl2k.ab.ca> wrote: > Which is the better compiler? Not touching that with a bargepole. > Also are there any toher C / C++ compilers? You don't specify which platform you use, so you probably mean MS Windows, in which case: Pelle's C: <http://www.smorgasbordet.com/pellesc/> Complete development environment, _actual_ freeware. Others exist for other platforms (I just found out about ACK, but haven't used it). Generally speaking, many platforms have a port of LCC and TCC. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-23 12:35 -0700 |
| Message-ID | <ln8twsgnbj.fsf@kst-u.example.com> |
| In reply to | #90795 |
The Doctor <doctor@doctor.nl2k.ab.ca> writes:
> Which is the better compiler?
>
> Also are there any [other] C / C++ compilers?
[typo corrected in quoted text]
There are a lot of them.
https://en.wikipedia.org/wiki/List_of_compilers#C_compilers
https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_compilers
(I note that the list of C compilers does not include lcc-win.
Presumably it should. Be prepared for jacob to be greatly offended
because I mentioned this.)
Please keep in mind that C and C++ are two different languages;
there is no "C/C++ language". (C++ is almost but not quite a
superset of C.)
--
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] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c
csiph-web