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 205 — 34 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 Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:33 +1300
Re: faster than c Philip Lantz <prl@canterey.us> - 2015-03-31 00:14 -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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-25 21:22 +0100 |
| Message-ID | <mev5bo$8u6$1@dont-email.me> |
| In reply to | #58952 |
On 25/03/15 20:45, Malcolm McLean wrote: > On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: >> >> (BTW I think the "well-written" qualifier is just weaseling, >> since you could arbitrarily limit "well-written" code to be only >> that code that is also legal C++. To give the statement any >> meaning there must be an independent definition of what >> "well-written" means, or better yet choose another qualifier that >> can be measured objectively.) >> > Stuff like implict int, functions without prototypes, functions > called with arguments of a different type to that declared in > the argument list, ignoring of const qualifiers, assignment of > pointer variables to ints and back, all examples of things C > supports for backwards compatibility. > That's the sort of thing I was thinking of - C++ is a lot stricter about that kind of detail (although of course newer C standards are also stricter than the old ones). But I am happy to accept that "almost all" was an overstatement, and consider "most" as a better choice of vague pseudo-quantification. And I didn't specify whether I was talking about "almost all programs written in C", "almost all C program lines", or any other definition of what I was vaguely quantifying. The whole point of the claim was to show that C is very rarely going to let you write code that is faster than the equivalent C++ code - because the C code is already valid C++ code, or it can easily be massaged into being valid C++ code. Missing features (like designated initialisers, VLAs, etc.) may mean the C++ source code is a little bulkier, but it is unlikely to change the speed of the generated object code significantly. And most since most modern compilers handle C and C++, and generate approximately the same results when the source code is valid as C and as C++, the conclusion has to be that for most practical purposes, C code is not going to be faster than C++ code.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 16:30 -0700 |
| Message-ID | <kfn1tkcac3z.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58957 |
David Brown <david.brown@hesbynett.no> writes: > On 25/03/15 20:45, Malcolm McLean wrote: >> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: >> >>> (BTW I think the "well-written" qualifier is just weaseling, >>> since you could arbitrarily limit "well-written" code to be only >>> that code that is also legal C++. To give the statement any >>> meaning there must be an independent definition of what >>> "well-written" means, or better yet choose another qualifier that >>> can be measured objectively.) >> >> Stuff like implict int, functions without prototypes, functions >> called with arguments of a different type to that declared in >> the argument list, ignoring of const qualifiers, assignment of >> pointer variables to ints and back, all examples of things C >> supports for backwards compatibility. > > That's the sort of thing I was thinking of - C++ is a lot stricter > about that kind of detail (although of course newer C standards are > also stricter than the old ones). > > But I am happy to accept that "almost all" was an overstatement, and > consider "most" as a better choice of vague pseudo-quantification. > And I didn't specify whether I was talking about "almost all > programs written in C", "almost all C program lines", or any other > definition of what I was vaguely quantifying. > > The whole point of the claim was to show that C is very rarely > going to let you write code that is faster than the equivalent C++ > code - because the C code is already valid C++ code, or it can > easily be massaged into being valid C++ code. Missing features > (like designated initialisers, VLAs, etc.) may mean the C++ source > code is a little bulkier, but it is unlikely to change the speed > of the generated object code significantly. And most since most > modern compilers handle C and C++, and generate approximately the > same results when the source code is valid as C and as C++, the > conclusion has to be that for most practical purposes, C code is > not going to be faster than C++ code. Does C++ have 'restrict'? If C++ does not have 'restrict', then there are lots of cases where a C compiler can generate better code than C++ could. In fact I ran into such a case just the other day (depressing but true).
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-26 00:50 +0100 |
| Message-ID | <20150326005004.414f690c@maxa-pc> |
| In reply to | #58984 |
On Wed, 25 Mar 2015 16:30:56 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > David Brown <david.brown@hesbynett.no> writes: > > > On 25/03/15 20:45, Malcolm McLean wrote: > >> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: > >> > >>> (BTW I think the "well-written" qualifier is just weaseling, > >>> since you could arbitrarily limit "well-written" code to be only > >>> that code that is also legal C++. To give the statement any > >>> meaning there must be an independent definition of what > >>> "well-written" means, or better yet choose another qualifier that > >>> can be measured objectively.) > >> > >> Stuff like implict int, functions without prototypes, functions > >> called with arguments of a different type to that declared in > >> the argument list, ignoring of const qualifiers, assignment of > >> pointer variables to ints and back, all examples of things C > >> supports for backwards compatibility. > > > > That's the sort of thing I was thinking of - C++ is a lot stricter > > about that kind of detail (although of course newer C standards are > > also stricter than the old ones). > > > > But I am happy to accept that "almost all" was an overstatement, and > > consider "most" as a better choice of vague pseudo-quantification. > > And I didn't specify whether I was talking about "almost all > > programs written in C", "almost all C program lines", or any other > > definition of what I was vaguely quantifying. > > > > The whole point of the claim was to show that C is very rarely > > going to let you write code that is faster than the equivalent C++ > > code - because the C code is already valid C++ code, or it can > > easily be massaged into being valid C++ code. Missing features > > (like designated initialisers, VLAs, etc.) may mean the C++ source > > code is a little bulkier, but it is unlikely to change the speed > > of the generated object code significantly. And most since most > > modern compilers handle C and C++, and generate approximately the > > same results when the source code is valid as C and as C++, the > > conclusion has to be that for most practical purposes, C code is > > not going to be faster than C++ code. > > Does C++ have 'restrict'? No. If C++ does not have 'restrict', then > there are lots of cases where a C compiler can generate better > code than C++ could. Show one case. Same compiler C with restrict and without restrict. Show performance difference. In fact I ran into such a case just the > other day (depressing but true). I would be interesting too see ;)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-28 09:20 -0700 |
| Message-ID | <kfny4mh6ql1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58989 |
Melzzzzz <mel@zzzzz.com> writes:
> On Wed, 25 Mar 2015 16:30:56 -0700
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>[snip]
>
>> Does C++ have 'restrict'? If C++ does not have 'restrict', then
>> there are lots of cases where a C compiler can generate better
>> code than C++ could.
>
> Show one case. Same compiler C with restrict and without restrict.
> Show performance difference.
I posted one the other day in the "Packing algorithm" thread
Here is the code:
int
amount_unpacked( int amount, int n, const int sizes[], int out[] ){
// sizes[] array in order of largest to smallest
int i;
for( i = 0; i < n; i++ ){
out[i] = amount / sizes[i];
amount %= sizes[i];
}
return amount;
}
Using a -S option to gcc, the generated code can be seen to
be better if 'restrict' is used on the last two arguments.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-26 00:55 +0100 |
| Message-ID | <mevhs5$357$1@dont-email.me> |
| In reply to | #58984 |
On 26/03/15 00:30, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 25/03/15 20:45, Malcolm McLean wrote: >>> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: >>> >>>> (BTW I think the "well-written" qualifier is just weaseling, >>>> since you could arbitrarily limit "well-written" code to be only >>>> that code that is also legal C++. To give the statement any >>>> meaning there must be an independent definition of what >>>> "well-written" means, or better yet choose another qualifier that >>>> can be measured objectively.) >>> >>> Stuff like implict int, functions without prototypes, functions >>> called with arguments of a different type to that declared in >>> the argument list, ignoring of const qualifiers, assignment of >>> pointer variables to ints and back, all examples of things C >>> supports for backwards compatibility. >> >> That's the sort of thing I was thinking of - C++ is a lot stricter >> about that kind of detail (although of course newer C standards are >> also stricter than the old ones). >> >> But I am happy to accept that "almost all" was an overstatement, and >> consider "most" as a better choice of vague pseudo-quantification. >> And I didn't specify whether I was talking about "almost all >> programs written in C", "almost all C program lines", or any other >> definition of what I was vaguely quantifying. >> >> The whole point of the claim was to show that C is very rarely >> going to let you write code that is faster than the equivalent C++ >> code - because the C code is already valid C++ code, or it can >> easily be massaged into being valid C++ code. Missing features >> (like designated initialisers, VLAs, etc.) may mean the C++ source >> code is a little bulkier, but it is unlikely to change the speed >> of the generated object code significantly. And most since most >> modern compilers handle C and C++, and generate approximately the >> same results when the source code is valid as C and as C++, the >> conclusion has to be that for most practical purposes, C code is >> not going to be faster than C++ code. > > Does C++ have 'restrict'? If C++ does not have 'restrict', then > there are lots of cases where a C compiler can generate better > code than C++ could. In fact I ran into such a case just the > other day (depressing but true). > Good point - C++ does not have "restrict", and that could make a difference. In many cases, I think you could make messy code changes to make code that disallows aliasing by changing types as a workaround for missing "restrict". Many (most?) C++ compilers have a "__restrict__" extension that does the same job as C99 "restrict", but that is not standard C++.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-26 01:06 +0100 |
| Message-ID | <20150326010636.720cbe5d@maxa-pc> |
| In reply to | #58990 |
On Thu, 26 Mar 2015 00:55:36 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 26/03/15 00:30, Tim Rentsch wrote: > > David Brown <david.brown@hesbynett.no> writes: > > > >> On 25/03/15 20:45, Malcolm McLean wrote: > >>> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: > >>> > >>>> (BTW I think the "well-written" qualifier is just weaseling, > >>>> since you could arbitrarily limit "well-written" code to be only > >>>> that code that is also legal C++. To give the statement any > >>>> meaning there must be an independent definition of what > >>>> "well-written" means, or better yet choose another qualifier that > >>>> can be measured objectively.) > >>> > >>> Stuff like implict int, functions without prototypes, functions > >>> called with arguments of a different type to that declared in > >>> the argument list, ignoring of const qualifiers, assignment of > >>> pointer variables to ints and back, all examples of things C > >>> supports for backwards compatibility. > >> > >> That's the sort of thing I was thinking of - C++ is a lot stricter > >> about that kind of detail (although of course newer C standards are > >> also stricter than the old ones). > >> > >> But I am happy to accept that "almost all" was an overstatement, > >> and consider "most" as a better choice of vague > >> pseudo-quantification. And I didn't specify whether I was talking > >> about "almost all programs written in C", "almost all C program > >> lines", or any other definition of what I was vaguely quantifying. > >> > >> The whole point of the claim was to show that C is very rarely > >> going to let you write code that is faster than the equivalent C++ > >> code - because the C code is already valid C++ code, or it can > >> easily be massaged into being valid C++ code. Missing features > >> (like designated initialisers, VLAs, etc.) may mean the C++ source > >> code is a little bulkier, but it is unlikely to change the speed > >> of the generated object code significantly. And most since most > >> modern compilers handle C and C++, and generate approximately the > >> same results when the source code is valid as C and as C++, the > >> conclusion has to be that for most practical purposes, C code is > >> not going to be faster than C++ code. > > > > Does C++ have 'restrict'? If C++ does not have 'restrict', then > > there are lots of cases where a C compiler can generate better > > code than C++ could. In fact I ran into such a case just the > > other day (depressing but true). > > > > Good point - C++ does not have "restrict", and that could make a > difference. In many cases, I think you could make messy code changes > to make code that disallows aliasing by changing types as a > workaround for missing "restrict". > > Many (most?) C++ compilers have a "__restrict__" extension that does > the same job as C99 "restrict", but that is not standard C++. > gcc has also local functions extension for C but not for C++.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-26 11:34 +0100 |
| Message-ID | <mf0n9g$ka0$1@dont-email.me> |
| In reply to | #58991 |
On 26/03/15 01:06, Melzzzzz wrote: > On Thu, 26 Mar 2015 00:55:36 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/03/15 00:30, Tim Rentsch wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 25/03/15 20:45, Malcolm McLean wrote: >>>>> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: >>>>> >>>>>> (BTW I think the "well-written" qualifier is just weaseling, >>>>>> since you could arbitrarily limit "well-written" code to be only >>>>>> that code that is also legal C++. To give the statement any >>>>>> meaning there must be an independent definition of what >>>>>> "well-written" means, or better yet choose another qualifier that >>>>>> can be measured objectively.) >>>>> >>>>> Stuff like implict int, functions without prototypes, functions >>>>> called with arguments of a different type to that declared in >>>>> the argument list, ignoring of const qualifiers, assignment of >>>>> pointer variables to ints and back, all examples of things C >>>>> supports for backwards compatibility. >>>> >>>> That's the sort of thing I was thinking of - C++ is a lot stricter >>>> about that kind of detail (although of course newer C standards are >>>> also stricter than the old ones). >>>> >>>> But I am happy to accept that "almost all" was an overstatement, >>>> and consider "most" as a better choice of vague >>>> pseudo-quantification. And I didn't specify whether I was talking >>>> about "almost all programs written in C", "almost all C program >>>> lines", or any other definition of what I was vaguely quantifying. >>>> >>>> The whole point of the claim was to show that C is very rarely >>>> going to let you write code that is faster than the equivalent C++ >>>> code - because the C code is already valid C++ code, or it can >>>> easily be massaged into being valid C++ code. Missing features >>>> (like designated initialisers, VLAs, etc.) may mean the C++ source >>>> code is a little bulkier, but it is unlikely to change the speed >>>> of the generated object code significantly. And most since most >>>> modern compilers handle C and C++, and generate approximately the >>>> same results when the source code is valid as C and as C++, the >>>> conclusion has to be that for most practical purposes, C code is >>>> not going to be faster than C++ code. >>> >>> Does C++ have 'restrict'? If C++ does not have 'restrict', then >>> there are lots of cases where a C compiler can generate better >>> code than C++ could. In fact I ran into such a case just the >>> other day (depressing but true). >>> >> >> Good point - C++ does not have "restrict", and that could make a >> difference. In many cases, I think you could make messy code changes >> to make code that disallows aliasing by changing types as a >> workaround for missing "restrict". >> >> Many (most?) C++ compilers have a "__restrict__" extension that does >> the same job as C99 "restrict", but that is not standard C++. >> > > gcc has also local functions extension for C but not for C++. > gcc has a number of extensions that are only for C and not C++ (as well as several extensions the improve the compatibility between the languages), but the primary focus here is for standard C and C++ - or at least extensions like "__restrict__" that are common to many C++ compilers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-25 20:29 -0700 |
| Message-ID | <87wq24o2qn.fsf@kst-u.example.com> |
| In reply to | #58984 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Does C++ have 'restrict'?
No.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 16:34 -0700 |
| Message-ID | <kfnwq248xcy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58952 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: > >> (BTW I think the "well-written" qualifier is just weaseling, >> since you could arbitrarily limit "well-written" code to be only >> that code that is also legal C++. To give the statement any >> meaning there must be an independent definition of what >> "well-written" means, or better yet choose another qualifier that >> can be measured objectively.) > > Stuff like implict int, functions without prototypes, functions > called with arguments of a different type to that declared in > the argument list, ignoring of const qualifiers, assignment of > pointer variables to ints and back, all examples of things C > supports for backwards compatibility. IMO all of those are reasonable candidates for the "not well-written" category (modulo filtering for accuracy). My objection is not about there being a filter but that the implied filter is not well-defined. And just giving examples will never do that.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-26 13:53 +1300 |
| Message-ID | <cnh3kcF7rh0U1@mid.individual.net> |
| In reply to | #58950 |
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. Using the examples from the
gcc docs
(https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Compound-Literals.html), the
following is a C++ translation:
struct foo {int a; char b[2];} structure;
structure = {42, 'a', 0};
int y[] = { 1, 2, 3 };
Note this is a cut and paste removing the casts.
char **foo = (char *[]) { "x", "y", "z" };
has to be written as
const char* foo[] = { "x", "y", "z" };
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-28 15:08 -0700 |
| Message-ID | <kfnzj6w6ahb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58994 |
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. It makes no sense to say you can put in the very declared identifer we don't want to be there in the first place, so as not to need the compound literal. That's silly! That's why compound literals were added to C, and that is (almost exclusively) when and why they are used.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 11:28 +1300 |
| Message-ID | <cnoo7pFoba2U7@mid.individual.net> |
| In reply to | #59174 |
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:
typedef struct { int x, y; } Point;
void f( Point p ) {}
f( (Point){1,2} );
?
If so, the C++ equivalent (using an initialiser list) would be
f( {1,2} );
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-30 12:42 -0700 |
| Message-ID | <kfnr3s646hc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59178 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-30 20:06 +0000 |
| Message-ID | <20150330124434.593@kylheku.com> |
| In reply to | #59301 |
On 2015-03-30, Tim Rentsch <txr@alumni.caltech.edu> 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.
In the case of compound literals, I believe that macros could bridge the
gap, so it is not a real impediment toward developing the code with
either a C or C++ compiler.
I use a similar approach to obtain the benefits of C++ casts like static_cast
and const_cast in C code. The casts are wrapped in macros which generate
C++ casts when compiled as C++, and C casts otherwise.
Suppose compound literals are hidden behind a macro call:
foo x = foo_init(a, b, c);
Where the C code uses a compound literal, a macro call could be used instead
which also works in C++. In C, foo_init expands to:
foo x = ((foo) { .x = (a), .y = (b), .z = (c) });
In C++, it could expand to a straight constructor call:
foo x = foo(a, b, c);
So while, of course, the point stands that C code with naked compound literals
isn't C++, there is a way to make it C++ compatible without radically altering
its design.
The result is in fact an improvement. Suppose that foo acquires a new member
called w which *must* be initialized to some nonzero value. We can add a
fourth argument to the macro, and the compiler will diagnose all places where
only three arguments are supplied, so we can hunt them down and fix them.
Or we can default w in the expansion foo_init macro, and add a new macro that
has four arguments for when a nondefault value of w must be used.
By contrast, the compiler will not diagnose places where we are missing
a .w = expr initialiation in the bare initializer.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-31 16:37 +1300 |
| Message-ID | <cnuj38Fm7ngU2@mid.individual.net> |
| In reply to | #59306 |
Kaz Kylheku wrote:
>
> In the case of compound literals, I believe that macros could bridge the
> gap, so it is not a real impediment toward developing the code with
> either a C or C++ compiler.
>
> I use a similar approach to obtain the benefits of C++ casts like static_cast
> and const_cast in C code. The casts are wrapped in macros which generate
> C++ casts when compiled as C++, and C casts otherwise.
>
> Suppose compound literals are hidden behind a macro call:
>
> foo x = foo_init(a, b, c);
>
> Where the C code uses a compound literal, a macro call could be used instead
> which also works in C++. In C, foo_init expands to:
>
> foo x = ((foo) { .x = (a), .y = (b), .z = (c) });
>
> In C++, it could expand to a straight constructor call:
>
> foo x = foo(a, b, c);
>
> So while, of course, the point stands that C code with naked compound literals
> isn't C++, there is a way to make it C++ compatible without radically altering
> its design.
The there some confusion here between compound literal and designated
initialisers?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-31 05:13 +0000 |
| Message-ID | <20150330221118.458@kylheku.com> |
| In reply to | #59323 |
On 2015-03-31, Ian Collins <ian-news@hotmail.com> wrote:
> Kaz Kylheku wrote:
>>
>> In the case of compound literals, I believe that macros could bridge the
>> gap, so it is not a real impediment toward developing the code with
>> either a C or C++ compiler.
>>
>> I use a similar approach to obtain the benefits of C++ casts like static_cast
>> and const_cast in C code. The casts are wrapped in macros which generate
>> C++ casts when compiled as C++, and C casts otherwise.
>>
>> Suppose compound literals are hidden behind a macro call:
>>
>> foo x = foo_init(a, b, c);
>>
>> Where the C code uses a compound literal, a macro call could be used instead
>> which also works in C++. In C, foo_init expands to:
>>
>> foo x = ((foo) { .x = (a), .y = (b), .z = (c) });
>>
>> In C++, it could expand to a straight constructor call:
>>
>> foo x = foo(a, b, c);
>>
>> So while, of course, the point stands that C code with naked compound literals
>> isn't C++, there is a way to make it C++ compatible without radically altering
>> its design.
>
> The there some confusion here between compound literal and designated
> initialisers?
No. Compound literals support designated initializers. This is of secondary;
the main point is about compound literals. I just happened to use designated
initializers in the example. (More than just happened; the example also
illustrates a side point: that compoundl literals with designated initializers
still benefit from being wrapped in a functional abstraction.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-31 16:33 +1300 |
| Message-ID | <cnuit6Fm7ngU1@mid.individual.net> |
| 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. Hang on, I was paying attention. You wrote "I find compound literals extremely useful, and would not want to give them up" and I made an apparently misguided attempt to show you how initialiser lists fulfill much the same role. Do you disagree that the last example I posted and you snipped does this? -- Ian Collins
[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 | 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]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web