Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73070 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-10-16 13:29 -0700 |
| Last post | 2015-10-16 20:45 -0700 |
| Articles | 20 on this page of 168 — 20 participants |
Back to article view | Back to comp.lang.c
C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 13:29 -0700
Re: C struct syntax allowance by usage Siri Cruz <chine.bleu@yahoo.com> - 2015-10-16 13:47 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 14:12 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-16 22:15 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 10:32 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 05:26 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 14:17 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 06:48 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 19:01 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 11:17 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 15:28 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 01:41 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 18:23 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:04 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 10:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:14 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:25 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 12:32 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:35 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 11:16 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:40 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 17:35 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 10:52 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 11:02 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 19:59 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 12:15 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:41 +0100
Likeliehood of RDC/SeaAlive implementation (Was: C struct syntax allowance by usage) gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-19 08:23 +0000
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:02 -0400
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:19 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 21:13 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 20:37 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:27 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 23:14 +0200
Re: C struct syntax allowance by usage asetofsymbols@gmail.com - 2015-10-18 15:09 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 16:11 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 07:57 +1300
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:11 +0100
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 09:19 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:19 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 03:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:52 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 05:39 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 14:57 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 10:31 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 15:49 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:53 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 01:50 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 02:28 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 12:38 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 12:09 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:26 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 13:34 +0100
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:36 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 05:09 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:41 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 06:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 15:20 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 08:24 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 08:43 +1300
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 13:00 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 20:34 +0000
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 09:47 +1300
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-19 16:32 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 10:37 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 21:24 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 13:49 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-20 07:33 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:53 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:37 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:05 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:02 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 06:07 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 14:15 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 09:23 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 18:30 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 12:13 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 21:17 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 14:21 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-21 14:55 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:45 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:33 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 08:54 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-23 15:59 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:03 -0700
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:37 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 23:26 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:56 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:19 +0000
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 11:08 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:58 +0200
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:06 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 07:41 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 14:00 +0100
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 21:00 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 14:57 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 14:41 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 13:01 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 13:25 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 07:44 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:41 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:22 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-22 01:01 -0700
Re: C struct syntax allowance by usage Les Cargill <lcargill99@comcast.com> - 2015-10-22 08:00 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:49 -0400
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:40 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-20 11:55 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:11 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:47 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:32 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 10:08 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 21:45 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:09 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:22 -0400
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 17:49 -0700
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 21:13 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:36 +0000
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-22 20:18 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:55 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:14 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 09:09 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:31 +0000
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:17 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-11-10 10:39 -0800
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 11:02 -0800
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 15:54 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 13:51 -0700
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 17:41 -0400
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:32 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:17 -0700
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 16:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:51 +0000
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:01 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 12:38 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-24 13:56 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 15:17 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-25 13:47 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 23:46 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 07:05 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-25 10:59 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:24 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-25 11:13 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:58 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-24 11:02 -0700
Re: C struct syntax allowance by usage Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-10-24 20:13 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-24 12:45 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:30 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 12:05 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:57 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 00:54 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 17:19 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:33 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 19:41 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:58 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:10 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 16:49 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:59 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:32 +0200
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-16 23:15 -0400
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:34 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:45 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 15:38 -0700 |
| Message-ID | <7896f4ae-217a-4fb3-87d0-c0622c6ff448@googlegroups.com> |
| In reply to | #73104 |
On Friday, October 16, 2015 at 6:31:19 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Friday, October 16, 2015 at 6:14:41 PM UTC-4, Ian Collins wrote:
> >> Rick C. Hodgin wrote:
> >>> Does C++ offer this ability? FWIW, I've never heard of it before.
> >>> If it does, that's great.
> >>
> >> With a little help from the programmer....
> >>
> >> struct Foo
> >> {
> >> int i;
> >> double f;
> >>
> >> Foo& operator=( int v ) { i = v; return *this; }
> >> Foo& operator=( double v ) { f = v; return *this; }
> >> };
> >>
> >> int main()
> >> {
> >> Foo foo;
> >> foo = 42;
> >> foo = 21.21;
> >>
> >> printf( "%d %f\n", foo.i, foo.f );
> >
> > Still had to reference the member names here.
>
> As did your OP.
Untrue! :-) There were two line 14s in my OP. The first does not
require them, as the %d and %f align with values which the compiler
can know.
> 01: struct SAbc
> 02: {
> 03: int i;
> 04: float f;
> 05: };
> 06:
> 07: int main(int argc, char* argv[])
> 08: {
> 09: struct SAbc abc;
> 10:
> 11: abc = 5;
> 12: abc = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc, abc);
> 15: }
>
> Where the meaning of the above is actually understood by the
> language/compiler to be these members, because there is only
> one of each type in the structure:
>
> 11: abc.i = 5;
> 12: abc.f = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc.i, abc.f);
> >> return 0;
> >> }
> >
> > FWIW, I'd rather stop programming and become a farmer than inflict
> > that kind of syntax on all developers who would use my language,
> > and this ability.
> >
> > I do not use C++ for those very reasons. It might be a powerful
> > language and extension to C, offering things that are amazing ...
> > but it comes at steep price. It's also horrid on the eyes.
>
> If ugliness in one place leads to elegance in many, I'm all for it.
I would rather make the software have that ability through much
code that no one ever sees, than to require that type of code
someplace in a program, even if it then is easy to use everywhere
else.
We are past the age of mechanics. It's time to enter the general
age of elegance. It is the life cycle of the butterfly ... at
first they eat and consume and grow ... but at some point a
transformation takes place, and what emerges is not only truly
beautiful, but it also takes flight.
CAlive ... It will offer these extensions, and others that come
along as they make sense and are generally desired.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 12:32 +1300 |
| Message-ID | <d8dfovFp0vsU5@mid.individual.net> |
| In reply to | #73106 |
Rick C. Hodgin wrote: > On Friday, October 16, 2015 at 6:31:19 PM UTC-4, Ian Collins wrote: >> >> If ugliness in one place leads to elegance in many, I'm all for it. > > I would rather make the software have that ability through much > code that no one ever sees, than to require that type of code > someplace in a program, even if it then is easy to use everywhere > else. How often do you see the contents of a library header? They are the usual place to hide ugly code. > We are past the age of mechanics. It's time to enter the general > age of elegance. It is the life cycle of the butterfly ... at > first they eat and consume and grow ... but at some point a > transformation takes place, and what emerges is not only truly > beautiful, but it also takes flight. > > CAlive ... It will offer these extensions, and others that come > along as they make sense and are generally desired. I guess that's were we disagree on language philosophy. I prefer a language that provides the tools to add such extensions without having to update the language. Most of your proposed ideas can already be implemented, so I doubt wrapping them up in yet another language will gain much traction. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 11:35 +0200 |
| Message-ID | <mvvp1g$s89$2@dont-email.me> |
| In reply to | #73110 |
On 17/10/15 01:32, Ian Collins wrote: > I guess that's were we disagree on language philosophy. I prefer a > language that provides the tools to add such extensions without having > to update the language. Most of your proposed ideas can already be > implemented, so I doubt wrapping them up in yet another language will > gain much traction. > I think it is interesting that almost every time Rick comes up with an idea for another "extension" to his language, I get more convinced that C++ is the way forward!
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-18 11:16 +0100 |
| Message-ID | <mvvreq$4pk$1@dont-email.me> |
| In reply to | #73193 |
On 18/10/2015 10:35, David Brown wrote: > On 17/10/15 01:32, Ian Collins wrote: > >> I guess that's were we disagree on language philosophy. I prefer a >> language that provides the tools to add such extensions without having >> to update the language. Most of your proposed ideas can already be >> implemented, so I doubt wrapping them up in yet another language will >> gain much traction. >> > > I think it is interesting that almost every time Rick comes up with an > idea for another "extension" to his language, I get more convinced that > C++ is the way forward! Yes, C++ is a walking DIY compiler/language toolkit. It apparently can do pretty much anything you can dream up. That sounds good at first. Until you realise that Rick could actually implement his ideas using it (and other people could do the same with their even more oddball ones). If the implementation is then hidden away as has been suggested, what are people to then make of the baffling source code that will result? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 13:40 +0200 |
| Message-ID | <n000bm$kvb$1@dont-email.me> |
| In reply to | #73195 |
On 18/10/15 12:16, Bartc wrote: > On 18/10/2015 10:35, David Brown wrote: >> On 17/10/15 01:32, Ian Collins wrote: >> >>> I guess that's were we disagree on language philosophy. I prefer a >>> language that provides the tools to add such extensions without having >>> to update the language. Most of your proposed ideas can already be >>> implemented, so I doubt wrapping them up in yet another language will >>> gain much traction. >>> >> >> I think it is interesting that almost every time Rick comes up with an >> idea for another "extension" to his language, I get more convinced that >> C++ is the way forward! > > Yes, C++ is a walking DIY compiler/language toolkit. It apparently can > do pretty much anything you can dream up. That sounds good at first. > > Until you realise that Rick could actually implement his ideas using it > (and other people could do the same with their even more oddball ones). > 1. I have seen enough incomprehensible crap in C to know that C++ does not have a monopoly on bad code. Try looking at anything by Rosario193 for more than 30 seconds without going cross-eyed or getting a headache. 2. Just because C++ offers plenty of scope for writing incomprehensible crap, does not mean it is obligatory. One thing that C++ has a good deal more than C does is scope for code that is extremely difficult to understand, and yet does something very useful. Try understanding the implementation of tuple<>, for example - it is not for the faint of heart. But there is a very clear separation between implementation of such classes and templates, and their usage. You can /use/ tuples simply and easily, without having to understand how they work - writing such template classes is a specialist job. And when these things are seen to be useful, they get moved into the C++ standard library to be available to anyone who wants them. C has this too, of course, but it is not as visible to ordinary users. You can see some of it in the standard headers - they are often extremely difficult to comprehend because they are full of macros, compiler-specific extensions, etc., in order to be as efficient as possible or to help improve static error checking. But the real guts, in the library implementations, are far worse - look at the source code for newlib if you want a good example. > If the implementation is then hidden away as has been suggested, what > are people to then make of the baffling source code that will result? > People normally only need to look at the source code they write themselves - C++ does not change your source code.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-18 17:35 +0100 |
| Message-ID | <n00hk1$m73$1@dont-email.me> |
| In reply to | #73200 |
On 18/10/2015 12:40, David Brown wrote:
> On 18/10/15 12:16, Bartc wrote:
>> Yes, C++ is a walking DIY compiler/language toolkit. It apparently can
>> do pretty much anything you can dream up. That sounds good at first.
>>
>> Until you realise that Rick could actually implement his ideas using it
>> (and other people could do the same with their even more oddball ones).
>
> 1. I have seen enough incomprehensible crap in C to know that C++ does
> not have a monopoly on bad code. Try looking at anything by Rosario193
> for more than 30 seconds without going cross-eyed or getting a headache.
I wish Rosario's code was as bad as it gets! It's easy to convert those
Rs and Gs back to returns and gotos if necessary.
> 2. Just because C++ offers plenty of scope for writing incomprehensible
> crap, does not mean it is obligatory.
>Try understanding the implementation of tuple<>, for example -
> it is not for the faint of heart. But there is a very clear separation
> between implementation of such classes and templates, and their usage.
> You can /use/ tuples simply and easily, without having to understand how
> they work - writing such template classes is a specialist job.
Well, it's never going to be clear where the line is drawn between the
language and the user code. I've looked at some of the tuple stuff, and
as you predicted, I can't make head nor tail of it. But the same applies
to trying to use them!
What are we trying to do? If returning multiple values from a function,
in an easy language I might write:
return (x,y,z)
And to get to read those multiple values into separate variables, I can
write:
(a,b,c) = fn()
No tuples needed, or special bolt-on libraries that no-one comprehends;
just basic language features.
Now go back and look and how C++ does it. The above should be a starting
point for the ideal way of doing this; then we want the least painful
and most graceful way of making it possible in a statically typed language.
> C has this too, of course, but it is not as visible to ordinary users.
> You can see some of it in the standard headers - they are often
> extremely difficult to comprehend because they are full of macros,
> compiler-specific extensions, etc., in order to be as efficient as
> possible or to help improve static error checking. But the real guts,
> in the library implementations, are far worse - look at the source code
> for newlib if you want a good example.
The limiting factor for C is the language, which you can't change.
Eventually you can get the meaning of some code, unless it's
deliberately obfuscated, by working your way through and applying the rules.
That usually is not practical in C++, if it is necessary to fully
understand something (for the purposes, for example, of interfacing to
it from something that is not C++, not even C; or for understanding or
porting an algorithm expressed in C++).
>> If the implementation is then hidden away as has been suggested, what
>> are people to then make of the baffling source code that will result?
>>
>
> People normally only need to look at the source code they write
> themselves - C++ does not change your source code.
If I never had to look at anyone else's code, or use an API defined via
C++, then it wouldn't be so much of a problem. I don't care that other
people like to tie themselves up in knots.
But sometimes it is necessary to make use of other people's code, then
it really needs to be as plain as possible.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-18 10:52 -0700 |
| Message-ID | <87679697-62a0-4297-b7a9-ab6ff173fb77@googlegroups.com> |
| In reply to | #73211 |
On Sunday, October 18, 2015 at 11:35:27 AM UTC-5, Bart wrote:
> What are we trying to do? If returning multiple values from a function,
> in an easy language I might write:
>
> return (x,y,z)
>
> And to get to read those multiple values into separate variables, I can
> write:
>
> (a,b,c) = fn()
>
> No tuples needed, or special bolt-on libraries that no-one comprehends;
> just basic language features.
I find it curious that while the vast majority of hardware platforms which
are used to run C programs would make it easy for functions to support
primitive-type "in-out" and "output only" parameters more efficiently than
reference parameters, simply by having a caller read out the place where it
had either stored an argument (for in-out) or "stored" a dummy value (for
output only), and multi-value return types could easily be handled using
such a feature, very few languages provide it even when there could be
huge semantic benefit (e.g. the covariance support for .NET generics
would be much improved, since it's semantically possible for a method to
have covariant "out" parameters, but not covariant "ref" parameters).
I would think that even in the earliest days of C, before the advent of
prototypes, it would have been possible to have a function-call syntax
like:
foo(x, y return z);
to indicate that when "foo" returns, the argument into which y had been
stored should be read and copied into z. Once prototypes came on the
scene, a lot of functions would likely get optimized so that it would no
longer be possible for a caller to receive arguments that a called
function was not expecting to return to it, but on the other hand a
prototype would then be able to indicate which arguments would need to
be kept available to the calling function.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-18 11:02 -0700 |
| Message-ID | <47093620-5b8c-4d03-9544-dc2d1283070d@googlegroups.com> |
| In reply to | #73211 |
On Sunday, October 18, 2015 at 12:35:27 PM UTC-4, Bart wrote:
> What are we trying to do? If returning multiple values from a function,
> in an easy language I might write:
>
> return (x,y,z)
>
> And to get to read those multiple values into separate variables, I can
> write:
>
> (a,b,c) = fn()
>
> No tuples needed, or special bolt-on libraries that no-one comprehends;
> just basic language features.
CAlive allows for multiple return parameters, but the parenthesis are not
required:
int a, b, c;
a,b,c = fn();
function fn
| returns int r1, int r2, int r3
{
// Can return values using this:
return(1,2,3);
// Or this: (because return params can be used as local variables)
r1 = 1;
r2 = 2;
r3 = 3;
// No explicit return required
}
-----
CAlive also does this:
char* p1, p2, p3;
// p1, p2, p3 are all pointers because "char*" was touching,
// indicating the type was the full form "char*".
char *p4, c1, c2, *p5;
// p4 and p5 are pointers because the "*" was by them, but c1 and
// c2 are just char variables because they had no * by them.
-----
CAlive also doesn't abort when it encounters an error. It enters a
new thing called an "inquiry," which suspends execution if running
natively allowing a memory dump to be created, or it traps to the
debugger to allow the errant condition to be corrected, because CAlive
is a full edit-and-continue environment that I call "LiveCode".
Lots of features in CAlive that are new. They'll all be revealed in
the book in the coming weeks (Lord willing).
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-18 19:59 +0100 |
| Message-ID | <87k2qkm297.fsf@bsb.me.uk> |
| In reply to | #73219 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > CAlive allows for multiple return parameters, Is there an implementation now? Last time I asked I don't think there was even a language specification. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-18 12:15 -0700 |
| Message-ID | <22455c68-b5e5-4325-8ca0-a6e6004b82d0@googlegroups.com> |
| In reply to | #73225 |
On Sunday, October 18, 2015 at 2:59:42 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> > CAlive allows for multiple return parameters,
>
> Is there an implementation now?
No. I'm working on the assembly language parser at the current
time.
> Last time I asked I don't think there
> was even a language specification.
I pointed you to the specification at one point and you rejected it
as not being of any kind of proper form. It's all I've got, Ben,
other than the 20+ years of inertial thinking on how this language
should be implemented, along with the ongoing honing related to it
over time as new ideas surface, along with sign posts and guide posts
in my work over the years which all point to these features.
Here is the same concept conveyed in Visual FreePro's XBASE language
(called VXB++) from back in 2013:
http://www.visual-freepro.org/wiki/index.php/RETURNS
And in Visual FreePro, Jr.'s current implementation (search for
"multiple return parameters") in its language (called VXB):
http://www.visual-freepro.org/wiki/index.php/VXB
And here is support for it in Visual FreePro, Jr.'s current
implementation (search for "rp[_MAX_RETURN_COUNT];" in vjr_structs.h,
and "_MAX_RETURN_COUNT" in vjr_const.h):
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_structs.h
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_const.h
-----
My goals are CAlive for low-level programming, and VXB and VXB++ for
high level programming (VXB runs on native hardware, VXB++ runs in a
virtual machine). VXB++ is in a virtual machine as it conveys several
new features for advanced debugging:
http://www.visual-freepro.org/wiki/index.php/Enhanced_Debugging
o Horizontal debugging
o Breadcrumbs
o Hyper-Drops (allows visible 3D drop-downs into related information
when running under OpenGL)
o Pursues (allows computation to resources which must later be validated
before being accepted, and they can be rejected, allowing for "what if"
computational scenarios by only entering a type of pursue { } block.
o Codepoints (like breakpoints, but execute arbitrary code when hit)
o No-step-into functions (to allow step-into debugging which bypasses
things which don't need to be stepped into)
Some of these features will be in my RDC / CAlive debugger as well.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-18 21:41 +0100 |
| Message-ID | <87eggrnc4f.fsf@bsb.me.uk> |
| In reply to | #73227 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Sunday, October 18, 2015 at 2:59:42 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> <snip> >> > CAlive allows for multiple return parameters, >> >> Is there an implementation now? > > No. I'm working on the assembly language parser at the current > time. Ah, it was the present tense that threw me. >> Last time I asked I don't think there >> was even a language specification. > > I pointed you to the specification at one point and you rejected it > as not being of any kind of proper form. I'm sorry if that's how it came across. That sounds rather petty. I remember only being unable to understand it. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-10-19 08:23 +0000 |
| Subject | Likeliehood of RDC/SeaAlive implementation (Was: C struct syntax allowance by usage) |
| Message-ID | <n029an$huo$1@news.xmission.com> |
| In reply to | #73225 |
In article <87k2qkm297.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: ><snip> >> RDC^WCAlive allows for multiple return parameters, > >Is there an implementation now? Last time I asked ... No, and there probably never will be, given that the implementor is certain that we are all going to raptured any day now. I know that if I believed that, working on some new computer programming language would certainly be pretty low on *my* list of priorities. BTW, has comp.lang.rdc been newgrouped yet? -- "Although written many years ago, Lady Chatterley's Lover has just been reissued by the Grove Press, and this fictional account of the day-to-day life of an English gamekeeper is still of considerable interest to outdoor minded readers, as it contains many passages on pheasant raising, the apprehending of poachers, ways to control vermin, and other chores and duties of the professional gamekeeper. "Unfortunately, one is obliged to wade through many pages of extraneous material in order to discover and savor these sidelights on the management of a Midlands shooting estate, and in this reviewer's opinion this book cannot take the place of J.R. Miller's Practical Gamekeeping" (Ed Zern, Field and Stream, November 1959, p. 142).
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-10-18 14:02 -0400 |
| Message-ID | <N8RUx.47542$Ue1.24869@fx29.iad> |
| In reply to | #73211 |
On Sunday October 18 2015 12:35, in comp.lang.c, "Bartc" <bc@freeuk.com>
wrote:
[snip]
> What are we trying to do? If returning multiple values from a function,
> in an easy language I might write:
>
> return (x,y,z)
>
> And to get to read those multiple values into separate variables, I can
> write:
>
> (a,b,c) = fn()
>
> No tuples needed, or special bolt-on libraries that no-one comprehends;
> just basic language features.
Snap! That's an interesting idea. I like it.
But, I'd make one (minor) alteration: I'd use brace brackets instead of
parenthesis. As in:
return {x,y,z};
and
{a,b,c} = fn();
As for /why/, brace brackets already "frame" array element initializations, so
the idea of manipulating multiple values enclosed in braces is already part
of the language.
[snip]
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-10-18 14:19 -0400 |
| Message-ID | <BoRUx.74541$JC.11844@fx11.iad> |
| In reply to | #73220 |
On Sunday October 18 2015 14:02, in comp.lang.c, "Lew Pitcher"
<lew.pitcher@digitalfreehold.ca> wrote:
> On Sunday October 18 2015 12:35, in comp.lang.c, "Bartc" <bc@freeuk.com>
> wrote:
> [snip]
>> What are we trying to do? If returning multiple values from a function,
>> in an easy language I might write:
>>
>> return (x,y,z)
>>
>> And to get to read those multiple values into separate variables, I can
>> write:
>>
>> (a,b,c) = fn()
>>
>> No tuples needed, or special bolt-on libraries that no-one comprehends;
>> just basic language features.
>
> Snap! That's an interesting idea. I like it.
>
> But, I'd make one (minor) alteration: I'd use brace brackets instead of
> parenthesis. As in:
> return {x,y,z};
> and
> {a,b,c} = fn();
>
> As for /why/, brace brackets already "frame" array element initializations,
> so the idea of manipulating multiple values enclosed in braces is already
> part of the language.
The only issue would be one of how do you define or declare the /function/
that returns a tuple.
I'd suggest a brace-wrapped <<declaration-list>>-like construct in place of
the simple declaration-specifier of a function with a single return value.
Something like
{ int, char *, float } fn(void);
or
{ int, char *, float } fn(void) { return {10,"this is a test",3.14159}; }
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-18 21:13 +0100 |
| Message-ID | <n00uco$adr$1@dont-email.me> |
| In reply to | #73221 |
On 18/10/2015 19:19, Lew Pitcher wrote:
> On Sunday October 18 2015 14:02, in comp.lang.c, "Lew Pitcher"
> <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Sunday October 18 2015 12:35, in comp.lang.c, "Bartc" <bc@freeuk.com>
>> wrote:
>>> return (x,y,z)
>>>
>>> And to get to read those multiple values into separate variables, I can
>>> write:
>>>
>>> (a,b,c) = fn()
>> Snap! That's an interesting idea. I like it.
> The only issue would be one of how do you define or declare the /function/
> that returns a tuple.
> I'd suggest a brace-wrapped <<declaration-list>>-like construct in place of
> the simple declaration-specifier of a function with a single return value.
> Something like
> { int, char *, float } fn(void);
>
> or
> { int, char *, float } fn(void) { return {10,"this is a test",3.14159}; }
If you're going to declare the list of return types, C already has the
struct syntax for that. Actually, sticking 'struct' in front of your
examples (and add an extra ";") I think gives you legal C code.
You then just need a snappier way of denoting a compound literal,
although you can also just return a struct variable.
This is all possible now. (The scope of that return struct declaration
might cause problems.)
A new feature would be to expand a struct on the right side of an
assignment, to multiple values on the left.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 20:37 +0200 |
| Message-ID | <n00opo$k88$1@dont-email.me> |
| In reply to | #73211 |
On 18/10/15 18:35, Bartc wrote:
> On 18/10/2015 12:40, David Brown wrote:
>> On 18/10/15 12:16, Bartc wrote:
>
>>> Yes, C++ is a walking DIY compiler/language toolkit. It apparently can
>>> do pretty much anything you can dream up. That sounds good at first.
>>>
>>> Until you realise that Rick could actually implement his ideas using it
>>> (and other people could do the same with their even more oddball ones).
>>
>> 1. I have seen enough incomprehensible crap in C to know that C++ does
>> not have a monopoly on bad code. Try looking at anything by Rosario193
>> for more than 30 seconds without going cross-eyed or getting a headache.
>
> I wish Rosario's code was as bad as it gets! It's easy to convert those
> Rs and Gs back to returns and gotos if necessary.
>
Yes, it's far from the worst code around, but it's a familiar example -
and he manages to get an extraordinary amount of illegibility into a
very small space.
>> 2. Just because C++ offers plenty of scope for writing incomprehensible
>> crap, does not mean it is obligatory.
>
>> Try understanding the implementation of tuple<>, for example -
>> it is not for the faint of heart. But there is a very clear separation
>> between implementation of such classes and templates, and their usage.
>> You can /use/ tuples simply and easily, without having to understand how
>> they work - writing such template classes is a specialist job.
>
> Well, it's never going to be clear where the line is drawn between the
> language and the user code. I've looked at some of the tuple stuff, and
> as you predicted, I can't make head nor tail of it. But the same applies
> to trying to use them!
>
> What are we trying to do? If returning multiple values from a function,
> in an easy language I might write:
>
> return (x,y,z)
>
> And to get to read those multiple values into separate variables, I can
> write:
>
> (a,b,c) = fn()
>
> No tuples needed, or special bolt-on libraries that no-one comprehends;
> just basic language features.
using std::make_tuple;
using std::tie;
using std::get;
auto powers(double x) {
return make_tuple(1, x, x * x, x * x * x);
}
auto sumPowers(double x) {
auto res = powers(x);
double a, b, c, d;
tie(a, b, c, d) = res;
return a + b + c + d;
}
or
auto sumPowers2(double x) {
auto res = powers(x);
return get<0>(res) + get<1>(res) + get<2>(res) + get<3>(res);
}
Is it as neat and compact as Python? No, but it's not bad. It is not
too difficult to understand, nor too verbose. It could certainly be
improved (I think there should be some way to make a, b, c, and d "auto"
without having to use get<>). It is not that much different from the
standard C:
struct tuple4 { double a, b, c, d; };
struct tuple4 cpowers(double x) {
return (struct tuple4) { 1.0, x, x*x, x*x*x };
}
double csumPowers(double x) {
struct tuple4 t = cpowers(x);
return t.a + t.b + t.c + t.d;
}
The difference is that the struct is created on the fly, rather than
having to be pre-declared - and that can be a scalability feature.
The key point is that Python-style multiple return values requires
tuples to be a first-class type of object in the language, and that is
very far from being a simple change to the language. If one were to
make a new language from scratch, it is certainly a feature that should
be considered - but /adding/ it to an existing language is complex
(though definitely feasible). However, implementing this sort of thing
as a template class is straightforward - C++ is designed to be
extensible using such templates, rather than changing the language on a
regular basis. (For comparison, Python has such things as language
features - and look at the compatibility problems they see for every new
version of Python.)
I am not arguing that C++ is perfect, merely that it is quite good - and
the ease with which major features, such as tuples, can be added to the
language and used by programmers is an example of that strength. You
don't need to be able to understand the implementation of such features
- just their usage.
>
> Now go back and look and how C++ does it. The above should be a starting
> point for the ideal way of doing this; then we want the least painful
> and most graceful way of making it possible in a statically typed language.
>
>> C has this too, of course, but it is not as visible to ordinary users.
>> You can see some of it in the standard headers - they are often
>> extremely difficult to comprehend because they are full of macros,
>> compiler-specific extensions, etc., in order to be as efficient as
>> possible or to help improve static error checking. But the real guts,
>> in the library implementations, are far worse - look at the source code
>> for newlib if you want a good example.
>
> The limiting factor for C is the language, which you can't change.
> Eventually you can get the meaning of some code, unless it's
> deliberately obfuscated, by working your way through and applying the
> rules.
>
> That usually is not practical in C++, if it is necessary to fully
> understand something (for the purposes, for example, of interfacing to
> it from something that is not C++, not even C; or for understanding or
> porting an algorithm expressed in C++).
C++ is a bigger language, and has a bigger library - it takes more
knowledge and experience to understand it to the same depths as you
might understand C. But the same applies if you use C along with large
libraries - just because you can read the C code, does not mean you can
easily understand what it does or how it works.
>
>>> If the implementation is then hidden away as has been suggested, what
>>> are people to then make of the baffling source code that will result?
>>>
>>
>> People normally only need to look at the source code they write
>> themselves - C++ does not change your source code.
>
> If I never had to look at anyone else's code, or use an API defined via
> C++, then it wouldn't be so much of a problem. I don't care that other
> people like to tie themselves up in knots.
>
> But sometimes it is necessary to make use of other people's code, then
> it really needs to be as plain as possible.
>
I've just spend months trying to understand and bug-fix a C program
written by other people. It's the programmer, and the development
style, that makes code comprehensible or incomprehensible. It is not
the programming language.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-18 20:27 +0100 |
| Message-ID | <n00rmv$vmk$1@dont-email.me> |
| In reply to | #73223 |
On 18/10/2015 19:37, David Brown wrote:
> On 18/10/15 18:35, Bartc wrote:
>> If returning multiple values from a function,
>> in an easy language I might write:
>>
>> return (x,y,z)
>>
>> And to get to read those multiple values into separate variables, I can
>> write:
>>
>> (a,b,c) = fn()
>>
>> No tuples needed, or special bolt-on libraries that no-one comprehends;
>> just basic language features.
>
> using std::make_tuple;
> using std::tie;
> using std::get;
>
> auto powers(double x) {
> return make_tuple(1, x, x * x, x * x * x);
> }
What happens with multiple returns within the function; do they all have
to be compatible? I can see that 'auto' could have its work cut out!
(And what /is/ the return type from your example?)
>
> auto sumPowers(double x) {
> auto res = powers(x);
> double a, b, c, d;
> tie(a, b, c, d) = res;
> return a + b + c + d;
> }
>
> or
>
> auto sumPowers2(double x) {
> auto res = powers(x);
> return get<0>(res) + get<1>(res) + get<2>(res) + get<3>(res);
The C scores here because struct access is clearer. (C++ can use structs
too but tuples will be more tempting.)
>> But sometimes it is necessary to make use of other people's code, then
>> it really needs to be as plain as possible.
>>
>
> I've just spend months trying to understand and bug-fix a C program
> written by other people. It's the programmer, and the development
> style, that makes code comprehensible or incomprehensible. It is not
> the programming language.
It's factor; at least with C I'd have a sporting chance.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 23:14 +0200 |
| Message-ID | <n01201$nj7$1@dont-email.me> |
| In reply to | #73228 |
On 18/10/15 21:27, Bartc wrote:
> On 18/10/2015 19:37, David Brown wrote:
>> On 18/10/15 18:35, Bartc wrote:
>
>>> If returning multiple values from a function,
>>> in an easy language I might write:
>>>
>>> return (x,y,z)
>>>
>>> And to get to read those multiple values into separate variables, I can
>>> write:
>>>
>>> (a,b,c) = fn()
>>>
>>> No tuples needed, or special bolt-on libraries that no-one comprehends;
>>> just basic language features.
>>
>> using std::make_tuple;
>> using std::tie;
>> using std::get;
>>
>> auto powers(double x) {
>> return make_tuple(1, x, x * x, x * x * x);
>> }
>
> What happens with multiple returns within the function; do they all have
> to be compatible? I can see that 'auto' could have its work cut out!
Multiple returns are allowed as long as the return types are the same.
(Note that this is a C++14 feature.)
>
> (And what /is/ the return type from your example?)
std::tuple<int, double, double, double>
(Since I used "1" instead of "1.0".)
Using "auto" just saves a bit of typing here. For some use, it can save
a /lot/ of typing (and increase clarity), especially when the real type
is a messier template instantiation. In other cases, it is almost
essential - it makes template programming a good deal easier and
clearer. And some types - such as lambdas - can't really be written any
other way.
Basically, you use "auto" to save telling the compiler about types it
can easily figure out anyway.
>
>>
>> auto sumPowers(double x) {
>> auto res = powers(x);
>> double a, b, c, d;
>> tie(a, b, c, d) = res;
>> return a + b + c + d;
>> }
>>
>> or
>>
>> auto sumPowers2(double x) {
>> auto res = powers(x);
>> return get<0>(res) + get<1>(res) + get<2>(res) + get<3>(res);
>
> The C scores here because struct access is clearer. (C++ can use structs
> too but tuples will be more tempting.)
The C code is fine here - and I don't disagree that it is clearer in
this case. Just because tuples exist, does not mean you have to use
them. I was merely trying to show you that using tuples is not
particularly difficult.
There will be other cases where the convenience of making up the tuple
at the time, rather than having a separate struct definition, will be
more convenient despite the somewhat ugly get<x> syntax. (I wonder if
it would have been possible to name the tuple elements automatically, so
that you could write "return res.e0 + res.e1 + res.e2 + res.e3" ?)
>
>>> But sometimes it is necessary to make use of other people's code, then
>>> it really needs to be as plain as possible.
>>>
>>
>> I've just spend months trying to understand and bug-fix a C program
>> written by other people. It's the programmer, and the development
>> style, that makes code comprehensible or incomprehensible. It is not
>> the programming language.
>
> It's factor; at least with C I'd have a sporting chance.
>
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-10-18 15:09 -0700 |
| Message-ID | <b262bf02-816f-460b-8f7d-9dd51dfa7a78@googlegroups.com> |
| In reply to | #73228 |
Multiple return can be done in C, efficiently in this way: int function(returnType* rtn, etc) In the return pointer Possibly better than other language that for this could use malloc-free memory...
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-18 16:11 -0700 |
| Message-ID | <8909704f-b30b-4be8-a7eb-00b874d499f8@googlegroups.com> |
| In reply to | #73243 |
On Sunday, October 18, 2015 at 5:10:03 PM UTC-5, asetof...@gmail.com wrote:
> Multiple return can be done in C, efficiently in this way:
> int function(returnType* rtn, etc)
A major weakness of that approach is that given:
void blah(whatever)
{
returnType foo;
func1(&foo, whatever);
for (int i=0; i<foo.something; i++)
func2(whatever);
}
the only way for a compiler or optimizer to know whether foo.something
may be safely kept in a register across the call to func2 would be to
examine the code for func1 and/or func2. If, by contrast, func1 had
been written to return a value of returnType, then given:
void blah(whatever)
{
returnType foo;
foo=func1(whatever);
for (int i=0; i<foo.something; i++)
func2(whatever);
}
a compiler could infer that any or all fields of foo could safely be cached
in registers across the call to func2, without having to examine any
outside code, there would be no way outside code could possibly have
acquired foo's address.
Even in cases where structure-type returns are handled by passing a pointer
to the place where the returned structure should go as a hidden parameter,
called functions are forbidden from keeping a copy of that pointer. There
is no other mechanism for passing a pointer which a compiler could be
entitled to assume the recipient couldn't keep.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web