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 | 20 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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 09:36 -0700 |
| Message-ID | <lnshuv9gy4.fsf@kst-u.example.com> |
| In reply to | #91142 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> > Le 26/07/2016 à 01:31, supercat@casperkitty.com a écrit :
>> >> Separating the library from the compiler makes it unclear what a compiler
>> >> is or is not allowed to assume about the way the library is used.
>> >
>> > To give a popular example: The gcc compiler under the "mingw" version
>> > (windows) recognizes long double and generates code for 80 bits longs
>> > double. But mingw uses the Microsoft C library, and that printf doesn't
>> > recognize long doubles, since Microsoft doesn't support them. We have
>> > answered MANY times questions here from people that ask why their printf
>> > "wasn't working".
>> >
>> > Separating the library from the compiler is just NONSENSE!
>>
>> Separating the library from the compiler is what made MinGW possible in
>> the first place.
>
> Well, that explains why there were no ports of GCC to Microsoft
> platforms before MinGW. Good thing DJ Delorie never gave up his day job
> as a shrimp fisherman, then.
>
> Sorry, Keith, but in this case, supercat and jacob are mostly(!) right
> and you are mostly(!) wrong.
Ok, I concede the point.
But I believe it made MinGW much easier to implement.
As I understand it, the MinGW developers were able to take an
existing compiler and an existing runtime library and combine them
into a C implementation with far less effort than would have been
required if they had had to write their own runtime library.
Disclaimer: I am not very familiar with MinGW, and I welcome any
corrections on the above.
It is unfortunate that the compiler and the runtime library did not
agree on the representation of long double. There is a workaround:
defining the macro "__USE_MINGW_ANSI_STDIO" as 1 before including
<stdio.h> causes it to use a different implementation of stdio.
(I don't know whether this applies to the long double functions
declared in <math.h> and <stdlib.h>.)
> There _are_ reasons for separating the
> compiler from the library, and a few of them are good, but the main one
> does appear to be the ability to pass the buck around when the two don't
> work together.
I don't believe that's the actual reason. It might be an unintended
effect in some cases.
> The reasons for keeping the development of the implementation in one
> hand are more important to me. I prefer a complete implementation, not a
> bunch of parts sourced from incestuous-but-legally-separate parties. I
> don't buy my car as a DIY kit, either. I'll assemble my own furniture,
> because that only has to stay up, but as soon as something has to do
> work, like a car or a C implementation, I want it built by the vendor,
> not by me.
Your preference is certainly a valid one. However, I'm content to let
someone else do the work of integrating a compiler and a runtime
library, perhaps developed separately, into a working implementation.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 10:04 -0700 |
| Message-ID | <lnh9bb9flx.fsf@kst-u.example.com> |
| In reply to | #91156 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> It is unfortunate that the compiler and the runtime library did not
> agree on the representation of long double. There is a workaround:
> defining the macro "__USE_MINGW_ANSI_STDIO" as 1 before including
> <stdio.h> causes it to use a different implementation of stdio.
> (I don't know whether this applies to the long double functions
> declared in <math.h> and <stdlib.h>.)
[...]
It occurs to me that configuring gcc to use the Windows native
representation for long double would have been a better solution.
gcc even has command line options that controls the size of
long double.
Perhaps the MinGW developers had (or thought they had) good reasons not
to do that.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-27 20:42 +0200 |
| Message-ID | <nnavap$nr5$1@dont-email.me> |
| In reply to | #91162 |
On 27/07/16 19:04, Keith Thompson wrote: > Keith Thompson <kst-u@mib.org> writes: > [...] >> It is unfortunate that the compiler and the runtime library did not >> agree on the representation of long double. There is a workaround: >> defining the macro "__USE_MINGW_ANSI_STDIO" as 1 before including >> <stdio.h> causes it to use a different implementation of stdio. >> (I don't know whether this applies to the long double functions >> declared in <math.h> and <stdlib.h>.) > [...] > > It occurs to me that configuring gcc to use the Windows native > representation for long double would have been a better solution. > gcc even has command line options that controls the size of > long double. > > Perhaps the MinGW developers had (or thought they had) good reasons not > to do that. > It is possible that they wanted to make the compiler compatible with other libraries (though I fully agree that the native format for the target platform would be the best default choice). In general, the separation of the compiler and the library makes it much easier to mix and match compiler and library. This is perhaps not a common thing, though I have done so myself on a few occasions. There is also the point that the folks writing a C library need to know a good deal about the target platform and OS (for hosted implementations). The folks writing the compiler don't need to know anything about system calls, OS character encodings, etc. Also, a C library for an OS can also be used as the base for a Fortran library, a Pascal library, etc. - keeping it a separate project has advantages for such code sharing. I also agree with Richard that having a single combined implementation from a single source can be more convenient and less error-prone than having them entirely separate. But it is usually sufficient that the different development groups cooperate, and that someone does the high-level package management to make life easier for the users. (The same applies to things like the assembler and linker as well as the library.)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-27 20:29 +0100 |
| Message-ID | <nnb22d$2j1$1@dont-email.me> |
| In reply to | #91169 |
On 27/07/2016 19:42, David Brown wrote: > The folks writing the compiler don't need to know > anything about system calls, OS character encodings, etc. If the compiler generates native code then I think they do need to know all this. Otherwise there will be little left of the 'compiler' other than a parser. (Which will still need to know the encoding of source code files.) > Also, a C > library for an OS can also be used as the base for a Fortran library, a > Pascal library, etc. - keeping it a separate project has advantages for > such code sharing. So? Just make it a shareable library then. And that doesn't explain why there can't be a stdio.h file. A compiler that can compile hardly any C programs is not much of one! I would expect a C compiler to at least be able to compile Hello World from K&R into an object file. Even if the library needed to complete the executable is separate. But Clang on Windows, in the absence of gcc-supplied include files, can't do that. Nor can gcc apparently if you haven't downloaded the full 'bundle'. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 12:08 -0700 |
| Message-ID | <3b435692-c743-4bd5-b5cd-c2a573fa6bea@googlegroups.com> |
| In reply to | #91156 |
On Wednesday, July 27, 2016 at 11:36:11 AM UTC-5, Keith Thompson wrote: > It is unfortunate that the compiler and the runtime library did not > agree on the representation of long double. There is a workaround: > defining the macro "__USE_MINGW_ANSI_STDIO" as 1 before including > <stdio.h> causes it to use a different implementation of stdio. > (I don't know whether this applies to the long double functions > declared in <math.h> and <stdlib.h>.) The fundamental problem with "long double" IMHO is that the Standard failed to define a means via which a variadic function prototype can specify a type to which all floating-point values [and optionally all integer values] should be converted. If variadic functions had to specify the type to which they wanted floating-point values converted (with "double" as the default), the effects of using "printf" on various expressions would be much more consistent and predictable. BTW, I wish there had also been a "long float" whose precision could be anywhere between "float" and "long double", and the semantics were defined such that operations on "float" promote to "long float", and operations on "double" promote to "long double". On machines where operations on longer computation-friendly types are more efficient than operations on shorter "packed" types [which is true not only on x86, but also on many platforms without floating-point hardware] having such intermediate types could greatly improve performance and semantics.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-31 14:43 +0000 |
| Message-ID | <579e0c94.8440859@news.xs4all.nl> |
| In reply to | #91156 |
Keith Thompson <kst-u@mib.org> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > Keith Thompson <kst-u@mib.org> wrote: > >> jacobnavia <jacob@jacob.remcomp.fr> writes: > >> > Separating the library from the compiler is just NONSENSE! > >> > >> Separating the library from the compiler is what made MinGW possible in > >> the first place. > > > > Well, that explains why there were no ports of GCC to Microsoft > > platforms before MinGW. Good thing DJ Delorie never gave up his day job > > as a shrimp fisherman, then. > > > > Sorry, Keith, but in this case, supercat and jacob are mostly(!) right > > and you are mostly(!) wrong. > > Ok, I concede the point. > > But I believe it made MinGW much easier to implement. Somewhat, maybe. Much? I doubt it. > As I understand it, the MinGW developers were able to take an > existing compiler and an existing runtime library and combine them > into a C implementation with far less effort than would have been > required if they had had to write their own runtime library. But if they hadn't had the existing runtime library, they wouldn't have written their own; they'd have ported an existing one, just as they did with the compiler. This would certainly have been more work; but other people did that work as well. I mean, there's also *shudder* CygWin... > It is unfortunate that the compiler and the runtime library did not > agree on the representation of long double. This is true, and as you later point out they could've avoided that by not shoving two separate parts together without sufficient adaptation. That's part of the problem with having an implementation in two parts, in fact it's the main problem: the parts don't always fit perfectly. I, meanwhile, will concede that this is a minor point which I have never run into in practice myself, and that I'm quite happy to use MinGW as it is now; but I do believe that it would've been even better had there been one single responsible party. > > The reasons for keeping the development of the implementation in one > > hand are more important to me. I prefer a complete implementation, not a > > bunch of parts sourced from incestuous-but-legally-separate parties. I > > don't buy my car as a DIY kit, either. I'll assemble my own furniture, > > because that only has to stay up, but as soon as something has to do > > work, like a car or a C implementation, I want it built by the vendor, > > not by me. > > Your preference is certainly a valid one. However, I'm content to let > someone else do the work of integrating a compiler and a runtime > library, perhaps developed separately, into a working implementation. Well, as noted, in practice so am I, if only because I have to; but I still prefer the other approach. IOW: my personal projects tend to get written in Pelles C because I find it more congenial, work projects in Code::Blocks with MinGW because I have to link with external libraries. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-28 07:32 +1200 |
| Message-ID | <dvsgidFakf4U2@mid.individual.net> |
| In reply to | #91142 |
On 07/28/16 03:17 AM, Richard Bos wrote: > > Sorry, Keith, but in this case, supercat and jacob are mostly(!) right > and you are mostly(!) wrong. There _are_ reasons for separating the > compiler from the library, and a few of them are good, but the main one > does appear to be the ability to pass the buck around when the two don't > work together. The main one is to be able to use any compiler with the system supplied libraries. > The reasons for keeping the development of the implementation in one > hand are more important to me. I prefer a complete implementation, not a > bunch of parts sourced from incestuous-but-legally-separate parties. I > don't buy my car as a DIY kit, either. I'll assemble my own furniture, > because that only has to stay up, but as soon as something has to do > work, like a car or a C implementation, I want it built by the vendor, > not by me. So you don't use any Unix Systems or anything other than gcc on Linux? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 13:23 -0700 |
| Message-ID | <3fbddb77-f0db-4e78-a2eb-d45b425bd631@googlegroups.com> |
| In reply to | #91173 |
On Wednesday, July 27, 2016 at 2:32:37 PM UTC-5, Ian Collins wrote: > The main one is to be able to use any compiler with the system supplied > libraries. A header supplied with a particular compiler-independent library should use fixed-sized integer types appropriate to that library; it should not rely upon the compiler's choices for things like the size of "long". Since standard libraries are defined in terms of compiler-specific types, I don't see how one can get around them being compiler specific unless won't ever want to use the same OS to run some programs which assume "long" is 32 bits and others that assume it's 64 bits. Maybe some people like the idea that platforms should confine programmers in that way, but I see no good reason for it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-28 17:13 +1200 |
| Message-ID | <dvtijuFakf4U5@mid.individual.net> |
| In reply to | #91177 |
On 07/28/16 08:23 AM, supercat@casperkitty.com wrote: > On Wednesday, July 27, 2016 at 2:32:37 PM UTC-5, Ian Collins wrote: >> The main one is to be able to use any compiler with the system supplied >> libraries. > > A header supplied with a particular compiler-independent library should > use fixed-sized integer types appropriate to that library; it should not > rely upon the compiler's choices for things like the size of "long". Since > standard libraries are defined in terms of compiler-specific types, I don't > see how one can get around them being compiler specific unless won't ever > want to use the same OS to run some programs which assume "long" is 32 bits > and others that assume it's 64 bits. Maybe some people like the idea that > platforms should confine programmers in that way, but I see no good reason > for it. The platform ABI determines the sizes of standard types. Anything else would be pointless. No matter what compiler you use, if you want to use any of the system's libraries, you (and your compiler's libraries if it provides them) have to use the system ABI. This does not "confine programmers", it prevents chaos. My main development platform (Solaris) has always provided it's own libC. As a programmer, I know I will get consistent behaviour from my code no matter which compiler I use to build it. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-26 07:10 +0200 |
| Message-ID | <nn6rd0$bd5$1@dont-email.me> |
| In reply to | #91068 |
Le 26/07/2016 à 01:00, Keith Thompson a écrit : > > What other non-Unix microcomputer operating systems are there? > I know there are a few non-Unix non-Windows operating systems, > but none of them are particularly common. > For kiki, Apple just doesn't exist. He is so well informed...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-26 17:19 +1200 |
| Message-ID | <dvoa75Ffb5cU5@mid.individual.net> |
| In reply to | #91075 |
On 07/26/16 05:10 PM, jacobnavia wrote: > Le 26/07/2016 à 01:00, Keith Thompson a écrit : > >> >> What other non-Unix microcomputer operating systems are there? >> I know there are a few non-Unix non-Windows operating systems, >> but none of them are particularly common. >> > > For kiki, Apple just doesn't exist. He is so well informed... OS X is BSD based... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-26 08:28 +0200 |
| Message-ID | <nn6vtg$m0r$1@dont-email.me> |
| In reply to | #91077 |
Le 26/07/2016 à 07:19, Ian Collins a écrit : > On 07/26/16 05:10 PM, jacobnavia wrote: >> Le 26/07/2016 à 01:00, Keith Thompson a écrit : >> >>> >>> What other non-Unix microcomputer operating systems are there? >>> I know there are a few non-Unix non-Windows operating systems, >>> but none of them are particularly common. >>> >> >> For kiki, Apple just doesn't exist. He is so well informed... > > OS X is BSD based... > Yes, you are right. I shouldn't answer things out of emotional reasons, you end up saying nonsense
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-26 00:53 -0700 |
| Message-ID | <lntwfcbzta.fsf@kst-u.example.com> |
| In reply to | #91078 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 26/07/2016 à 07:19, Ian Collins a écrit :
/>> On 07/26/16 05:10 PM, jacobnavia wrote:
>>> Le 26/07/2016 à 01:00, Keith Thompson a écrit :
>>
>>>>
>>>> What other non-Unix microcomputer operating systems are there?
>>>> I know there are a few non-Unix non-Windows operating systems,
>>>> but none of them are particularly common.
>>>>
>>>
>>> For kiki, Apple just doesn't exist. He is so well informed...
>>
>> OS X is BSD based...
>>
> Yes, you are right. I shouldn't answer things out of emotional reasons,
> you end up saying nonsense
You shouldn't give me straight lines like that.
(You might also consider dropping the "kiki" crap, unless you enjoy
looking childish.)
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-26 02:04 -0700 |
| Message-ID | <cdb18ad1-27a3-4bdd-86a4-64a5a9311087@googlegroups.com> |
| In reply to | #91079 |
On Tuesday, July 26, 2016 at 8:53:33 AM UTC+1, Keith Thompson wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > > (You might also consider dropping the "kiki" crap, unless you enjoy > looking childish.) > "Kiki" is a diminutive of the girl's name "Christine", which is of course ultimately from "Christ". It's not used for Keith. So I'm not sure why Kenny picked it. However Kiki is a parrot in Enid Blyton's "Adventure series". Bill Cunningham is also a character in the same series. And notice how Kenny never replies to or participates in any Bill threads? I wonder if they are two and the same.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-25 08:41 -0700 |
| Message-ID | <lnoa5ld8sg.fsf@kst-u.example.com> |
| In reply to | #90993 |
BartC <bc@freeuk.com> writes:
> On 25/07/2016 12:31, David Brown wrote:
>> On 22/07/16 23:18, 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...
>>
>> If you are using an OS that does not include basic OS headers and
>> libraries, then you will need to install those along with your compiler.
>
> Huh? How is a beginner supposed to know anything about that? They will
> expect a C compiler to come with everything needed to compile C programs
> into something that can be run.
They will if they listen to you. That's why the rest of us have to
point out that you are mistaken.
Ignorance is not a virtue, nor is it uncurable.
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 17:37 +0100 |
| Message-ID | <nn5f7t$3qs$1@dont-email.me> |
| In reply to | #91008 |
On 25/07/2016 16:41, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Huh? How is a beginner supposed to know anything about that? They will >> expect a C compiler to come with everything needed to compile C programs >> into something that can be run. > > They will if they listen to you. That's why the rest of us have to > point out that you are mistaken. > > Ignorance is not a virtue, nor is it uncurable. I don't get you. Obviously it is desirable for languages to be simple, self-contained and to Just Work, yes? So why be so accepting of systems that expect you to jump through so many hoops? Do you really want to put would-be C programmers off for life before they've even started? (Plenty of time for that when they start to learn the language!) So I would not recommend the use of gcc or clang for Windows; there are too many potential gotchas. Maybe for Linux IF it's pre-installed. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-25 12:07 -0700 |
| Message-ID | <lnbn1lcz9u.fsf@kst-u.example.com> |
| In reply to | #91027 |
BartC <bc@freeuk.com> writes:
> On 25/07/2016 16:41, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> Huh? How is a beginner supposed to know anything about that? They will
>>> expect a C compiler to come with everything needed to compile C programs
>>> into something that can be run.
>>
>> They will if they listen to you. That's why the rest of us have to
>> point out that you are mistaken.
>>
>> Ignorance is not a virtue, nor is it uncurable.
>
> I don't get you. Obviously it is desirable for languages to be simple,
> self-contained and to Just Work, yes?
Yes, those are some of the many criteria for a language, or in this
case an implementation, to be useful. (Your complaints about your
difficulties installing gcc and/or clang on Windows have little or
nothing to do with the language.)
> So why be so accepting of systems that expect you to jump through so
> many hoops? Do you really want to put would-be C programmers off for
> life before they've even started? (Plenty of time for that when they
> start to learn the language!)
You make foolish assumptions about my motivations. The fact that I
disagree with you doesn't mean that I maliciously want to confuse
people.
> So I would not recommend the use of gcc or clang for Windows; there
> are too many potential gotchas. Maybe for Linux IF it's pre-installed.
I don't know how clang is packaged for Windows. I don't currently
use Windows, so I've had no reason to find out. But your complaint
seems to be about that packaging. Fine, as far as I know your
complaints are valid.
Here's what I find odd. You express dismay and astonishment that
a beginner might have to know certain things to use a certain
implementation -- and then you do *nothing* to explain any of it.
You seem to advocate (please correct me if I'm mistaken) that they
should throw up their hands and give up because it's too difficult.
The distinction between a *compiler* and an *implementation* is
very relevant here, and you seem to be deliberately ignoring it,
and you complain when someone else points it out. "This is too
complicated!" "Yes, it is. Here's an explanation." "Why are you
defending it?" (That's probably not entirely fair, but it is the
impression I get from what you've been saying.)
Sure, the installation is probably more complicated than it should
be. (My guess is that the clang maintainers don't care much about
Windows support, but that's only a guess.) You could try to help
people with that.
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-25 22:57 +0200 |
| Subject | Re: GCC vs Clang? |
| Message-ID | <nn5ufn$uc8$1@dont-email.me> |
| In reply to | #91027 |
Le 25/07/2016 à 18:37, BartC a écrit : > I don't get you. Obviously it is desirable for languages to be simple, > self-contained and to Just Work, yes? YES! lcc-win comes with everything you need: compiler, linker, IDE make utility and debugger in a single auto-installing package. LING! (Lcc-win Is Not Gcc)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-26 14:08 +0200 |
| Subject | Re: GCC vs Clang? |
| Message-ID | <nn7jrj$m18$1@dont-email.me> |
| In reply to | #91057 |
On 25/07/16 22:57, jacobnavia wrote: > Le 25/07/2016 à 18:37, BartC a écrit : >> I don't get you. Obviously it is desirable for languages to be simple, >> self-contained and to Just Work, yes? > > YES! > > lcc-win comes with everything you need: compiler, linker, IDE make > utility and debugger in a single auto-installing package. > > LING! > > (Lcc-win Is Not Gcc) gcc is a compiler (or to be more accurate, a compiler collection) supporting a wide range of target devices, a large range of host compilers, and a number of different programming languages. The gcc team don't make installers, binary packages, pre-compiled tools, assemblers, linkers, libraries, debuggers, editors, etc. They expect these things to be provided separately. And this is a good thing for gcc - it means the same compiler can be used of a huge range of systems for a huge range of targets. I use gcc for a dozen different processors, with wildly different C libraries, compiled using different host systems, using different IDEs, editors, build systems, etc. I can do that /precisely/ because gcc is a compiler and not an all-or-nothing development toolkit. But there are other people, and other tasks, for which an all-or-nothing complete toolkit is exactly what is wanted. And sometimes people want small and simple, other times people want large, full-featured and flexible. So there is a choice in the tools market. People can choose to download a massive MSVC system. They can choose to download a small and clear lcc-win system. They can choose to build gcc from sources or use it along with different libraries for different purposes. They can choose to buy pre-build packages of gcc, libraries, editors, etc. with full professional support. It is all there. clang is in a similar position to gcc, but it is a much newer project. Most of the pre-built packages (free or commercial) are therefore gcc - but you can expect to see them appearing for clang too. The choice is a good thing for customers and users - they can pick from a variety of solutions according to their needs, experience, interest, and budget. And of course it is a good thing for vendors - where would Jacob's market for lcc-win be if gcc or clang was as small and easy-to-use as his tools? Even in the world of free (/really/ free) tools this choice is good - some of the major contributors to gcc include groups like Code Sourcery and Red Hat's development tool group, which make their living selling packaged and supported gcc toolchains. As for what beginners should do when they want a C compiler, their main two choices are: 1. Use the most common or standard tools for their platform. 2. Use something that is easy to get installed and running. For Windows, option 1 is MSVC. Option 2 would be something like lcc-win. The use of gcc or clang on Windows is not really a beginners choice - it makes sense for people who have enough experience with C to know what they are looking for. For Linux, both options are gcc. For BSD (including Mac's), both options are clang.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-27 15:18 +0000 |
| Subject | Re: GCC vs Clang? |
| Message-ID | <5798d072.3878546@news.xs4all.nl> |
| In reply to | #91057 |
jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 25/07/2016 à 18:37, BartC a écrit : > > I don't get you. Obviously it is desirable for languages to be simple, > > self-contained and to Just Work, yes? > > YES! > > lcc-win comes with everything you need: compiler, linker, IDE make > utility and debugger in a single auto-installing package. > > LING! > > (Lcc-win Is Not Gcc) No, Lcc-win is lcc. So is Pelle's C, and it _is_ free for all purposes including commercial ones. But it doesn't come with your extensions. Richard
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web