Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56134 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-01-10 13:11 -0800 |
| Last post | 2015-01-20 00:12 -0800 |
| Articles | 20 on this page of 261 — 38 participants |
Back to article view | Back to comp.lang.c
faster than c fir <profesor.fir@gmail.com> - 2015-01-10 13:11 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-10 14:26 -0800
Re: faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:43 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:39 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-11 09:23 +0000
Re: faster than c asetofsymbols@gmail.com - 2015-01-11 02:17 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-11 06:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 06:46 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 15:01 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 13:44 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 16:59 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 15:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 04:56 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-12 23:26 +0000
Re: faster than c jt@toerring.de (Jens Thoms Toerring) - 2015-01-13 01:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 05:16 -0800
faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:42 -0800
Re: faster than c Cooler_x0a <c00f3r@gmail.com> - 2015-01-10 15:51 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-11 00:21 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-11 02:27 -0800
Re: faster than c gamo <gamo@telecable.es> - 2015-01-11 12:17 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:02 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 03:44 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 05:08 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 06:03 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:06 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 06:57 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-22 07:27 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:45 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:16 +0100
Re: faster than c Tim Prince <tprince@computer.org> - 2015-01-11 15:42 -0500
Re: faster than c Michael Angelo Ravera <maravera@prodigy.net> - 2015-01-14 12:25 -0800
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 13:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:32 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 14:42 +0100
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 19:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:55 -0800
Re: faster than c "Osmium" <r124c4u102@comcast.net> - 2015-01-17 08:00 -0600
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 10:15 -0800
Re: faster than c wssimms@gmail.com - 2015-01-17 10:31 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:21 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:13 -0800
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-17 12:32 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:01 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 08:24 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 22:52 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:04 -0600
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 10:12 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 23:05 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 16:23 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:32 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-24 19:08 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 12:31 -0700
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:45 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 12:58 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-25 21:22 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:30 -0700
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:50 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:20 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 00:55 +0100
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 01:06 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 11:34 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 20:29 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:34 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-26 13:53 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:08 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:28 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:42 -0700
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 20:06 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:37 +1300
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 05:13 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 15:23 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 10:02 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 10:58 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 08:26 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-17 13:51 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 11:24 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-18 12:11 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:29 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 13:08 +0200
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 23:33 +1200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 14:19 +0200
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:43 +0000
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-19 13:46 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-19 23:33 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:25 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 00:37 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 00:25 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-23 19:36 +1200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 09:10 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:19 +0200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 13:41 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 10:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:25 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-24 04:45 -0700
Re: faster than c Bartc <bc@freeuk.com> - 2015-04-24 13:36 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-27 06:16 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 14:44 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:10 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:03 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 16:22 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:18 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 16:58 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 09:21 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 12:51 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:47 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 17:20 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:51 -0700
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-17 23:10 +0000
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:46 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:56 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:33 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 22:56 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-16 20:06 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 08:44 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-16 20:21 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 09:55 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 15:43 +1200
Re: faster than c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 11:33 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 12:36 +1200
Re: faster than c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 11:24 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 20:07 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 15:59 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 14:04 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 16:52 +1200
Re: faster than c Paavo Helde <myfirstname@osa.pri.ee> - 2015-04-19 09:27 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 23:04 -0700
Re: faster than c Philip Lantz <prl@canterey.us> - 2015-03-31 00:14 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 00:18 -0700
Re: faster than c wssimms@gmail.com - 2015-01-17 10:33 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-17 20:03 +0000
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:07 +0100
Re: faster than c wpihughes@gmail.com - 2015-01-26 13:30 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:36 +1300
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:02 +0000
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 19:14 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:41 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 12:06 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 20:36 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:01 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 21:18 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:36 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:17 +0100
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 10:40 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:29 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:41 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 12:45 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:31 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:48 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 15:23 +0100
Re: faster than c mark.bluemel@gmail.com - 2015-01-19 07:25 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-19 08:56 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 17:01 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:08 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:19 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 17:46 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 10:19 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-19 10:56 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 11:30 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 14:22 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-20 00:45 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 01:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 08:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 00:57 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 03:58 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:05 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 02:11 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 02:18 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 02:30 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 05:16 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-20 14:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:29 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-20 21:53 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 17:37 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 00:05 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 01:38 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 07:46 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-21 03:23 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:52 +0000
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-21 08:53 -0600
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 16:41 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:58 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:11 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 02:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:38 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-21 08:48 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:24 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 13:38 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-21 16:43 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 10:09 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-24 01:15 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 23:59 -0600
Re: faster than c fmassei@gmail.com - 2015-01-22 01:17 -0800
Re: faster than c wssimms@gmail.com - 2015-01-22 05:16 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:27 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-22 05:36 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:54 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 05:55 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 00:53 -0600
Re: faster than c fmassei@gmail.com - 2015-01-23 00:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:09 -0800
Re: faster than c fmassei@gmail.com - 2015-01-23 01:33 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:55 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-23 22:44 +1300
Re: faster than c fmassei@gmail.com - 2015-01-23 01:56 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:11 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 06:21 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 16:46 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 07:58 -0800
Re: faster than c Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-01-22 12:29 -0500
Re: faster than c fmassei@gmail.com - 2015-01-22 10:09 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-22 14:07 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-24 00:40 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-24 12:53 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-22 15:09 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 01:59 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:46 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 02:15 -0500
Re: faster than c asetofsymbols@gmail.com - 2015-03-25 02:45 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 11:30 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-26 00:42 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 11:35 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-17 14:42 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 22:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 15:13 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 22:02 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 16:21 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 01:27 +0000
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-18 01:41 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 00:11 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 11:23 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 20:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 13:12 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 15:49 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 16:06 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 01:03 +0000
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 08:13 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 01:39 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 13:52 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:36 +0000
Re: faster than c Walter Banks <walter@bytecraft.com> - 2015-01-20 14:01 -0500
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 11:18 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 22:30 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:49 +1300
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 14:30 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 07:32 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 15:56 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 08:33 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 02:26 -0800
faster than c asetofsymbols@gmail.com - 2015-01-20 00:12 -0800
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-16 20:21 +1200 |
| Message-ID | <cp99nhFfnp3U3@mid.individual.net> |
| In reply to | #60112 |
Tim Rentsch wrote: > > The second item is about how such workarounds might be done and > to what extent they meet the needs of using compound literls. > You gave an example (which I slightly mislabeled in my []'ed > summary - that should be "snip example of how to re-write a C > fragment in C/C++ common subset", which is more like what I > actually meant) showing how to do that. I agree that your > example shows a reasonable way of writing the example line so as > not to use a compound literal. The problem is, the example line > is not representative of how compound literals are typically > used. Usually compound literals are used as subexpressions of a > larger expression, not as the (whole) initializer portion of a > declared variable. To use the technique illustrated in your > example, in most cases it would be necessary to introduce a > declaration so that there could be an initializer list to give > the initial value. The point of using a compound literal, and > indeed why they were added to the language in the first place, is > so we don't have to add a declaration just to supply a compound > value. It is this point that I was addressing in my middle > response of the quoted stuff above. I thought my function call example illustrated not having to add a declaration just to supply a compound value. Perhaps an example of "compound literals are used as subexpressions of a larger expression" would help clarify the discussion? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-17 09:55 -0700 |
| Message-ID | <kfn4moey9r8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60119 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>
>> The second item is about how such workarounds might be done and
>> to what extent they meet the needs of using compound literls.
>> You gave an example (which I slightly mislabeled in my []'ed
>> summary - that should be "snip example of how to re-write a C
>> fragment in C/C++ common subset", which is more like what I
>> actually meant) showing how to do that. I agree that your
>> example shows a reasonable way of writing the example line so as
>> not to use a compound literal. The problem is, the example line
>> is not representative of how compound literals are typically
>> used. Usually compound literals are used as subexpressions of a
>> larger expression, not as the (whole) initializer portion of a
>> declared variable. To use the technique illustrated in your
>> example, in most cases it would be necessary to introduce a
>> declaration so that there could be an initializer list to give
>> the initial value. The point of using a compound literal, and
>> indeed why they were added to the language in the first place, is
>> so we don't have to add a declaration just to supply a compound
>> value. It is this point that I was addressing in my middle
>> response of the quoted stuff above.
>
> I thought my function call example illustrated not having to add a
> declaration just to supply a compound value. Perhaps an example of
> "compound literals are used as subexpressions of a larger expression"
> would help clarify the discussion?
My context is writing C code, so for me arguments to function
calls count as being a subexpression of a larger expression.
However here are some other examples.
Doing arithmetic conversions, compound literals can (and IMO
should) be used instead of casts. For example, functions
like isupper() expect a non-negative value (for characters),
not necessarily a 'char' value. (The parameter type is 'int'.)
Hence:
char *p = something();
...
if( isupper( (unsigned char){ *p } ) ) ...
Here it's important to convert the type to (unsigned char) rather
than to the type of the parameter. This conversion could of
course be done with a cast, but I think using a compound literal
is better style. (I really hate casts.)
A different kind of example is doing bit-level conversion,
sometimes called type-punning. Suppose for example we want to
treat an unsigned int as a signed int (a similar case came up in
writing the code for strtol() that I did recently) at the bit
level. This can be done using a union compound literal:
unsigned u = something();
...
return (union { unsigned u; signed s; }){ u }.s;
Somewhat related to that, sometimes we want to supply a
value to a function that takes a pointer to an argument, and
both inspects and writes into the pointed-to object. It's
important to supply a value, but if we don't care about the
(overwritten) output result, the argument can be written
directly using a compound literal, taking advantage of the
property that compound literals are lvalues:
rc = example( x, y, &(int){ 0 } );
This leads into what may be the most common case, where
what is needed is a pointer, but the value to be used
is an array. Here is some actual code written as part
of my test scaffolding for the strtoul() functions:
static TestSet trials = {{
(String[]){ "", 0 },
(String[]){ "", "+", "-", " ", " +", " -", 0 },
(String[]){ "", "0", "0x", "0X", 0 },
(int[]){ 0, 1, 2, 3, 4, 5, -1 },
(ULL[]){
1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
100, 1000, 10000, 100000, 1000000, 10000000,
100000000, 1000000000,
LONG_MAX-1, LONG_MAX, LONG_MAX+1ULL, LONG_MAX+2ULL,
ULONG_MAX-1, ULONG_MAX, ULONG_MAX+1ULL, ULONG_MAX+2ULL,
LLONG_MAX-1, LLONG_MAX, LLONG_MAX+1ULL, LLONG_MAX+2ULL,
ULLONG_MAX-1, ULLONG_MAX,
0
},
(String[]){ "", "!", "0000", 0 },
}};
It's necessary to use compound literals in the initializer (ie,
as opposed to using sub-initializers), because the structure
whose values are being filled in takes pointers, not arrays.
Of course, all of these (including arguments to function calls,
which matter in the C context) can be re-written so as not to
use compound literals. But the code that results is decidedly
clunkier.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-18 15:43 +1200 |
| Message-ID | <cpe27hFl1o8U2@mid.individual.net> |
| In reply to | #60247 |
Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>>
>> I thought my function call example illustrated not having to add a
>> declaration just to supply a compound value. Perhaps an example of
>> "compound literals are used as subexpressions of a larger expression"
>> would help clarify the discussion?
Thank you for taking the time to provide some examples. In order to
evaluate the alternatives below, I've had to learn more about C++
initialiser lists than I did this morning!
> My context is writing C code, so for me arguments to function
> calls count as being a subexpression of a larger expression.
> However here are some other examples.
>
> Doing arithmetic conversions, compound literals can (and IMO
> should) be used instead of casts. For example, functions
> like isupper() expect a non-negative value (for characters),
> not necessarily a 'char' value. (The parameter type is 'int'.)
> Hence:
>
> char *p = something();
> ...
> if( isupper( (unsigned char){ *p } ) ) ...
I guess the C++ equivalent would be to use a static_cast here.
> Here it's important to convert the type to (unsigned char) rather
> than to the type of the parameter. This conversion could of
> course be done with a cast, but I think using a compound literal
> is better style. (I really hate casts.)
>
> A different kind of example is doing bit-level conversion,
> sometimes called type-punning. Suppose for example we want to
> treat an unsigned int as a signed int (a similar case came up in
> writing the code for strtol() that I did recently) at the bit
> level. This can be done using a union compound literal:
>
> unsigned u = something();
> ...
>
> return (union { unsigned u; signed s; }){ u }.s;
I guess the C++ equivalent would be to use a static_cast here as well.
> Somewhat related to that, sometimes we want to supply a
> value to a function that takes a pointer to an argument, and
> both inspects and writes into the pointed-to object. It's
> important to supply a value, but if we don't care about the
> (overwritten) output result, the argument can be written
> directly using a compound literal, taking advantage of the
> property that compound literals are lvalues:
>
> rc = example( x, y, &(int){ 0 } );
Now I see where your use of compound literals wouldn't fit with the way
C++ initialiser lists work. Initialiser list objects and temporaries
are rvalues in C++, so neither can be used here. In C++ one would have
to use an rvalue reference as the third parameter of example:
int example( int, int, int&& );
and pass a temporary:
int rc = example( 1, 2, int(0) );
> This leads into what may be the most common case, where
> what is needed is a pointer, but the value to be used
> is an array. Here is some actual code written as part
> of my test scaffolding for the strtoul() functions:
Again, this would be problematic in C++, unless the object is const. So
one could have:
const int* y = std::begin({ 1, 2, 3 });
or (useful if you really want the data in read only memory)
constexpr const int* y = std::begin({ 1, 2, 3 });
>
> static TestSet trials = {{
> (String[]){ "", 0 },
> (String[]){ "", "+", "-", " ", " +", " -", 0 },
> (String[]){ "", "0", "0x", "0X", 0 },
> (int[]){ 0, 1, 2, 3, 4, 5, -1 },
> (ULL[]){
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
> 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
> 100, 1000, 10000, 100000, 1000000, 10000000,
> 100000000, 1000000000,
> LONG_MAX-1, LONG_MAX, LONG_MAX+1ULL, LONG_MAX+2ULL,
> ULONG_MAX-1, ULONG_MAX, ULONG_MAX+1ULL, ULONG_MAX+2ULL,
> LLONG_MAX-1, LLONG_MAX, LLONG_MAX+1ULL, LLONG_MAX+2ULL,
> ULLONG_MAX-1, ULLONG_MAX,
> 0
> },
> (String[]){ "", "!", "0000", 0 },
> }};
>
> It's necessary to use compound literals in the initializer (ie,
> as opposed to using sub-initializers), because the structure
> whose values are being filled in takes pointers, not arrays.
This could be written with initialiser lists if the pointers were const
(which in this case, is probably desirable!). Something like:
struct TestSet
{
const String* s1;
const String* s2;
const String* s3;
const int* i;
const uint64_t* ull;
const String* s4;
};
> Of course, all of these (including arguments to function calls,
> which matter in the C context) can be re-written so as not to
> use compound literals. But the code that results is decidedly
> clunkier.
True enough. I guess in practical use cases the significant differences
between compound literals and initialiser lists are the ability to use
anonymous types with the former and whether the resulting object is an
lvalue or an rvalue
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-18 11:33 +0100 |
| Message-ID | <87y4lpbua6.fsf@bsb.me.uk> |
| In reply to | #60290 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
<snip>
>> A different kind of example is doing bit-level conversion,
>> sometimes called type-punning. Suppose for example we want to
>> treat an unsigned int as a signed int (a similar case came up in
>> writing the code for strtol() that I did recently) at the bit
>> level. This can be done using a union compound literal:
>>
>> unsigned u = something();
>> ...
>>
>> return (union { unsigned u; signed s; }){ u }.s;
>
> I guess the C++ equivalent would be to use a static_cast here as well.
static_cast does not do the right thing here because it converts the
value rather than reinterpreting the bits. But since in this example
the unsigned is available as a lvalue you can use C++ reinterpret_cast
to a reference:
reinterpret_cast<signed &>(u)
If, however, you had a more general unsigned (rvalue) expression, this
would not be permitted.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-19 12:36 +1200 |
| Message-ID | <cpgbk7Fl1o8U6@mid.individual.net> |
| In reply to | #60298 |
Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Tim Rentsch wrote:
> <snip>
>>> A different kind of example is doing bit-level conversion,
>>> sometimes called type-punning. Suppose for example we want to
>>> treat an unsigned int as a signed int (a similar case came up in
>>> writing the code for strtol() that I did recently) at the bit
>>> level. This can be done using a union compound literal:
>>>
>>> unsigned u = something();
>>> ...
>>>
>>> return (union { unsigned u; signed s; }){ u }.s;
>>
>> I guess the C++ equivalent would be to use a static_cast here as well.
>
> static_cast does not do the right thing here because it converts the
> value rather than reinterpreting the bits. But since in this example
> the unsigned is available as a lvalue you can use C++ reinterpret_cast
> to a reference:
>
> reinterpret_cast<signed &>(u)
Good spot.
> If, however, you had a more general unsigned (rvalue) expression, this
> would not be permitted.
You could just cast it to a const reference, ie:
const float f = 42.32;
int n = reinterpret_cast<const int&>(f);
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-19 11:24 +0100 |
| Message-ID | <87fv7wa01r.fsf@bsb.me.uk> |
| In reply to | #60356 |
Ian Collins <ian-news@hotmail.com> writes:
> Ben Bacarisse wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Tim Rentsch wrote:
>> <snip>
>>>> A different kind of example is doing bit-level conversion,
>>>> sometimes called type-punning. Suppose for example we want to
>>>> treat an unsigned int as a signed int (a similar case came up in
>>>> writing the code for strtol() that I did recently) at the bit
>>>> level. This can be done using a union compound literal:
>>>>
>>>> unsigned u = something();
>>>> ...
>>>>
>>>> return (union { unsigned u; signed s; }){ u }.s;
>>>
>>> I guess the C++ equivalent would be to use a static_cast here as well.
>>
>> static_cast does not do the right thing here because it converts the
>> value rather than reinterpreting the bits. But since in this example
>> the unsigned is available as a lvalue you can use C++ reinterpret_cast
>> to a reference:
>>
>> reinterpret_cast<signed &>(u)
>
> Good spot.
>
>> If, however, you had a more general unsigned (rvalue) expression, this
>> would not be permitted.
>
> You could just cast it to a const reference, ie:
>
> const float f = 42.32;
>
> int n = reinterpret_cast<const int&>(f);
Sure, but that rather defeats the purpose (or some of the purpose) as I
understand it. The compound literal provides a expression to do the
job, so as soon as you need a declaration you are in different syntactic
waters. I could not come up with an expression that would work with an
arbitrary rvalue, but I am not well-versed in the corners of C++.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-18 20:07 -0700 |
| Message-ID | <kfn1tjgx1c3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60290 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> I thought my function call example illustrated not having to add a
>>> declaration just to supply a compound value. Perhaps an example
>>> of "compound literals are used as subexpressions of a larger
>>> expression" would help clarify the discussion?
>
> Thank you for taking the time to provide some examples. In order
> to evaluate the alternatives below, I've had to learn more about
> C++ initialiser lists than I did this morning!
I've been frustrated in my attempts to do so, due to a lack of
good reference material. The C++ standard is IMO rather poorly
done as a language reference.
>> My context is writing C code, so for me arguments to function
>> calls count as being a subexpression of a larger expression.
>> However here are some other examples.
>>
>> Doing arithmetic conversions, compound literals can (and IMO
>> should) be used instead of casts. For example, functions
>> like isupper() expect a non-negative value (for characters),
>> not necessarily a 'char' value. (The parameter type is 'int'.)
>> Hence:
>>
>> char *p = something();
>> ...
>> if( isupper( (unsigned char){ *p } ) ) ...
>
> I guess the C++ equivalent would be to use a static_cast here.
Yes. Not quite as safe in general as compound literals, although
for arithmetic target types I think they are the same.
>> Here it's important to convert the type to (unsigned char) rather
>> than to the type of the parameter. This conversion could of
>> course be done with a cast, but I think using a compound literal
>> is better style. (I really hate casts.)
>>
>> A different kind of example is doing bit-level conversion,
>> sometimes called type-punning. Suppose for example we want to
>> treat an unsigned int as a signed int (a similar case came up in
>> writing the code for strtol() that I did recently) at the bit
>> level. This can be done using a union compound literal:
>>
>> unsigned u = something();
>> ...
>>
>> return (union { unsigned u; signed s; }){ u }.s;
>
> I guess the C++ equivalent would be to use a static_cast here as
> well.
This would be (as already pointed out) reinterpret_cast, but
reinterpret_cast is not guaranteed to do the same thing that
a union does. Also, when done with a union, two types are
specified, not just one, so a more faithful tranlation would
be, eg, (assuming I understand the C++ syntax)
reinterpret_cast<signed>( static_cast<unsigned>( u ) )
Another way of saying this is that using reinterpret_cast by
itself is unsafe because it is affected by changes in type of the
expression being converted (and is unsafe in that form - any
scalar type can be converted to any other).
>> Somewhat related to that, sometimes we want to supply a
>> value to a function that takes a pointer to an argument, and
>> both inspects and writes into the pointed-to object. It's
>> important to supply a value, but if we don't care about the
>> (overwritten) output result, the argument can be written
>> directly using a compound literal, taking advantage of the
>> property that compound literals are lvalues:
>>
>> rc = example( x, y, &(int){ 0 } );
>
> Now I see where your use of compound literals wouldn't fit with
> the way C++ initialiser lists work. Initialiser list objects and
> temporaries are rvalues in C++, so neither can be used here. In
> C++ one would have to use an rvalue reference as the third
> parameter of example:
>
> int example( int, int, int&& );
>
> and pass a temporary:
>
> int rc = example( 1, 2, int(0) );
Unfortunately the cases where this comes up are often calls to
library functions whose interfaces cannot be changed.
>> This leads into what may be the most common case, where
>> what is needed is a pointer, but the value to be used
>> is an array. Here is some actual code written as part
>> of my test scaffolding for the strtoul() functions:
>
> Again, this would be problematic in C++, unless the object is
> const. So one could have:
>
> const int* y = std::begin({ 1, 2, 3 });
>
> or (useful if you really want the data in read only memory)
>
> constexpr const int* y = std::begin({ 1, 2, 3 });
This explains one difficulty I was having trying to find out
about how C++ might do this - I didn't know about std::begin.
Funny restriction (understandable, but still funny). It's sort
of sad that so much machinery (templates, library function,
etc) to get something that seems like it should be part of
the language proper. The absence of an explicit type for
the array elements is a drawback (or more accurately would
be in some cases), but I guess one could be supplied using
a static_cast around the std::begin() expression if that
were desired.
>> static TestSet trials = {{
>> (String[]){ "", 0 },
>> (String[]){ "", "+", "-", " ", " +", " -", 0 },
>> (String[]){ "", "0", "0x", "0X", 0 },
>> (int[]){ 0, 1, 2, 3, 4, 5, -1 },
>> (ULL[]){
>> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
>> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
>> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
>> 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
>> 100, 1000, 10000, 100000, 1000000, 10000000,
>> 100000000, 1000000000,
>> LONG_MAX-1, LONG_MAX, LONG_MAX+1ULL, LONG_MAX+2ULL,
>> ULONG_MAX-1, ULONG_MAX, ULONG_MAX+1ULL, ULONG_MAX+2ULL,
>> LLONG_MAX-1, LLONG_MAX, LLONG_MAX+1ULL, LLONG_MAX+2ULL,
>> ULLONG_MAX-1, ULLONG_MAX,
>> 0
>> },
>> (String[]){ "", "!", "0000", 0 },
>> }};
>>
>> It's necessary to use compound literals in the initializer (ie,
>> as opposed to using sub-initializers), because the structure
>> whose values are being filled in takes pointers, not arrays.
>
> This could be written with initialiser lists if the pointers were
> const (which in this case, is probably desirable!). Something
> like:
>
> struct TestSet
> {
> const String* s1;
> const String* s2;
> const String* s3;
> const int* i;
> const uint64_t* ull;
> const String* s4;
> };
I have to object on this one. If I had wanted to make the
pointers be pointers to const (somethings) then I would made them
that way. To me this indicates a shortcoming in language design.
>> Of course, all of these (including arguments to function calls,
>> which matter in the C context) can be re-written so as not to
>> use compound literals. But the code that results is decidedly
>> clunkier.
>
> True enough. I guess in practical use cases the significant
> differences between compound literals and initialiser lists are
> the ability to use anonymous types with the former and whether
> the resulting object is an lvalue or an rvalue
I would add: compound literals are a little bit safer (in
cases where casting is the alternative), and more generally
available - that is, a compound literal is just one kind of
expression, and is usable anywhere an expression is, whereas
initializer lists are wired into various scattered places in
the extra-expression syntax rules.
Also, not to beat a dead horse, but compound literals are
available in C, and the "uniform initialization" constructs
that C++ has are not. I'm not asking C++ folks to embrace
using compound literals, only that the language make them
available to make the two languages more interoperable.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-19 15:59 +1200 |
| Message-ID | <cpgnh6Fl1o8U8@mid.individual.net> |
| In reply to | #60360 |
Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Tim Rentsch wrote:
>>> This leads into what may be the most common case, where
>>> what is needed is a pointer, but the value to be used
>>> is an array. Here is some actual code written as part
>>> of my test scaffolding for the strtoul() functions:
>>
>> Again, this would be problematic in C++, unless the object is
>> const. So one could have:
>>
>> const int* y = std::begin({ 1, 2, 3 });
>>
>> or (useful if you really want the data in read only memory)
>>
>> constexpr const int* y = std::begin({ 1, 2, 3 });
>
> This explains one difficulty I was having trying to find out
> about how C++ might do this - I didn't know about std::begin.
> Funny restriction (understandable, but still funny). It's sort
> of sad that so much machinery (templates, library function,
> etc) to get something that seems like it should be part of
> the language proper.
I agree to a point. Uniform initialisation will undoubtedly be enhanced
in later standards (there already are improvements in C++14). The
initialiser list syntax is part of the language proper, with exiting
language mechanisms utilised to make it work for on-code objects.
The real advantages from a C++ programmer's perspective derive from the
"uniform" part of uniform initialisation. Being able to use the same
syntax to initialise an array and a standard container is a bit plus.
It enables compound literal like syntax where a function parameter is a
container, for example s function like
foo( std::vector<int> );
can be called with
foo( {1,2,3,4} );
> The absence of an explicit type for
> the array elements is a drawback (or more accurately would
> be in some cases), but I guess one could be supplied using
> a static_cast around the std::begin() expression if that
> were desired.
That is somewhat messy as well.. An explicit initialiser list would
have to be used. But if this were C++ code, the idiomatic solution
would be to have an object with a constructor.
>>> static TestSet trials = {{
>>> (String[]){ "", 0 },
>>> (String[]){ "", "+", "-", " ", " +", " -", 0 },
>>> (String[]){ "", "0", "0x", "0X", 0 },
>>> (int[]){ 0, 1, 2, 3, 4, 5, -1 },
>>> (ULL[]){
>>> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
>>> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
>>> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
>>> 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
>>> 100, 1000, 10000, 100000, 1000000, 10000000,
>>> 100000000, 1000000000,
>>> LONG_MAX-1, LONG_MAX, LONG_MAX+1ULL, LONG_MAX+2ULL,
>>> ULONG_MAX-1, ULONG_MAX, ULONG_MAX+1ULL, ULONG_MAX+2ULL,
>>> LLONG_MAX-1, LLONG_MAX, LLONG_MAX+1ULL, LLONG_MAX+2ULL,
>>> ULLONG_MAX-1, ULLONG_MAX,
>>> 0
>>> },
>>> (String[]){ "", "!", "0000", 0 },
>>> }};
>>>
>>> It's necessary to use compound literals in the initializer (ie,
>>> as opposed to using sub-initializers), because the structure
>>> whose values are being filled in takes pointers, not arrays.
>>
>> This could be written with initialiser lists if the pointers were
>> const (which in this case, is probably desirable!). Something
>> like:
>>
>> struct TestSet
>> {
>> const String* s1;
>> const String* s2;
>> const String* s3;
>> const int* i;
>> const uint64_t* ull;
>> const String* s4;
>> };
>
> I have to object on this one. If I had wanted to make the
> pointers be pointers to const (somethings) then I would made them
> that way. To me this indicates a shortcoming in language design.
More of an lvalue/rvalue difference.
> Also, not to beat a dead horse, but compound literals are
> available in C, and the "uniform initialization" constructs
> that C++ has are not. I'm not asking C++ folks to embrace
> using compound literals, only that the language make them
> available to make the two languages more interoperable.
While a desirable outcome, I doubt it would happen now C++ has added
uniform initialisation the possibility of ambiguities would be too
great. I'm sure before C++11 the case could (and probably was) made,
but the C++ community was looking for something with broader scope - a
common syntax for initialisation of built in and user defined types.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 14:04 -0700 |
| Message-ID | <kfnzj5zswlz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60362 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> Tim Rentsch wrote:
>>>
>>>> This leads into what may be the most common case, where
>>>> what is needed is a pointer, but the value to be used
>>>> is an array. Here is some actual code written as part
>>>> of my test scaffolding for the strtoul() functions:
>>>
>>> Again, this would be problematic in C++, unless the object is
>>> const. So one could have:
>>>
>>> const int* y = std::begin({ 1, 2, 3 });
>>>
>>> or (useful if you really want the data in read only memory)
>>>
>>> constexpr const int* y = std::begin({ 1, 2, 3 });
>>
>> This explains one difficulty I was having trying to find out
>> about how C++ might do this - I didn't know about std::begin.
>> Funny restriction (understandable, but still funny). It's sort
>> of sad that so much machinery (templates, library function,
>> etc) to get something that seems like it should be part of
>> the language proper.
>
> I agree to a point. Uniform initialisation will undoubtedly be
> enhanced in later standards (there already are improvements in
> C++14). The initialiser list syntax is part of the language
> proper, with exiting language mechanisms utilised to make it work
> for on-code objects.
>
> The real advantages from a C++ programmer's perspective derive
> from the "uniform" part of uniform initialisation. Being able to
> use the same syntax to initialise an array and a standard
> container is a bit plus. It enables compound literal like syntax
> where a function parameter is a container, for example s function
> like
>
> foo( std::vector<int> );
>
> can be called with
>
> foo( {1,2,3,4} );
I think we are mostly in agreement here, except I want to expand
on the "compound literal like" modifier, about which more below.
>> The absence of an explicit type for
>> the array elements is a drawback (or more accurately would
>> be in some cases), but I guess one could be supplied using
>> a static_cast around the std::begin() expression if that
>> were desired.
>
> That is somewhat messy as well.. An explicit initialiser list
> would have to be used. But if this were C++ code, the idiomatic
> solution would be to have an object with a constructor.
That doesn't let me do what I want (assuming I understand what
kinds of things C++ allows constructing, which may be different
than my previous understanding), because what I want is an
array, not a class/struct instance.
>>>> static TestSet trials = {{
>>>> (String[]){ "", 0 },
>>>> (String[]){ "", "+", "-", " ", " +", " -", 0 },
>>>> (String[]){ "", "0", "0x", "0X", 0 },
>>>> (int[]){ 0, 1, 2, 3, 4, 5, -1 },
>>>> (ULL[]){
>>>> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
>>>> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
>>>> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
>>>> 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
>>>> 100, 1000, 10000, 100000, 1000000, 10000000,
>>>> 100000000, 1000000000,
>>>> LONG_MAX-1, LONG_MAX, LONG_MAX+1ULL, LONG_MAX+2ULL,
>>>> ULONG_MAX-1, ULONG_MAX, ULONG_MAX+1ULL, ULONG_MAX+2ULL,
>>>> LLONG_MAX-1, LLONG_MAX, LLONG_MAX+1ULL, LLONG_MAX+2ULL,
>>>> ULLONG_MAX-1, ULLONG_MAX,
>>>> 0
>>>> },
>>>> (String[]){ "", "!", "0000", 0 },
>>>> }};
>>>>
>>>> It's necessary to use compound literals in the initializer (ie,
>>>> as opposed to using sub-initializers), because the structure
>>>> whose values are being filled in takes pointers, not arrays.
>>>
>>> This could be written with initialiser lists if the pointers were
>>> const (which in this case, is probably desirable!). Something
>>> like:
>>>
>>> struct TestSet
>>> {
>>> const String* s1;
>>> const String* s2;
>>> const String* s3;
>>> const int* i;
>>> const uint64_t* ull;
>>> const String* s4;
>>> };
>>
>> I have to object on this one. If I had wanted to make the
>> pointers be pointers to const (somethings) then I would made them
>> that way. To me this indicates a shortcoming in language design.
>
> More of an lvalue/rvalue difference.
I don't understand the point you are trying to make here. I
should be able to write an expression whose value is a
constructed value of any type the language supports, including
structs whose members are pointers to non-const elements. If C++
can't do that, it seems reasonable to label the lack as a
shortcoming in language design. Do you disagree with that?
>> Also, not to beat a dead horse, but compound literals are
>> available in C, and the "uniform initialization" constructs
>> that C++ has are not. I'm not asking C++ folks to embrace
>> using compound literals, only that the language make them
>> available to make the two languages more interoperable.
>
> While a desirable outcome, I doubt it would happen now C++ has
> added uniform initialisation the possibility of ambiguities would
> be too great.
I agree that it's unlikely that it will happen, but I don't
see any technical reason that it shouldn't happen. What
ambiguities? AFAICS there aren't any ambiguities, because
the respective syntaxes are disjoint.
> I'm sure before C++11 the case could (and probably
> was) made, but the C++ community was looking for something with
> broader scope - a common syntax for initialisation of built in and
> user defined types.
I suggest that this view isn't quite right. What they were (and
are) looking for is slightly different - to be able to construct
a value without having to know exactly what type is needed.
There is an element of polymorphism, or perhaps type inference,
in the uniform initialization constructs. There is none in
compound literals - the type must be completely specified (not
counting the extent for array types, which is well-established in
C). The two notions serve different purposes. For constructing
values of class/struct type, C++ has constructors. The point of
compound literals is to be able to write an expression that can
yield a value of any type, certainly including structs, but also
including all other types that C supports. This isn't what
uniform initialization does - what it does do is allow omitting
the type in certain contexts, because those contexts have (or
maybe "can have" is more accurate, I'm not sure) enough
information from other sources to be able to supply (or guess, or
deduce, or infer, whatever) the missing type information. And I
agree that this kind of capability is valuable - I am a strong
proponent of type inference (if done well, I guess I might add),
and uniform initialization is a step in that direction. But I
don't think uniform initialization is "broader" or "better" than
compound literals - it's just different.
Also, to flog that dead horse once again, the reason for the
suggestion is not to improve C++ but just to make it easier to
transition between the two languages. As long as compound
literals don't interfere with C++ and its evolution, that should
be enough to satisfy the C++ committee. AFAICT there is not such
interference. Can you find a counterexample to that? In this
regard, any statement like "in such-and-such case it would be be
better to use a C++ initializer list" doesn't qualify as a
counterexample; to do that there needs to be some degree of
actual conflict on a technical level, since otherwise the test is
essentially meaningless.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-19 16:52 +1200 |
| Message-ID | <cpgqkdFl1o8U9@mid.individual.net> |
| In reply to | #60290 |
Stefan Ram wrote:
> Newsgroups: comp.lang.c,comp.lang.c++
>
> Ian Collins <ian-news@hotmail.com> writes:
>> Again, this would be problematic in C++, unless the object is const. So
>> one could have:
>> const int* y = std::begin({ 1, 2, 3 });
>
> What is this? { 1, 2, 3 } seems to be used to initialize a
> temporary object whose lifetimes ends at the semicolon, so
> the pointer y then would be dangling?
It's an initialiser list. To quote cplusplus.com:
"initializer_list objects are automatically constructed as if an array
of elements of type T was allocated, with each of the elements in the
list being copy-initialized to its corresponding element in the array,
using any necessary non-narrowing implicit conversions."
So while the object is a temporary, the data it references is not. Note
that the return type of std::begin() is a const T* (constexpr in C++14).
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2015-04-19 09:27 -0500 |
| Message-ID | <XnsA481B18816568myfirstnameosapriee@216.196.109.131> |
| In reply to | #60365 |
Ian Collins <ian-news@hotmail.com> wrote in
news:cpgqkdFl1o8U9@mid.individual.net:
> Stefan Ram wrote:
>> Newsgroups: comp.lang.c,comp.lang.c++
>>
>> Ian Collins <ian-news@hotmail.com> writes:
>>> Again, this would be problematic in C++, unless the object is const.
>>> So one could have:
>>> const int* y = std::begin({ 1, 2, 3 });
>>
>> What is this? { 1, 2, 3 } seems to be used to initialize a
>> temporary object whose lifetimes ends at the semicolon, so
>> the pointer y then would be dangling?
>
> It's an initialiser list. To quote cplusplus.com:
>
> "initializer_list objects are automatically constructed as if an array
> of elements of type T was allocated, with each of the elements in the
> list being copy-initialized to its corresponding element in the array,
> using any necessary non-narrowing implicit conversions."
>
> So while the object is a temporary, the data it references is not.
There is no data object the y pointer could point to. 1 is a rvalue whose
address cannot be taken, and any other objects constructed from it and
initialized to 1 are not guaranteed to be alive.
Quoting from cppreference.com: "The underlying array is a temporary
array, in which each element is copy-initialized (except that narrowing
conversions are invalid) from the corresponding element of the original
initializer list. The lifetime of the underlying array is the same as any
other temporary object [...]"
So, as the array is temporary, a pointer to its element can and will
become dangling as far as I can see.
Cheers
Paavo
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-15 23:04 -0700 |
| Message-ID | <kfn618w1udy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59322 |
Ian Collins <ian-news@hotmail.com> writes: I have to amend my last comments. You posted two example, one of which was C++ and one of which was in a C/C++ common subset. My orginal []'ed summary was right, but I mistakenly thought it applied to your second example. It's a minor point but I feel obliged to correct it.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-03-31 00:14 -0700 |
| Message-ID | <MPG.2f83e91ba3bac49c13@news.eternal-september.org> |
| In reply to | #59301 |
Tim Rentsch wrote: > > Ian Collins <ian-news@hotmail.com> writes: > > > Tim Rentsch wrote: > >> Ian Collins <ian-news@hotmail.com> writes: > >> > >>> Tim Rentsch wrote: > >>> > >>>> By the way, I'll give you another item for your list, which is > >>>> compound literals. I find compound literals extremely useful, > >>>> and would not want to give them up. (Disclaimer: I believe that > >>>> C++ does not support compound literals, but I haven't really > >>>> followed what's going on with C++ features, especially lately.) > >>> > >>> C++ does not support compound literals, but in most use cases > >>> initialiser lists fulfill the same role. [snip elaboration] > >> > >> This assertion is not even remotely right. Of course you can > >> use an initializer list when you have a declared identifier > >> to initialize. The whole point of compound literals is not > >> to have to need such a declared identifier, and that's when > >> compound literals are used. > > > > I'm either being dense, or we are completely misunderstanding each > > other. Are you referring to a case like [snip example of how to > > re-write a C fragment in C++]: > > I guess you weren't completely paying attention earlier. What > was being discussed is what parts of C are (or are not) legal > C++, not how to re-write C code in C++. The claim is that almost > all C (programs or lines of code, it was ambiguous which) is also > legal C++. Compound literals is a counter-example to that. Use > cases in C++ are irrelevant to the question; it is use cases in > C that matter. I guess you weren't paying attention. Ian said that C++ initializer lists serve the same role as C compound initializers. You *incorrectly* disagreed with that, and then when he defended the point, you said, well, that's not the topic under discussion. You're right, it's not the topic under discussion, but it's still true, and your statement "This assertion is not even remotely right" is not even remotely right.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-16 00:18 -0700 |
| Message-ID | <kfn4mog1qxz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59333 |
Philip Lantz <prl@canterey.us> writes: > Tim Rentsch wrote: > >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> By the way, I'll give you another item for your list, which is >>>>>> compound literals. I find compound literals extremely useful, >>>>>> and would not want to give them up. (Disclaimer: I believe >>>>>> that C++ does not support compound literals, but I haven't >>>>>> really followed what's going on with C++ features, especially >>>>>> lately.) >>>>> >>>>> C++ does not support compound literals, but in most use cases >>>>> initialiser lists fulfill the same role. [snip elaboration] >>>> >>>> This assertion is not even remotely right. Of course you can >>>> use an initializer list when you have a declared identifier >>>> to initialize. The whole point of compound literals is not >>>> to have to need such a declared identifier, and that's when >>>> compound literals are used. >>> >>> I'm either being dense, or we are completely misunderstanding >>> each other. Are you referring to a case like [snip example of >>> how to re-write a C fragment in C++]: >> >> I guess you weren't completely paying attention earlier. What >> was being discussed is what parts of C are (or are not) legal >> C++, not how to re-write C code in C++. The claim is that almost >> all C (programs or lines of code, it was ambiguous which) is also >> legal C++. Compound literals is a counter-example to that. Use >> cases in C++ are irrelevant to the question; it is use cases in >> C that matter. > > I guess you weren't paying attention. If you mean I didn't notice what may have been a subtle and unannounced change of subject, that's true. I didn't. However I think that is understandable since (a) I had already posted two prior messages on the existing subject, and (b) this is after all comp.lang.c -- it is reasonable to expect that the subject will be about programming in C, not C++, unless that is made clear at the outset. > Ian said that C++ initializer lists serve the same role as C > compound initializers. No, he didn't. Read the quoted message above. What he did say is that "in most use cases initialiser lists fulfill the same role." First off, "initializer lists" is unqualified, so it is natural to take this as meaning C initializer lists, not C++ initializer lists (which have different rules). Second, even if we take this phrase as meaning C++ initializer lists, they certainly do not address my use cases, which involve programming in C, not in C++, so C++ initilizer lists are not available. > You *incorrectly* disagreed with that, and then when he defended > the point, you said, well, that's not the topic under discussion. > You're right, it's not the topic under discussion, but it's still > true, and your statement "This assertion is not even remotely > right" is not even remotely right. Read the quoted message again. My objection to what he actually wrote, rather than what you think he wrote, is correct.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2015-01-17 10:33 -0800 |
| Message-ID | <2b1d1665-dcf7-4c75-9252-841842341194@googlegroups.com> |
| In reply to | #56380 |
Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: > On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: > > > > I have a hard time parsing your question, but C++ tends to be faster > > than C. > > > I find that hard to believe. > If performance is overwhelming important, then of course it's hard to > be extremely optimised C. If there has to be a trade-off between > performance and ease of coding, C++ templates can be faster than > the C equivalent of passing void *s about. The main advantage of C++, > as far as I can see, is that it makes it easier to use a balanced > binary search tree (called a set for some reason). > > However C++ makes it much harder to keep track of how > many cycles you are using. Another thing. If you are doing the type of programming where you care how many cycles are being used, then yeah, C++ is probably not for your projects. But for most programming projects you don't care how many cycles are used.
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-01-17 20:03 +0000 |
| Message-ID | <6ezuw.309723$_R5.85382@fx28.iad> |
| In reply to | #56382 |
On 2015-01-17, wssimms@gmail.com <wssimms@gmail.com> wrote: > Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: >> On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: >> > >> > I have a hard time parsing your question, but C++ tends to be faster >> > than C. >> > >> I find that hard to believe. >> If performance is overwhelming important, then of course it's hard to >> be extremely optimised C. If there has to be a trade-off between >> performance and ease of coding, C++ templates can be faster than >> the C equivalent of passing void *s about. The main advantage of C++, >> as far as I can see, is that it makes it easier to use a balanced >> binary search tree (called a set for some reason). >> >> However C++ makes it much harder to keep track of how >> many cycles you are using. > > Another thing. If you are doing the type of programming where you care > how many cycles are being used, then yeah, C++ is probably not for your > projects. But for most programming projects you don't care how many > cycles are used. The number of cysles usedd is directly porportional to the efficiency of the code - which was the question - so in this case the number of cycles does matter. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 11:07 +0100 |
| Message-ID | <m9ikv6$h00$1@dont-email.me> |
| In reply to | #56391 |
On 17/01/15 21:03, Greg Martin wrote: > On 2015-01-17, wssimms@gmail.com <wssimms@gmail.com> wrote: >> Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: >>> On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: >>>> >>>> I have a hard time parsing your question, but C++ tends to be faster >>>> than C. >>>> >>> I find that hard to believe. >>> If performance is overwhelming important, then of course it's hard to >>> be extremely optimised C. If there has to be a trade-off between >>> performance and ease of coding, C++ templates can be faster than >>> the C equivalent of passing void *s about. The main advantage of C++, >>> as far as I can see, is that it makes it easier to use a balanced >>> binary search tree (called a set for some reason). >>> >>> However C++ makes it much harder to keep track of how >>> many cycles you are using. >> >> Another thing. If you are doing the type of programming where you care >> how many cycles are being used, then yeah, C++ is probably not for your >> projects. But for most programming projects you don't care how many >> cycles are used. > > The number of cysles usedd is directly porportional to the efficiency of > the code - which was the question - so in this case the number of cycles > does matter. > There are many types of "cycles" - processor clock cycles, instructions executed per second, memory bus cycles, single-core speed, multi-core speed, ticks on the wall clock. And there are many types of efficiency - run-time speed, power, processor saturation, wall-clock time, etc. Sometimes code that uses more processor cycles but less memory cycles will be much faster than one that uses more memory to save processor cycles. If you are trying to count cycles on a modern "big" processor, you have almost certainly misunderstood the problem. As others have said, real-world profiling with real-world data on real-world targets is the only way to get proper information.
[toc] | [prev] | [next] | [standalone]
| From | wpihughes@gmail.com |
|---|---|
| Date | 2015-01-26 13:30 -0800 |
| Message-ID | <9f399a99-cc28-4ea4-bc84-43ed8b6fc9e6@googlegroups.com> |
| In reply to | #56391 |
On Saturday, January 17, 2015 at 4:03:21 PM UTC-4, Greg Martin wrote: > used. > > The number of cysles usedd is directly porportional to the efficiency of > the code Neither in theory nor practice. If the bottleneck is memory access it might be worth a *LOT* of cycles to speed up memory access (e.g. by doing few overall accesses or by improving locality) -William Hughes
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-01-18 16:36 +1300 |
| Message-ID | <ci0o2dFgs9mU1@mid.individual.net> |
| In reply to | #56380 |
Malcolm McLean wrote: > On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: >> >> I have a hard time parsing your question, but C++ tends to be faster >> than C. >> > I find that hard to believe. > If performance is overwhelming important, then of course it's hard to > be extremely optimised C. If there has to be a trade-off between > performance and ease of coding, C++ templates can be faster than > the C equivalent of passing void *s about. The main advantage of C++, > as far as I can see, is that it makes it easier to use a balanced > binary search tree (called a set for some reason). > > However C++ makes it more tempting to use inefficient data representations, > and do unnecessary copying and dynamic memory allocation, also run > unnecessary bounds checking. It much harder to keep track of how > many cycles you are using, because C++ does more work without being > explicitly told. You can't fool a profiler! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-17 19:02 +0000 |
| Message-ID | <m9ebji$22b$1@speranza.aioe.org> |
| In reply to | #56368 |
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > On Sat, 2015-01-10, fir wrote: >> there are some languages that are low level like c [...] I mean some >> languages that could teoretically compete with c in efficiency.. do >> maybe some of such language some solution that make the outcome >> program to be faster (or equally speed but with different solution) >> comparing to c? > I have a hard time parsing your question, but C++ tends to be faster > than C. Why would that be? > Plenty of other languages are faster, in specialized cases. If you use the fancier features of any language, usually that allow for less work by the programmer, they often have more run-time overhead. A simpler language requires more work by the programmer, and often runs faster as a result. -- glen
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web