Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #96073 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2016-11-08 22:17 +0800 |
| Last post | 2016-11-08 18:25 -0800 |
| Articles | 20 on this page of 296 — 29 participants |
Back to article view | Back to comp.lang.c
Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:17 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 14:25 +0000
[OI] chat "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:26 +0800
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:29 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 20:48 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 11:51 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 21:12 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 20:43 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 13:20 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 14:30 -0800
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 01:25 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 17:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 07:52 +0000
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 15:18 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:00 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-08 22:33 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 22:56 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 23:40 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:54 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:47 -0600
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:46 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:19 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:46 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-08 23:00 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 11:30 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 11:14 +0000
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:15 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 13:59 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:15 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 05:44 -0600
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:57 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:19 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 07:59 -0500
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 13:13 +0000
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 14:06 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 14:46 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:33 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:28 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:22 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 10:55 -0500
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:01 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:11 +0000
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 13:37 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:16 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 22:36 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 23:40 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 08:49 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 14:02 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 05:40 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 15:47 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-09 19:32 +0300
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:34 -0600
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:43 +0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 20:00 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-09 13:25 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:57 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 12:10 -0800
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 20:32 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:56 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:16 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:29 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:35 +0100
Re: Compiler design in C? Melzzzzz <mel@zzzzz.com> - 2016-11-09 21:55 +0100
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:49 -0600
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:31 +0100
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:42 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:03 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 15:37 +0300
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:13 -0800
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 20:22 +0300
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 12:29 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:02 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:24 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 12:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 12:36 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:43 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 21:06 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:12 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-09 14:35 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:10 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 21:28 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-09 21:32 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:36 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 07:10 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:32 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:05 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:06 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:14 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:33 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:20 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:15 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:29 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:09 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:25 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:35 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:29 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:59 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:10 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:27 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:42 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:46 +1300
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 16:27 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:47 +0100
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 19:29 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:17 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 13:45 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:31 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:41 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 20:57 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:16 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 13:35 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:43 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:58 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 14:28 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:47 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:51 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:27 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 15:57 -0800
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:38 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:46 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:51 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:45 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-14 00:27 -0600
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-14 21:24 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-14 09:45 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:54 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:19 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:47 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:22 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:01 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:49 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:02 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:10 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:17 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 06:56 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:05 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:09 -0500
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:56 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:37 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:07 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 22:43 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:50 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 11:43 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:36 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 15:05 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 16:25 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:14 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:01 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:35 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:08 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:30 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 12:20 -0800
Re: Compiler design in C? me <crisdunbar@gmail.com> - 2016-11-10 13:48 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:53 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:38 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:52 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 06:09 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 21:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 14:10 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-12 14:17 +0100
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 10:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 19:04 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-12 16:13 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:28 +0000
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 17:36 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 10:20 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 14:37 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 22:42 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 18:26 -0500
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:08 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 15:52 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:10 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 07:33 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 18:42 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 11:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 19:49 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 12:24 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 12:32 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-16 08:18 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-16 08:50 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-17 12:02 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-17 12:22 -0800
Re: Compiler design in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:35 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 10:52 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:28 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-09 13:27 -0800
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 23:43 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 17:57 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:26 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:39 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 15:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:50 +0000
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 13:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:07 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:15 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:26 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:44 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:48 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:34 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:57 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:17 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:18 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:24 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-08 19:59 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 00:51 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:59 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:08 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-11 14:41 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:55 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:21 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:32 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 16:11 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:12 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:03 +0000
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:21 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:30 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 21:51 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 13:16 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 23:04 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 14:12 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:05 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:43 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:49 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:33 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 22:45 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-12 18:14 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:12 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 11:38 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 00:44 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 11:45 -0500
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 09:42 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:14 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 22:59 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:15 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 19:11 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 15:40 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 20:45 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 17:20 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-09 19:49 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:14 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:28 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 00:45 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:40 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:42 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:18 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-13 11:46 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:22 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:52 -0800
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 14:57 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 00:13 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 15:46 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-08 20:04 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:23 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 08:01 -0500
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-09 12:27 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:32 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:43 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:30 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:35 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:12 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:19 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:46 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:01 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-11 16:04 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-11 08:36 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 17:41 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:58 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:10 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 10:35 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-08 14:21 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:28 +0100
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 22:47 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 09:52 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:33 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:03 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:15 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:47 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 22:55 +0100
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:44 +0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:18 -0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:25 -0800
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 22:43 +0100 |
| Message-ID | <o02ple$mcp$1@dont-email.me> |
| In reply to | #96340 |
Le 10/11/2016 à 22:35, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 10/11/2016 à 21:57, Gareth Owen a écrit :
>>> I actually considered mentioning this, but decided against it.
>>
>> And the reason was?
>>
>> Why is the pre-processor such an "evil"?
>>
>> Look at this for instance: (this is the "valarraygen.c file of the ccl)
>>
>> 81 static int ResizeTo(ValArray *AL,size_t newcapacity)
>> 82 {
>> 83 ElementType *oldcontents;
>> 84
>> 85 if (AL->capacity == newcapacity) return 0;
>> 86 oldcontents = AL->contents;
>> 87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity
>> * sizeof(ElementType));
>> 88 if (AL->contents == NULL) {
>> 89 AL->contents = oldcontents;
>> 90 return NoMemory("ResizeTo");
>> 91 }
>> 92 AL->capacity = newcapacity;
>> 93 AL->timestamp++;
>> 94 return 1;
>> 95 }
>>
>> ElementType is a macro. A plain #define with the name of the underlying
>> type.
>>
>> I find it OK, you can do a lot of things with the preprocessor.
>
> I'm probably missing some context here, but what is the advantage of
> making ElementType a macro rather than a typedef?
>
> In particular, if ElementType is `int[3]`, then
> ElementType *oldcontents;
> is a syntax error.
>
Look, you are effectively missing some context here. This function is
included in a small C file that
#define ElementType MyPieceOfData
where "MyPieceOfData" can be a type you use whatever.
Then you compile your small file
#include "valarraygen.c"
and your type will have a vector-array for it, complete with a standard
interface. You can put the code in a library and only the functions that
you use will get included in the final executable.
You point out that this doesn't work with
#define MyElementType int[3]
Yes. That doesn't work. You can then do:
typedef MyPieceOfData int[3];
And then
#define ElementType MyPieceOfData
Not very difficult Mr Thompson.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 21:58 +0000 |
| Message-ID | <87bmxnngim.fsf@gmail.com> |
| In reply to | #96343 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Look, you are effectively missing some context here. This function is > included in a small C file that > > #define ElementType MyPieceOfData > > where "MyPieceOfData" can be a type you use whatever. > > Then you compile your small file > #include "valarraygen.c" > > and your type will have a vector-array for it, complete with a > standard interface. You can put the code in a library and only the > functions that you use will get included in the final executable. How do I have two similar containers with dissimilar types in the same function? > Not very difficult Mr Thompson. Nowhere near as simple as C++ though.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-10 14:28 -0800 |
| Message-ID | <lnpom3nf5h.fsf@kst-u.example.com> |
| In reply to | #96343 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 10/11/2016 á 22:35, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 10/11/2016 á 21:57, Gareth Owen a écrit :
>>>> I actually considered mentioning this, but decided against it.
>>>
>>> And the reason was?
>>>
>>> Why is the pre-processor such an "evil"?
>>>
>>> Look at this for instance: (this is the "valarraygen.c file of the ccl)
>>>
>>> 81 static int ResizeTo(ValArray *AL,size_t newcapacity)
>>> 82 {
>>> 83 ElementType *oldcontents;
>>> 84
>>> 85 if (AL->capacity == newcapacity) return 0;
>>> 86 oldcontents = AL->contents;
>>> 87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity
>>> * sizeof(ElementType));
>>> 88 if (AL->contents == NULL) {
>>> 89 AL->contents = oldcontents;
>>> 90 return NoMemory("ResizeTo");
>>> 91 }
>>> 92 AL->capacity = newcapacity;
>>> 93 AL->timestamp++;
>>> 94 return 1;
>>> 95 }
>>>
>>> ElementType is a macro. A plain #define with the name of the underlying
>>> type.
>>>
>>> I find it OK, you can do a lot of things with the preprocessor.
>>
>> I'm probably missing some context here, but what is the advantage of
>> making ElementType a macro rather than a typedef?
>>
>> In particular, if ElementType is `int[3]`, then
>> ElementType *oldcontents;
>> is a syntax error.
>
> Look, you are effectively missing some context here.
Yes, as I acknowledged.
> This function is
> included in a small C file that
>
> #define ElementType MyPieceOfData
>
> where "MyPieceOfData" can be a type you use whatever.
>
> Then you compile your small file
> #include "valarraygen.c"
>
> and your type will have a vector-array for it, complete with a standard
> interface. You can put the code in a library and only the functions that
> you use will get included in the final executable.
>
> You point out that this doesn't work with
>
> #define MyElementType int[3]
>
> Yes. That doesn't work. You can then do:
>
> typedef MyPieceOfData int[3];
>
> And then
>
> #define ElementType MyPieceOfData
>
> Not very difficult Mr Thompson.
I never said it was very difficult. I still question whether it's
better than using a typedef in the first place.
You want me to write:
#define ElementType MyPieceOfData
#include "valarraygen.c"
I'd prefer to write:
typedef MyPieceOfData ElementType
#include "valarraygen.c"
and as far as I can tell it should still work.
--
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-11-10 14:47 -0800 |
| Message-ID | <380466f7-a4ce-472e-8c5d-bb3c5d1d0738@googlegroups.com> |
| In reply to | #96354 |
On Thursday, November 10, 2016 at 4:27:52 PM UTC-6, Keith Thompson wrote:> You want me to write:
>
> #define ElementType MyPieceOfData
> #include "valarraygen.c"
>
> I'd prefer to write:
>
> typedef MyPieceOfData ElementType
> #include "valarraygen.c"
>
> and as far as I can tell it should still work.
Depending upon how the include file is written, it may be possible to use
[I prefer .i as an exception for files which are only intended to be used
within other .c files, but which include definitions rather than just
declarations]
#define ElementType Fnord
#include "valarraygen.i"
#undef ElementType
#define ElementType Wizzle
#include "valarraygen.i"
#undef ElementType
If valarraygen is written suitably, it may define:
va_Fnord *va_Fnord_create(void) ...
va_Fnord_add(va_Fnord *it, Fnord *new_item) ...
va_Wizzle *va_Fnord_create(void) ...
va_Wizzle_add(va_Wizzle *it, Wizzle *new_item) ...
Nothing remotely like that would be possible using the typedef approach.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 22:51 +0000 |
| Message-ID | <87d1i3x81n.fsf@gmail.com> |
| In reply to | #96354 |
Keith Thompson <kst-u@mib.org> writes: > I'd prefer to write: > > typedef MyPieceOfData ElementType > #include "valarraygen.c" > > and as far as I can tell it should still work. I assume there's some token-pasting magic to relabel the public interface for when you want a two valarrays of different types
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-11 00:27 +0100 |
| Message-ID | <o02voe$g4l$1@dont-email.me> |
| In reply to | #96354 |
Le 10/11/2016 à 23:28, Keith Thompson a écrit : > I'd prefer to write: > > typedef MyPieceOfData ElementType > #include "valarraygen.c" > > and as far as I can tell it should still work. Mmmm good idea. The only thing that I could argue in favour of the preprocessor is that at the end of the include file I #undef "MyPieceOfData" and I can't do that with a typedef. There is no forget(MyPieceOfData) to get rid of a typedef. But why would you want to get rid of the symbol in the first place? Could it clash with other symbols in the user's system? It is the programmer that decides that name so... I can't tell you right now but maybe the typedef is better than the define, I have to think about it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-10 15:57 -0800 |
| Message-ID | <lna8d6opm9.fsf@kst-u.example.com> |
| In reply to | #96361 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 10/11/2016 à 23:28, Keith Thompson a écrit :
>> I'd prefer to write:
>>
>> typedef MyPieceOfData ElementType
>> #include "valarraygen.c"
>>
>> and as far as I can tell it should still work.
>
> Mmmm good idea.
Thanks.
> The only thing that I could argue in favour of the
> preprocessor is that at the end of the include file I #undef
> "MyPieceOfData" and I can't do that with a typedef. There is no
>
> forget(MyPieceOfData)
>
> to get rid of a typedef.
Well, a typedef does vanish at the end of its scope.
> But why would you want to get rid of the symbol in the first place?
>
> Could it clash with other symbols in the user's system?
>
> It is the programmer that decides that name so... I can't tell you right
> now but maybe the typedef is better than the define, I have to think
> about it.
Somebody suggested that a macro could be used with token-pasting to
generate unique function names. I haven't looked at your code closely
enough to know whether that's an issue.
I'm not suggesting that it's all that big a deal. I just prefer to use
typedefs rather than macros if possible, both because of syntax issues
(with array types, for example) and because it ... feels cleaner.
Macros do give you some finer control over when you can redefine them.
That can be good or bad.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-11 10:38 +1300 |
| Message-ID | <e8k7mjFl834U5@mid.individual.net> |
| In reply to | #96337 |
On 11/11/16 10:16 AM, jacobnavia wrote: > Le 10/11/2016 à 21:57, Gareth Owen a écrit : >> I actually considered mentioning this, but decided against it. > > And the reason was? > > Why is the pre-processor such an "evil"? Not so much an evil as a kludge! One of the biggest problem with using function like macros to implement generics is code bloat. With language native generics, such as C++ templates, the compiler can choose whether or not to inline, with a macro it can't. Another is the lack of scope. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 22:46 +0100 |
| Message-ID | <o02prh$n29$1@dont-email.me> |
| In reply to | #96341 |
Le 10/11/2016 à 22:38, Ian Collins a écrit : > ne of the biggest problem with using function like macros to implement > generics is code bloat. In the function that I showed there is no code blat since the macro is just replacing the "ElementType" place holder with the name of your type. The compiler doesn't even see the macro. With language native generics, such as C++ > templates, the compiler can choose whether or not to inline, with a > macro it can't. Yes, function like macros, but here there is only text substitution! No code bloat here since the macro doesn't generate any code.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-11 10:51 +1300 |
| Message-ID | <e8k8f3Fl834U7@mid.individual.net> |
| In reply to | #96346 |
On 11/11/16 10:46 AM, jacobnavia wrote: > Le 10/11/2016 à 22:38, Ian Collins a écrit : >> ne of the biggest problem with using function like macros to implement >> generics is code bloat. > > In the function that I showed there is no code blat since the macro is > just replacing the "ElementType" place holder with the name of your > type. The compiler doesn't even see the macro. > > > With language native generics, such as C++ >> templates, the compiler can choose whether or not to inline, with a >> macro it can't. > > > Yes, function like macros, but here there is only text substitution! > > No code bloat here since the macro doesn't generate any code. In this case, no but in others (you mentioned sorting functions up-thread) where function like macros are used to implement generics, there will be. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 22:04 +0000 |
| Message-ID | <877f8bng9u.fsf@gmail.com> |
| In reply to | #96346 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Yes, function like macros, but here there is only text substitution!
>
> No code bloat here since the macro doesn't generate any code.
So, what would the following simple three-line function look
like written C + LCC?
void f()
{
std::vector<int> v_int(1000);
for(auto& v: v_int) v = rand();
std::sort(v.begin(),v.end());
}
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-11 00:18 +0100 |
| Message-ID | <o02v6e$ej4$1@dont-email.me> |
| In reply to | #96353 |
Le 10/11/2016 à 23:04, Gareth Owen a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>> Yes, function like macros, but here there is only text substitution!
>>
>> No code bloat here since the macro doesn't generate any code.
>
> So, what would the following simple three-line function look
> like written C + LCC?
>
> void f()
> {
> std::vector<int> v_int(1000);
> for(auto& v: v_int) v = rand();
> std::sort(v.begin(),v.end());
> }
>
1) The c containers library is written in C89/C99, and it compiles with
gcc or msvc or clang. Or lcc if you wish, since it is written in C.
2) The code would look like this:
1 #include <stdlib.h>
2 #include "../containers.h"
3
4 int main(void)
5 {
6 int i;
7
8 ValArrayInt * table = iValArrayInt.Create(10000);
9 size_t siz = iValArrayInt.GetCapacity(table);
10 for (i=0; i<siz;i++) {
11 iValArrayInt.Add(table,rand());
12 }
18 iValArrayInt.Sort(table);
19
25 }
You create a table (line 8), then you fill it (line 10 to 12) and then
you sort it (line 18).
A slightly more elaborate version prints the first 5 elements before and
after sorting. I could have used iterators but for a small sample
printing it is not really necessary. I could have reduced the line count
by avoiding empty lines but who cares? The function is just as concise
and small as the c++ one.
1 #include <stdlib.h>
2 #include "../containers.h"
3
4 int main(void)
5 {
6 int i;
7
8 ValArrayInt * table = iValArrayInt.Create(10000);
9 size_t siz = iValArrayInt.GetCapacity(table);
10 for (i=0; i<siz;i++) {
11 iValArrayInt.Add(table,rand());
12 }
13 printf("5 first elements before sorting\n");
14 for (i=0; i<5; i++) {
15 int data = iValArrayInt.GetElement(table,i);
16 printf("Position [%d] is %d\n",i,data);
17 }
18 iValArrayInt.Sort(table);
19
20 printf("5 first elements after sorting\n");
21 for (i=0; i<5; i++) {
22 int data = iValArrayInt.GetElement(table,i);
23 printf("Position [%d] is %d\n",i,data);
24 }
25 }
prints out:
/tmp/ccl/test $ ./a.out
5 first elements before sorting
Position [0] is 16807
Position [1] is 282475249
Position [2] is 1622650073
Position [3] is 984943658
Position [4] is 1144108930
5 first elements after sorting
Position [0] is 8383
Position [1] is 13456
Position [2] is 16807
Position [3] is 84083
Position [4] is 86383
/tmp/ccl/test $
---------------------------------------------------------------------
Your c++ version:
First, it doesn't compile unless I add the corresponding includes and
transform your function in "main".
1 #include <cstdlib>
2 #include <vector>
3 int main()
4 {
5 std::vector<int> v_int(1000);
6 for(auto& v: v_int) v = rand();
7 std::sort(v.begin(),v.end());
8 }
9
But now the compiler says:
/tmp/ccl/test $ g++ -std=c++11 t.cpp
t.cpp:7:13: error: use of undeclared identifier 'v'
std::sort(v.begin(),v.end());
^
t.cpp:7:23: error: use of undeclared identifier 'v'
std::sort(v.begin(),v.end());
^
2 errors generated.
/tmp/ccl/test $
I think that line 7 should be:
7 std::sort(v_int.begin(),v_int.end());
I chyanged that and it compiles.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-11 05:45 +0000 |
| Message-ID | <87r36ik1rl.fsf@gmail.com> |
| In reply to | #96358 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>> void f()
>> {
>> std::vector<int> v_int(1000);
>> for(auto& v: v_int) v = rand();
>> std::sort(v.begin(),v.end());
>> }
>>
>
> 1) The c containers library is written in C89/C99, and it compiles
> with gcc or msvc or clang. Or lcc if you wish, since it is written in
> C.
>
> 2) The code would look like this:
> 1 #include <stdlib.h>
> 2 #include "../containers.h"
> 3
> 4 int main(void)
> 5 {
> 6 int i;
> 7
> 8 ValArrayInt * table = iValArrayInt.Create(10000);
> 9 size_t siz = iValArrayInt.GetCapacity(table);
> 10 for (i=0; i<siz;i++) {
> 11 iValArrayInt.Add(table,rand());
> 12 }
> 18 iValArrayInt.Sort(table);
> 19
> 25 }
>
> You create a table (line 8), then you fill it (line 10 to 12) and then
> you sort it (line 18).
Where's your
#define ElementType ?
???
Do you have pre-made versions for the builtin types?
What's the equivalent for a non-builtin type?
> I think that line 7 should be:
> 7 std::sort(v_int.begin(),v_int.end());
You're right. Brain error.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-11-14 00:27 -0600 |
| Message-ID | <0sli2c9o18kg6i6rt3igc4u0pafa4m2a40@4ax.com> |
| In reply to | #96341 |
On Fri, 11 Nov 2016 10:38:27 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 11/11/16 10:16 AM, jacobnavia wrote: >> Le 10/11/2016 à 21:57, Gareth Owen a écrit : >>> I actually considered mentioning this, but decided against it. >> >> And the reason was? >> >> Why is the pre-processor such an "evil"? > >Not so much an evil as a kludge! > >One of the biggest problem with using function like macros to implement >generics is code bloat. With language native generics, such as C++ >templates, the compiler can choose whether or not to inline, with a >macro it can't. That's not really true. A compiler can certainly "out-line" code if it wants to, especially common sequences. Back in the late seventies/early eighties, this was a much hyped optimization in a few Cobol compilers (the compilers would find common code sequences and "out-line" them as a subroutine to save space). It's not a popular optimization today (Are there any actual implementations today? Perhaps for small embedded targets? Common subexpression elimination is a simpler, but related, idea, and *is* common.), and 70s vintage Cobol certainly had attributes that lead to considerable code duplication (no subroutines with parameters*, for example), which may have made such a space optimization much more attractive. *And let's not restart the debate that "CALL" statements were the actual subroutine call in Cobol, almost nobody actually used them that way, leaving us with the parameter-less "PERFORM".
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-14 21:24 +1300 |
| Message-ID | <e8taldF2p0mU1@mid.individual.net> |
| In reply to | #96526 |
On 11/14/16 07:27 PM, Robert Wessel wrote: > On Fri, 11 Nov 2016 10:38:27 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 11/11/16 10:16 AM, jacobnavia wrote: >>> Le 10/11/2016 à 21:57, Gareth Owen a écrit : >>>> I actually considered mentioning this, but decided against it. >>> >>> And the reason was? >>> >>> Why is the pre-processor such an "evil"? >> >> Not so much an evil as a kludge! >> >> One of the biggest problem with using function like macros to implement >> generics is code bloat. With language native generics, such as C++ >> templates, the compiler can choose whether or not to inline, with a >> macro it can't. > > > That's not really true. A compiler can certainly "out-line" code if > it wants to, especially common sequences. Yes it can and compilers targeting embedded platforms will be able to do this. The big drawback is to be effective, such optimisations have to be done at link time. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-14 09:45 +0100 |
| Message-ID | <o0btho$nnk$1@dont-email.me> |
| In reply to | #96526 |
On 14/11/16 07:27, Robert Wessel wrote: > On Fri, 11 Nov 2016 10:38:27 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 11/11/16 10:16 AM, jacobnavia wrote: >>> Le 10/11/2016 à 21:57, Gareth Owen a écrit : >>>> I actually considered mentioning this, but decided against it. >>> >>> And the reason was? >>> >>> Why is the pre-processor such an "evil"? >> >> Not so much an evil as a kludge! >> >> One of the biggest problem with using function like macros to implement >> generics is code bloat. With language native generics, such as C++ >> templates, the compiler can choose whether or not to inline, with a >> macro it can't. > > > That's not really true. A compiler can certainly "out-line" code if > it wants to, especially common sequences. Back in the late > seventies/early eighties, this was a much hyped optimization in a few > Cobol compilers (the compilers would find common code sequences and > "out-line" them as a subroutine to save space). It's not a popular > optimization today (Are there any actual implementations today? > Perhaps for small embedded targets? Common subexpression elimination > is a simpler, but related, idea, and *is* common.), and 70s vintage > Cobol certainly had attributes that lead to considerable code > duplication (no subroutines with parameters*, for example), which may > have made such a space optimization much more attractive. > > *And let's not restart the debate that "CALL" statements were the > actual subroutine call in Cobol, almost nobody actually used them that > way, leaving us with the parameter-less "PERFORM". > Modern compilers (and/or linkers) can combine some code sections or entire functions if the code is identical - this is particularly useful for C++ templates. It has been a while since I have used a compiler that actively searched for common generated code sequences and collected them as subroutines to save space - perhaps 12 years ago. And it was indeed for a small embedded target. By the time you have link-time code generation, inter-procedural optimisations, etc., there is little to be gained by "outlining" code - unless someone has gone overboard with their macros.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 21:54 +0000 |
| Message-ID | <87fumzngqv.fsf@gmail.com> |
| In reply to | #96337 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 10/11/2016 à 21:57, Gareth Owen a écrit :
>> I actually considered mentioning this, but decided against it.
>
> And the reason was?
I didn't consider it particularly relevant.
> Why is the pre-processor such an "evil"?
No. It's fine.
> I find it OK, you can do a lot of things with the preprocessor.
I find it OK, also.
> 81 static int ResizeTo(ValArray *AL,size_t newcapacity)
> 82 {
> 83 ElementType *oldcontents;
> 84
> 85 if (AL->capacity == newcapacity) return 0;
> 86 oldcontents = AL->contents;
> 87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity
> * sizeof(ElementType));
> 88 if (AL->contents == NULL) {
> 89 AL->contents = oldcontents;
> 90 return NoMemory("ResizeTo");
> 91 }
> 92 AL->capacity = newcapacity;
> 93 AL->timestamp++;
> 94 return 1;
> 95 }
What if I want two different containers in the same translation unit?
What mitigation is there for multiple functions called ResizeTo?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-11 00:19 +0100 |
| Message-ID | <o02v9k$ej4$2@dont-email.me> |
| In reply to | #96351 |
Le 10/11/2016 à 22:54, Gareth Owen a écrit : > What if I want two different containers in the same translation unit? You compile the two different containers and you put that in a library. Then you use them.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-11 05:47 +0000 |
| Message-ID | <87mvh6k1pc.fsf@gmail.com> |
| In reply to | #96359 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 10/11/2016 à 22:54, Gareth Owen a écrit : >> What if I want two different containers in the same translation unit? > > You compile the two different containers and you put that in a library. > > Then you use them. So I need a new source file for every container type / contained type? Yikes
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-11 00:22 +0100 |
| Message-ID | <o02ve9$ej4$3@dont-email.me> |
| In reply to | #96351 |
Le 10/11/2016 à 22:54, Gareth Owen a écrit : > What mitigation is there for multiple functions called ResizeTo? There is no function called "ResizeTo". The only thing that exists is a table of function pointers, where the nth position is filled with a pointer to an anonymous (static) function that will be executed if you use the function pointer at that position, the position of the "ResizeTo" interface API, as described in the header files.
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web