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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-19 07:57 +1300 |
| Message-ID | <d8i8d1FrihmU4@mid.individual.net> |
| In reply to | #73211 |
Bartc wrote: > On 18/10/2015 12:40, David Brown wrote: > >> 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. There you see the difference between your thinking and the C++ more abstract way of thinking. C++ adds a construct (in this case, variadic templates) to the language that enables library writers and programmers to implement a range of new features. Giving programmers the tools to create their own features has always been the philosophy at the heart of C++. Most programmers don't have the time to create new languages, but they do write libraries. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-18 20:11 +0100 |
| Message-ID | <n00qor$s8c$1@dont-email.me> |
| In reply to | #73224 |
On 18/10/2015 19:57, Ian Collins wrote: > Bartc 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. > > There you see the difference between your thinking and the C++ more > abstract way of thinking. C++ adds a construct (in this case, variadic > templates) to the language that enables library writers and programmers > to implement a range of new features. Giving programmers the tools to > create their own features has always been the philosophy at the heart of > C++. So how does it actually work? I mean, in terms of native language features. Because there must be a start point in the language where things just work instead of needing a library to implement them in terms of simpler primitives. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-19 09:19 +1300 |
| Message-ID | <d8id68Fge23U1@mid.individual.net> |
| In reply to | #73226 |
Bartc wrote: > On 18/10/2015 19:57, Ian Collins wrote: >> Bartc 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. >> >> There you see the difference between your thinking and the C++ more >> abstract way of thinking. C++ adds a construct (in this case, variadic >> templates) to the language that enables library writers and programmers >> to implement a range of new features. Giving programmers the tools to >> create their own features has always been the philosophy at the heart of >> C++. > > So how does it actually work? I guess the obvious example is complex numbers. The C++ philosophy that user defined types should behave as built in types enables Complex to be a class rather that having to update the language to add it (as C did). > I mean, in terms of native language features. Because there must be a > start point in the language where things just work instead of needing a > library to implement them in terms of simpler primitives. I guess the fundamental glue is templates and operator overloading. You can't mimic operator overloading in user code, but once it is part of the language you can build types that behave like built in ones. With these tools it is relatively easy to build constructs such as associative arrays that need to be native in other languages. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 11:19 +0200 |
| Message-ID | <mvvo2o$pct$1@dont-email.me> |
| In reply to | #73099 |
On 17/10/15 00:25, 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.
>
>> return 0;
>> }
Add these to the struct definition:
operator int() const { return i; }
operator double() const { return f; }
Then you can use:
printf("%d %f\n", (int) foo, (double) foo);
The printf format string is part of the C library, not the C (or C++)
language - the compiler can't know foo should be turned into or treated
as an "int" or "double" just because the format string says so.
But if you had a function that took an int parameter, you could happily
call it with "foo" - the compiler would use the value of foo.i.
>
> 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.
This code is not difficult - you quickly get used to it when doing C++
programming. There is lots of potential for /really/ ugly and
incomprehensible code in C++, but it usually gets hidden away in
libraries or templates somewhere, and "normal" programmers don't have to
understand the details. (The same applies in C with some hairy macros,
or implementation of functions like "printf".)
Beauty is in the eye of the beholder, of course. You think your "casks"
are clear and elegant - to other people it looks like your cat walked
across your keyboard. It is fair enough to reject C++ for whatever
reasons you want - but don't pretend it is for good, technical reasons
until you have used it enough to be familiar with its basics.
>
> 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.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-18 03:08 -0700 |
| Message-ID | <f13812b4-2057-48e8-9892-4ec10b351385@googlegroups.com> |
| In reply to | #73191 |
On Sunday, October 18, 2015 at 10:19:30 AM UTC+1, David Brown wrote: > > Beauty is in the eye of the beholder, of course. You think your "casks" > are clear and elegant - to other people it looks like your cat walked > across your keyboard. It is fair enough to reject C++ for whatever > reasons you want - but don't pretend it is for good, technical reasons > until you have used it enough to be familiar with its basics. > You can't expect someone to spend much time on your language before dismissing it as hard to use, uninterpretable, and so on. Admittedly where a language has a large user base, like C++, you should maybe be more careful before making too sweeping a judgement. But the fact that everyone keeps going back to C to derive new languages tell you all you really need to know.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 13:52 +0200 |
| Message-ID | <n0011a$nll$1@dont-email.me> |
| In reply to | #73194 |
On 18/10/15 12:08, Malcolm McLean wrote: > On Sunday, October 18, 2015 at 10:19:30 AM UTC+1, David Brown wrote: >> >> Beauty is in the eye of the beholder, of course. You think your "casks" >> are clear and elegant - to other people it looks like your cat walked >> across your keyboard. It is fair enough to reject C++ for whatever >> reasons you want - but don't pretend it is for good, technical reasons >> until you have used it enough to be familiar with its basics. >> > You can't expect someone to spend much time on your language before > dismissing it as hard to use, uninterpretable, and so on. > Admittedly where a language has a large user base, like C++, you should > maybe be more careful before making too sweeping a judgement. But > the fact that everyone keeps going back to C to derive new languages > tell you all you really need to know. > What exactly is that fact (assuming, without proof, that it /is/ a fact) supposed to tell me? At best, it tells me that if you want to create a new language, then it makes sense to start with something roughly like C to provide a base. That is pretty obvious - C is well-known, and it is a fairly basic imperative programming language. Almost any language that supports imperative programming will therefore have a sublanguage that is roughly isomorphic to C. It does not mean that C is always the best starting point - but it makes little difference to anything but the syntactic details if you choose Pascal or another imperative language as a starting point. On the other hand, object models can have a great deal of variation, as can techniques for metaprogramming and generic programming. C++ would only be a useful starting point if you wanted to copy the same models there, and that is unlikely (as you would probably be better off with a library for C++). Of course, languages like Java and C# copied a good deal of C++ syntax for similar features.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-18 05:39 -0700 |
| Message-ID | <5e7749c6-82d7-48b8-9dc6-3afb8e8d61a1@googlegroups.com> |
| In reply to | #73201 |
On Sunday, October 18, 2015 at 12:52:19 PM UTC+1, David Brown wrote: > On 18/10/15 12:08, Malcolm McLean wrote: > > > You can't expect someone to spend much time on your language before > > dismissing it as hard to use, uninterpretable, and so on. > > Admittedly where a language has a large user base, like C++, you should > > maybe be more careful before making too sweeping a judgement. But > > the fact that everyone keeps going back to C to derive new languages > > tell you all you really need to know. > > > > What exactly is that fact (assuming, without proof, that it /is/ a fact) > supposed to tell me? > > At best, it tells me that if you want to create a new language, then it > makes sense to start with something roughly like C to provide a base. > That is pretty obvious - C is well-known, and it is a fairly basic > imperative programming language. Almost any language that supports > imperative programming will therefore have a sublanguage that is roughly > isomorphic to C. It does not mean that C is always the best starting > point - but it makes little difference to anything but the syntactic > details if you choose Pascal or another imperative language as a > starting point. > > On the other hand, object models can have a great deal of variation, as > can techniques for metaprogramming and generic programming. C++ would > only be a useful starting point if you wanted to copy the same models > there, and that is unlikely (as you would probably be better off with a > library for C++). Of course, languages like Java and C# copied a good > deal of C++ syntax for similar features. > The other languages haven't really achieved acceptance. Plenty of people use C++, but there isn't a consensus that C++ is the best way to extend C to include objects. Both Apple and Microsoft, the two largest players, instead created their own sets of extensions to C, and tried to push development in that direction. Whilst there was an element of business and market positioning, there were also technical reasons. The exception is Javascript. But it's accepted purely as web page programming language, an environment in which a standards committee has quite a bit of power. I'm actually using a Javascript variant for non-web programming, but it's just that, a variant. It wasn't considered important to implement the full Javascript spec exactly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 14:57 +0200 |
| Message-ID | <n004rk$5om$1@dont-email.me> |
| In reply to | #73203 |
On 18/10/15 14:39, Malcolm McLean wrote: > On Sunday, October 18, 2015 at 12:52:19 PM UTC+1, David Brown wrote: >> On 18/10/15 12:08, Malcolm McLean wrote: >> >>> You can't expect someone to spend much time on your language before >>> dismissing it as hard to use, uninterpretable, and so on. >>> Admittedly where a language has a large user base, like C++, you should >>> maybe be more careful before making too sweeping a judgement. But >>> the fact that everyone keeps going back to C to derive new languages >>> tell you all you really need to know. >>> >> >> What exactly is that fact (assuming, without proof, that it /is/ a fact) >> supposed to tell me? >> >> At best, it tells me that if you want to create a new language, then it >> makes sense to start with something roughly like C to provide a base. >> That is pretty obvious - C is well-known, and it is a fairly basic >> imperative programming language. Almost any language that supports >> imperative programming will therefore have a sublanguage that is roughly >> isomorphic to C. It does not mean that C is always the best starting >> point - but it makes little difference to anything but the syntactic >> details if you choose Pascal or another imperative language as a >> starting point. >> >> On the other hand, object models can have a great deal of variation, as >> can techniques for metaprogramming and generic programming. C++ would >> only be a useful starting point if you wanted to copy the same models >> there, and that is unlikely (as you would probably be better off with a >> library for C++). Of course, languages like Java and C# copied a good >> deal of C++ syntax for similar features. >> > The other languages haven't really achieved acceptance. Which other languages are you talking about? I mentioned Pascal, which certainly achieved acceptance (and there are good examples of languages that are derived or inspired from Pascal, including Modula 2 and Ada, which "achieved acceptance" within particular areas). I also mentioned C# and Java - both of which have "achieved acceptance". > Plenty of people > use C++, but there isn't a consensus that C++ is the best way to extend C > to include objects. Both Apple and Microsoft, the two largest players, instead > created their own sets of extensions to C, and tried to push development > in that direction. Whilst there was an element of business and market positioning, > there were also technical reasons. In the case of Objective-C and C#, the reasoning was mainly business - the technical reasons are minor in comparison. But as I said, there are many reasons to pick different object models (as well as ways of handling generic programming) when making a new language. I am not arguing that people have or should have based new languages directly on C++ - I am arguing against the groundless theory that the lack of such languages indicates a fundamental problem with C++. > The exception is Javascript. But it's accepted purely as web page programming > language, an environment in which a standards committee has quite a bit of > power. I'm actually using a Javascript variant for non-web programming, but > it's just that, a variant. It wasn't considered important to implement the full > Javascript spec exactly. >
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-19 10:31 +1300 |
| Message-ID | <d8ihecFge23U3@mid.individual.net> |
| In reply to | #73203 |
Malcolm McLean wrote: > On Sunday, October 18, 2015 at 12:52:19 PM UTC+1, David Brown wrote: >> >> On the other hand, object models can have a great deal of variation, as >> can techniques for metaprogramming and generic programming. C++ would >> only be a useful starting point if you wanted to copy the same models >> there, and that is unlikely (as you would probably be better off with a >> library for C++). Of course, languages like Java and C# copied a good >> deal of C++ syntax for similar features. >> > The other languages haven't really achieved acceptance. Plenty of people > use C++, but there isn't a consensus that C++ is the best way to extend C > to include objects. Both Apple and Microsoft, the two largest players, instead > created their own sets of extensions to C, and tried to push development > in that direction. Whilst there was an element of business and market positioning, > there were also technical reasons. Mainly business. Companies like pushing their own tools, especially when they lock you into their platform. Microsoft needed something to compete with Java to avoid becoming just another second tier JVM hosting platform. To their credit they are now firmly behind the C++ standardisation process and promote C++ along with C# as a preferred language. > The exception is Javascript. Exception to what? > But it's accepted purely as web page programming > language, an environment in which a standards committee has quite a bit of > power. I'm actually using a Javascript variant for non-web programming, but > it's just that, a variant. It wasn't considered important to implement the full > Javascript spec exactly. JavaScript is more than just a web page programming language. The Google V8 JavaScript changed that. See https://nodejs.org/en/ for a server side environment. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-18 15:49 +0100 |
| Message-ID | <87twpomdtd.fsf@bsb.me.uk> |
| In reply to | #73194 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, October 18, 2015 at 10:19:30 AM UTC+1, David Brown wrote: >> >> Beauty is in the eye of the beholder, of course. You think your "casks" >> are clear and elegant - to other people it looks like your cat walked >> across your keyboard. It is fair enough to reject C++ for whatever >> reasons you want - but don't pretend it is for good, technical reasons >> until you have used it enough to be familiar with its basics. >> > You can't expect someone to spend much time on your language before > dismissing it as hard to use, uninterpretable, and so on. > Admittedly where a language has a large user base, like C++, you should > maybe be more careful before making too sweeping a judgement. But > the fact that everyone keeps going back to C to derive new languages > tell you all you really need to know. Can you give some examples so I know what you mean by "going back to C"? The new languages that I've been reading about seem to be far removed form C (even if the designers went back there for a starting point), which tells me that C is not a good end-point for a modern programming language. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-18 16:53 -0700 |
| Message-ID | <7eb90a37-7096-4656-a950-7a6f831e0579@googlegroups.com> |
| In reply to | #73206 |
On Sunday, October 18, 2015 at 3:50:08 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Can you give some examples so I know what you mean by "going back to C"? > The new languages that I've been reading about seem to be far removed > form C (even if the designers went back there for a starting point), > which tells me that C is not a good end-point for a modern programming > language. > By definition, if you create a new language using C as your basis and starting point, you're trying to make something a bit different for C. But it's also a compliment to C. You could reasonably go to Cobol and add a more sophisticated natural language parser and some more modern object type constructs. Possibly someone has done that. But I've never heard of the project if they have, it's got no traction. Functional languages do go back to Lisp. Often they also add a bit of C-like syntax, or functional constructs are bolted onto a languages which is basically a C derivative. But none has really broken into the mainstream yet. You play about with them for a bit and you write a Fibonacci generator or a PI series in a couple of lines of code that compiles to something mega efficient. But you don't actually use them for putting polygons on screen.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-19 01:50 +0100 |
| Message-ID | <87eggrlm13.fsf@bsb.me.uk> |
| In reply to | #73256 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, October 18, 2015 at 3:50:08 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Can you give some examples so I know what you mean by "going back to C"?
>> The new languages that I've been reading about seem to be far removed
>> form C (even if the designers went back there for a starting point),
>> which tells me that C is not a good end-point for a modern programming
>> language.
>>
> By definition, if you create a new language using C as your basis
> and starting point, you're trying to make something a bit different
> for C. But it's also a compliment to C.
I was hoping for an answer to my question. I just wanted to know what
you consider examples of new languages that went back to C for a
starting point. For some, if it uses {}s, it's a homage to C (I don't
accuse you of that, but I have no idea what languages you mean yet).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-19 02:28 -0700 |
| Message-ID | <2497a155-9713-4c4d-936a-0b6c2e5bfccb@googlegroups.com> |
| In reply to | #73258 |
On Monday, October 19, 2015 at 1:50:14 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Sunday, October 18, 2015 at 3:50:08 PM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> Can you give some examples so I know what you mean by "going back to C"?
> >> The new languages that I've been reading about seem to be far removed
> >> form C (even if the designers went back there for a starting point),
> >> which tells me that C is not a good end-point for a modern programming
> >> language.
> >>
> > By definition, if you create a new language using C as your basis
> > and starting point, you're trying to make something a bit different
> > for C. But it's also a compliment to C.
>
> I was hoping for an answer to my question. I just wanted to know what
> you consider examples of new languages that went back to C for a
> starting point. For some, if it uses {}s, it's a homage to C (I don't
> accuse you of that, but I have no idea what languages you mean yet).
>
C++, C sharp, Objective C are obvious examples. They've even got C in their
name. They're taking C as the starting point, and making it better or different.
But those are only the hugely popular languages which unambiguously and
self-admittedly used C as a basis or starting point. They're hardly the only
ones, though you can sometimes argue about whether C should be considered
a basis or an influence. Perl is basically a melding of shell script with C, for
example, you could regard it as C derivative or not, depending on how generous
you want to be to Denis Ritchie.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-19 12:38 +0200 |
| Message-ID | <n02h3q$rrq$1@dont-email.me> |
| In reply to | #73270 |
On 19/10/15 11:28, Malcolm McLean wrote:
> On Monday, October 19, 2015 at 1:50:14 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Sunday, October 18, 2015 at 3:50:08 PM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>
>>>> Can you give some examples so I know what you mean by "going back to C"?
>>>> The new languages that I've been reading about seem to be far removed
>>>> form C (even if the designers went back there for a starting point),
>>>> which tells me that C is not a good end-point for a modern programming
>>>> language.
>>>>
>>> By definition, if you create a new language using C as your basis
>>> and starting point, you're trying to make something a bit different
>>> for C. But it's also a compliment to C.
>>
>> I was hoping for an answer to my question. I just wanted to know what
>> you consider examples of new languages that went back to C for a
>> starting point. For some, if it uses {}s, it's a homage to C (I don't
>> accuse you of that, but I have no idea what languages you mean yet).
>>
> C++, C sharp, Objective C are obvious examples. They've even got C in their
> name. They're taking C as the starting point, and making it better or different.
You were trying to give examples for your claim that people "went back
to C" for deriving new languages, rather than starting from C++ - you
were using this "fact" as evidence for how bad C++ is.
And your three examples are - C++, C#, and Objective C. Yes, C++ was
derived from C and not from C++ - perhaps you can guess why? I don't
believe it has anything to do with supposed problems with C++.
What about Objective C? If you look at its history, it first appeared
in 1983. And when did C++ first appear? In 1983. Can you guess why
Objective C was derived from C and not C++?
Your third example is C# - and it /was/ derived from C++. It changes
many things, but is strongly influenced by C++ - both directly, and
indirectly via Java.
>
> But those are only the hugely popular languages which unambiguously and
> self-admittedly used C as a basis or starting point. They're hardly the only
> ones, though you can sometimes argue about whether C should be considered
> a basis or an influence. Perl is basically a melding of shell script with C, for
> example, you could regard it as C derivative or not, depending on how generous
> you want to be to Denis Ritchie.
>
The only thing "C-derived" about Perl is that it uses {} for grouping.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-19 12:09 +0100 |
| Message-ID | <n02itq$2v9$1@dont-email.me> |
| In reply to | #73273 |
On 19/10/2015 11:38, David Brown wrote:
> On 19/10/15 11:28, Malcolm McLean wrote:
>> But those are only the hugely popular languages which unambiguously and
>> self-admittedly used C as a basis or starting point. They're hardly the only
>> ones, though you can sometimes argue about whether C should be considered
>> a basis or an influence. Perl is basically a melding of shell script with C, for
>> example, you could regard it as C derivative or not, depending on how generous
>> you want to be to Denis Ritchie.
>>
>
> The only thing "C-derived" about Perl is that it uses {} for grouping.
Loads of languages are based around C-like syntax (which is what I
mostly don't like about C!)
It's not just {,} braces, but things such as parentheses around
conditionals, semicolons, and even exact copies of C's 'for' statement.
I think Perl has all this as well.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-19 14:26 +0200 |
| Message-ID | <n02nd0$jhb$1@dont-email.me> |
| In reply to | #73277 |
On 19/10/15 13:09, Bartc wrote:
> On 19/10/2015 11:38, David Brown wrote:
>> On 19/10/15 11:28, Malcolm McLean wrote:
>
>>> But those are only the hugely popular languages which unambiguously and
>>> self-admittedly used C as a basis or starting point. They're hardly
>>> the only
>>> ones, though you can sometimes argue about whether C should be
>>> considered
>>> a basis or an influence. Perl is basically a melding of shell script
>>> with C, for
>>> example, you could regard it as C derivative or not, depending on how
>>> generous
>>> you want to be to Denis Ritchie.
>>>
>>
>> The only thing "C-derived" about Perl is that it uses {} for grouping.
>
> Loads of languages are based around C-like syntax (which is what I
> mostly don't like about C!)
>
> It's not just {,} braces, but things such as parentheses around
> conditionals, semicolons, and even exact copies of C's 'for' statement.
> I think Perl has all this as well.
>
That's just syntax details. When making a new language, you need some
syntax - if it is convenient, you borrow from an existing language as it
might save you effort in making parsers, or syntax highlighting, or
lower the learning curve for people who are already used to the syntax.
But that doesn't mean the language is a C (or whatever) derivative -
any more than Esperanto is a Finish derivative just because they share
mostly the same alphabet.
In the case of Perl, you have an interpreted high-level language
targeted at scripting, web applications, and string manipulation. It is
not a derivative of a general purpose low-level systems language with an
emphasis on efficient performance.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-19 13:34 +0100 |
| Message-ID | <n02nrt$lav$1@dont-email.me> |
| In reply to | #73280 |
On 19/10/2015 13:26, David Brown wrote:
> On 19/10/15 13:09, Bartc wrote:
>> Loads of languages are based around C-like syntax (which is what I
>> mostly don't like about C!)
>>
>> It's not just {,} braces, but things such as parentheses around
>> conditionals, semicolons, and even exact copies of C's 'for' statement.
>> I think Perl has all this as well.
>>
>
> That's just syntax details. When making a new language, you need some
> syntax - if it is convenient, you borrow from an existing language as it
> might save you effort in making parsers, or syntax highlighting, or
> lower the learning curve for people who are already used to the syntax.
> But that doesn't mean the language is a C (or whatever) derivative -
> any more than Esperanto is a Finish derivative just because they share
> mostly the same alphabet.
Syntax isn't just a detail. It is quite a big deal, otherwise we'd all
be coding Lisp-style since that can express almost anything without
needing to keep adding dedicated syntax for it.
And there are a number of existing syntax families to choose from.
C-style just happens to be annoyingly popular.
And that still doesn't explain the obsession with many languages to keep
C's for statement practically unchanged.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-20 02:36 +0000 |
| Message-ID | <n049bp$862$1@speranza.aioe.org> |
| In reply to | #73280 |
David Brown <david.brown@hesbynett.no> wrote:
> On 19/10/15 13:09, Bartc wrote:
>> On 19/10/2015 11:38, David Brown wrote:
(snip)
>>> The only thing "C-derived" about Perl is that it uses {} for grouping.
>> Loads of languages are based around C-like syntax (which is what I
>> mostly don't like about C!)
>> It's not just {,} braces, but things such as parentheses around
>> conditionals, semicolons, and even exact copies of C's 'for' statement.
>> I think Perl has all this as well.
Well, there are languages that don't have ( ) for the IF statement,
but instead use THEN to separate the logical value from the statement
to execute.
I believe that a few C features can be traced back to PL/I, though not
so many of them.
> That's just syntax details. When making a new language, you need some
> syntax - if it is convenient, you borrow from an existing language as it
> might save you effort in making parsers, or syntax highlighting, or
> lower the learning curve for people who are already used to the syntax.
> But that doesn't mean the language is a C (or whatever) derivative -
> any more than Esperanto is a Finish derivative just because they share
> mostly the same alphabet.
Yes, but languages can have multiple inheritance.
It is well known that PL/I includes features from Fortran, COBOL,
and Algol.
IBM was hoping not to have to write separate compilers, but instead
get everyone to use one language.
Some features are common enough that you can't really say where they
came from, but in many cases there were languages used by the original
authors, and ideas came from those.
And even when a feature is derived from another language, the new syntax
can be completely different from the old.
I don't know that C struct came from PL/I structures, and the syntax
differences make it less obvious, but I suspect so.
PL/I was the usual language used with Multics, the system that unix was
written to avoid.
> In the case of Perl, you have an interpreted high-level language
> targeted at scripting, web applications, and string manipulation. It is
> not a derivative of a general purpose low-level systems language with an
> emphasis on efficient performance.
I suspect using similar syntax was intentional, even when the meaning
for the syntax might be different.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-19 05:09 -0700 |
| Message-ID | <382bc6a7-73d5-40dc-81e4-ce5806ddb1f7@googlegroups.com> |
| In reply to | #73273 |
On Monday, October 19, 2015 at 11:39:06 AM UTC+1, David Brown wrote:
> On 19/10/15 11:28, Malcolm McLean wrote:
>
> What about Objective C? If you look at its history, it first appeared
> in 1983. And when did C++ first appear? In 1983. Can you guess why
> Objective C was derived from C and not C++?
>
And it would have languished in obscurity, had not Apple chosen it as
their main development language. They didn't go for C++. They went back
to C.
>
> Your third example is C# - and it /was/ derived from C++. It changes
> many things, but is strongly influenced by C++ - both directly, and
> indirectly via Java.
>
Java and C# are both samples of languages designed by people who took
a look at C++, said, "yes, we see what they are trying to do, but we don't think
they did it very well". Then they returned to C as their base and re-derived
the extensions, admittedly with some influence from C++.
>
> The only thing "C-derived" about Perl is that it uses {} for grouping.
>
And it has printf style format strings. And it has essentially a superset of C's flow
control keywords (I'm not sure about switch). It does have a different (and very
horrid) syntax for passing arguments to subroutines, but essentially a Perl
sub maps to a C function. It doesn't make the procedure / function / pure
function distinction, for example. Despite being also influenced by shell scripting,
it doesn't insist that subroutines be in named separate files. Saying a sub maps to
a C function isn't the same as saying that C and Perl allow subroutines, which
would be a weak similarity.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-19 14:41 +0200 |
| Message-ID | <n02oai$n17$1@dont-email.me> |
| In reply to | #73279 |
On 19/10/15 14:09, Malcolm McLean wrote:
> On Monday, October 19, 2015 at 11:39:06 AM UTC+1, David Brown wrote:
>> On 19/10/15 11:28, Malcolm McLean wrote:
>>
>> What about Objective C? If you look at its history, it first appeared
>> in 1983. And when did C++ first appear? In 1983. Can you guess why
>> Objective C was derived from C and not C++?
>>
> And it would have languished in obscurity, had not Apple chosen it as
> their main development language. They didn't go for C++. They went back
> to C.
Have you ever /looked/ at Objective C? Beauty is in the eye of the
beholder, but I would have named it Objectionable C.
Historically, Objective C was one of several attempts to form an
object-oriented programming language with the efficiency of C but the OO
power of Smalltalk or Simula. There were a number of such C derivatives
considered at that time, of which two had a future - C++ (most
influenced by Simula) and Objective C (most influenced by Smalltalk).
So why did NeXt pick Objective C rather than C++ ? I don't know, but at
that time C++ was a young language - it did not have the sort of
dominance and popularity that it has now. And when Apple later acquired
NeXT and used their software and tools for their future development, it
was natural to build on Objective C.
So Apple did not choose Objective C as such - they choose NeXT and
NeXT's software, which happened to be strongly tied to Objective C.
Apple did not "go back to C" - Objective C is as far from C as C++ is.
(You are correct that Objective C would probably have died if it were
not used by Apple. But that's a side issue.)
>>
>> Your third example is C# - and it /was/ derived from C++. It changes
>> many things, but is strongly influenced by C++ - both directly, and
>> indirectly via Java.
>>
> Java and C# are both samples of languages designed by people who took
> a look at C++, said, "yes, we see what they are trying to do, but we don't think
> they did it very well". Then they returned to C as their base and re-derived
> the extensions, admittedly with some influence from C++.
No, they are both examples of languages where people looked at C++ and
said "I like a lot of what you are doing here, but not everything" - and
designed a language that suited their purpose better than C++. If they
couldn't improve on C++, at least within their own target area (which is
/not/ the same area as C++), then there would be no point in making a
new language.
And they did not "return to C" - they copied some parts of C, and
changed other parts - just as they copied some parts of C++ and changed
other parts. Java and C# are languages based on and developed from C++
in exactly the same way that they are based on and developed from C.
>>
>> The only thing "C-derived" about Perl is that it uses {} for grouping.
>>
> And it has printf style format strings. And it has essentially a superset of C's flow
> control keywords (I'm not sure about switch). It does have a different (and very
> horrid) syntax for passing arguments to subroutines, but essentially a Perl
> sub maps to a C function. It doesn't make the procedure / function / pure
> function distinction, for example. Despite being also influenced by shell scripting,
> it doesn't insist that subroutines be in named separate files. Saying a sub maps to
> a C function isn't the same as saying that C and Perl allow subroutines, which
> would be a weak similarity.
>
I don't understand what you mean by saying "shell scripting insists that
subroutines be in named separate files" - that's not my experience of
shell scripting.
So Perl has some similarities to C in a few areas. So what? It is not
a C-derived language - it is a completely different sort of language
designed for completely different tasks. The authors of Perl knew C,
and therefore copied the same names and a few syntactic details when
parts of the language overlapped, but that's all.
[toc] | [prev] | [next] | [standalone]
Page 3 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