Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #7948 > unrolled thread
| Started by | spud@potato.field |
|---|---|
| First post | 2016-03-01 11:06 +0000 |
| Last post | 2016-03-20 07:12 -0400 |
| Articles | 20 on this page of 186 — 27 participants |
Back to article view | Back to comp.unix.programmer
Odd compiler behaviour? spud@potato.field - 2016-03-01 11:06 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 12:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:48 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 15:46 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 15:08 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:36 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 16:47 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:51 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 17:05 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:00 -0800
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:56 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:42 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:55 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:46 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 20:59 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:09 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 13:03 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:15 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 14:38 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 11:20 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:45 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 16:54 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 13:14 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:10 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 19:26 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:57 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 21:07 +0100
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 15:40 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 21:14 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 21:20 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 22:09 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 23:04 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 17:08 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 22:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 10:39 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 16:19 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 11:56 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 17:21 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 12:42 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:03 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 10:41 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:59 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 11:40 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:05 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 15:32 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:51 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:01 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 21:10 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:41 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:52 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 22:14 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-02 18:54 -0500
Re: Odd compiler behaviour? gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-02 21:30 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:34 -0800
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-05 16:48 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-05 15:29 -0500
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-05 15:41 -0500
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-05 23:19 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-06 12:44 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-06 14:10 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-07 09:53 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 12:59 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 13:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 15:28 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-08 10:42 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-08 17:09 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 20:38 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 22:15 +0000
Re: Odd compiler behaviour? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-03-08 16:21 -0700
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-08 10:47 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 16:04 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 09:40 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 11:31 +0100
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:21 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 12:57 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:32 +0000
Re: Odd compiler behaviour? Robert Wessel <robertwessel2@yahoo.com> - 2016-03-09 11:13 -0600
Re: Odd compiler behaviour? Les Cargill <lcargill99@comcast.com> - 2016-03-09 07:16 -0600
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:19 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:28 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:35 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:08 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:32 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 13:34 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:17 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 16:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:45 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:34 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 15:40 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:57 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 16:07 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 14:12 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 19:51 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 20:08 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:31 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:55 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 17:25 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-11 17:49 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-12 18:11 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 09:43 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 15:57 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 12:16 -0400
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 17:00 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-14 17:14 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:29 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:46 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 18:16 -0400
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 20:45 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 09:25 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 22:36 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 10:23 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-15 10:11 -0400
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 14:33 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 15:41 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-17 18:18 -0400
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-17 23:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 09:44 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 11:31 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 08:32 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 21:46 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 09:25 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 13:22 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 14:07 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 15:59 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 15:12 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 17:27 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:35 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:29 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:23 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 13:14 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 13:38 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 15:20 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:23 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-18 15:58 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 16:20 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-19 02:46 -0400
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-15 15:42 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 21:55 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-15 13:37 +0000
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-31 19:25 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 15:17 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:23 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:30 +0100
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 14:40 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:28 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 10:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 10:29 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 12:50 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 12:21 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 12:22 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-10 13:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 13:55 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-10 08:29 -0800
Re: Odd compiler behaviour? gordonb.uf2r1@burditt.org (Gordon Burditt) - 2016-03-12 03:36 -0600
Re: Odd compiler behaviour? Richard Damon <Richard@Damon-Family.org> - 2016-03-12 10:13 -0500
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-13 23:11 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-13 22:12 +0000
succint expressions (was: Odd compiler behaviour?) Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 11:04 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:39 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 01:00 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:27 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:24 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:10 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:14 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-09 20:18 +0000
Re: Odd compiler behaviour? gordonb.2x965@burditt.org (Gordon Burditt) - 2016-03-14 23:45 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 16:11 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:37 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:34 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 20:05 +0000
[OT] Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-09 15:13 -0500
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:35 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:01 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:09 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-01 14:18 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:53 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 16:44 +0100
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 09:22 -0800
Re: Odd compiler behaviour? David Thompson <dave.thompson2@verizon.net> - 2016-03-20 07:12 -0400
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-10 17:25 -0500 |
| Message-ID | <20160310172556.1819add556ddbb260a38ab75@speakeasy.net> |
| In reply to | #8125 |
On Thu, 10 Mar 2016 19:51:58 +0000 Rainer Weikusat <rweikusat@talktalk.net> wrote: > > The difference has nothing to do with the CPU and everything to do > > with the language. Please see abs(3) and fabs(3). Two functions > > are needed because the arguments are of different *types*. That > > would be true even on a machine that implemented floating point in > > software. > > But the arguments are of different types because of "CPU > architectures" supporting different 'kinds' of numbers with different > properties and representations. That depends on what you mean by "because". If you mean CPU designs drove and drive the C language specification and compilers, OK. But I'm pretty sure the C standard makes no reference to any hardware. I can if I want to write a C compiler whose target is a VM written in JavaScript. (I wouldn't be surprised if it's been done already.) C -- not the hardware -- defines its types. C requires each function to have a unique name. Hence C, not the CPU, require abs and fabs to be two functions, if both types of absolute value are to be supported. > > The operator + is a binary function. > > 'operator +' implementations in C++ are binary functions. But the C > '+' operator isn't. It's a special language construct which can > appear in an additive expression. Yes, OK. To be ridiculously pedantic, the + operator is a binary function in C++ only for user-defined types. :-) I was speaking in logical terms. Would you have agreed with my statement if I had said, "The + operator can be thought of as a binary function"? How to escape the mechanics of C to draw a parallel to user-written functions? > Considering that the compiler is supposed to generate code based on > the types of the actual operands, the way to approximate this in C++ > would really rather be a template function with two template > arguments. But that's not good enough because the type of the return > value depends on the types of both arguments. Hmm, well, templates are one way to generate overloaded function definitions. AIUI C++17 will bring us concepts, a type system for template arguments. I haven't read the draft, but in theory that would encompass int/float types, and could support two templates along the lines you're suggesting. --jkl
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2016-03-11 17:49 +0000 |
| Message-ID | <87bn6klxb0.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #8127 |
"James K. Lowden" <jklowden@speakeasy.net> writes:
> On Thu, 10 Mar 2016 19:51:58 +0000
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>
>> > The difference has nothing to do with the CPU and everything to do
>> > with the language. Please see abs(3) and fabs(3). Two functions
>> > are needed because the arguments are of different *types*. That
>> > would be true even on a machine that implemented floating point in
>> > software.
>>
>> But the arguments are of different types because of "CPU
>> architectures" supporting different 'kinds' of numbers with different
>> properties and representations.
>
> That depends on what you mean by "because". If you mean CPU designs
> drove and drive the C language specification and compilers, OK. But
> I'm pretty sure the C standard makes no reference to any hardware.
> I can if I want to write a C compiler whose target is a VM written in
> JavaScript. (I wouldn't be surprised if it's been done already.)
>
> C -- not the hardware -- defines its types.
C is somewhat (in-)famous for mostly not 'defining its types'. In
particular, an implementation is to provide certain 'floating point
types', namely (C99), float, double and long double, with float being a
subset of double and double being a subset of long double, and that's
it.
And that C uses different types for 'integers' and 'floating point
numbers' was most assuredly driven by 'hardware requirements', cf
Second, although the original PDP-11 did not provide for
floating-point arithmetic, the manufacturer promised that it
would soon be available. Floating-point operations had been
added to BCPL in our Multics and GCOS compilers by defining
special operators, but the mechanism was possible only because
on the relevant machines, a single word was large enough to
contain a floating-point number; this was not true on the 16-bit
PDP-11.
[The Development of the C Lanuage, Ritchie, p 6]
[...]
>> > The operator + is a binary function.
>>
>> 'operator +' implementations in C++ are binary functions. But the C
>> '+' operator isn't. It's a special language construct which can
>> appear in an additive expression.
>
> Yes, OK. To be ridiculously pedantic, the + operator is a binary
> function in C++ only for user-defined types. :-)
That's why I wrote "'operator +' implementations in C++". This was
supposed to refer to C++ functions or methods named 'operator +', not to
the + operator provided by the language itself.
> I was speaking in logical terms. Would you have agreed with my
> statement if I had said, "The + operator can be thought of as a binary
> function"? How to escape the mechanics of C to draw a parallel to
> user-written functions?
Depending on the context, 'the + operator' can also be thought of as the
guy whose job is to turn the x. But this communicates nothing about
the C + operator which isn't a binary (C) function and can't be modelled
as such because the language doesn't support this. Further, this attempt
also fails in the other direction: C++ doesn't support something like
long double operator +(long double l, unsigned short us);
the first argument is required to be of class or enumeration type, ie,
the kind of overloading suggested by the add example is specifically not
'C++ operator overloading', overloading being overloaded here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-12 18:11 -0800 |
| Message-ID | <ln1t7fm8ip.fsf@kst-u.example.com> |
| In reply to | #8127 |
"James K. Lowden" <jklowden@speakeasy.net> writes:
[...]
> AIUI C++17 will bring us concepts, a type system for template
> arguments. I haven't read the draft, but in theory that would
> encompass int/float types, and could support two templates along the
> lines you're suggesting.
Apparently they won't be in C++17, but they could be in a later edition.
http://honermann.net/blog/?p=3
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-14 09:43 +0000 |
| Message-ID | <nc613f$793$1@gioia.aioe.org> |
| In reply to | #8149 |
On Sat, 12 Mar 2016 18:11:42 -0800 Keith Thompson <kst-u@mib.org> wrote: >"James K. Lowden" <jklowden@speakeasy.net> writes: >[...] >> AIUI C++17 will bring us concepts, a type system for template >> arguments. I haven't read the draft, but in theory that would >> encompass int/float types, and could support two templates along the >> lines you're suggesting. > >Apparently they won't be in C++17, but they could be in a later edition. Alternatively perhaps C++ has enough kitchen sinks in it already and it should be considered done. I get the feeling the constant additions to the C++ spec are not because anyone is asking for them but is more a case of "because we can". The language is complex enough and its already got to the point where people generally only learn a subset of it which makes debugging code from someone who's used another subset harder than it should be. Just adding more pointless paradigm-of-the-month functionality along with its contorted syntatic baggage is not going to make life any easier for anyone. Seems to me both Java and C++ suffer the same endless feature creep , except with Java is more and more libraries, with C++ its more and more expansion of the core language. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-14 15:57 +0000 |
| Message-ID | <20160314085528.572@kylheku.com> |
| In reply to | #8152 |
On 2016-03-14, spud@potato.field <spud@potato.field> wrote: > Alternatively perhaps C++ has enough kitchen sinks in it already and it > should be considered done. C++ was complete in 1998 as far as I'm concerned, and reasonably debugged in 2003. > I get the feeling the constant additions to the > C++ spec are not because anyone is asking for them but is more a case of > "because we can". An addition X to a language like C++ should be only for one reason, with two variants: 1. Numerous popular compilers are doing X, in incompatible ways; let's standardize it. 2. Numerous popular compilers have X; let's codify it as standard.
[toc] | [prev] | [next] | [standalone]
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-14 12:16 -0400 |
| Message-ID | <20160314121635.e41a9a3dcf5c11a6de0c3add@speakeasy.net> |
| In reply to | #8152 |
On Mon, 14 Mar 2016 09:43:11 +0000 (UTC)
spud@potato.field wrote:
> On Sat, 12 Mar 2016 18:11:42 -0800
> Keith Thompson <kst-u@mib.org> wrote:
> >"James K. Lowden" <jklowden@speakeasy.net> writes:
> >[...]
> >> AIUI C++17 will bring us concepts, a type system for template
> >> arguments. I haven't read the draft, but in theory that would
> >> encompass int/float types, and could support two templates along
> >> the lines you're suggesting.
> >
> >Apparently they won't be in C++17, but they could be in a later
> >edition.
>
> The language is complex enough and its already got to the point where
> people generally only learn a subset of it which makes debugging code
> from someone who's used another subset harder than it should be. Just
> adding more pointless paradigm-of-the-month functionality along with
> its contorted syntatic baggage is not going to make life any easier
> for anyone.
Your criticism could not be more off base. Concepts aren't by any
means "paradigm-of-the-month", and they could be very helpful with
regard to compiler error messages.
Concepts are a type system for template parameters. Because template
parameters currently have no type, use of the "wrong" type is invisible
to the template-expansion mechanism, and leads to horrendous compiler
diagnostics hardly worthy of the name. For example,
#include <set>
struct S { char name[8]; int value; };
std::set<S> values;
S s = {"a", 1};
void f() {
values.insert(s);
}
fails because no operator< is defined for S. And you know what that
kind of error message looks like. My copy of gcc for the above
produces as the first of 24 lines (!):
/usr/include/g++/bits/stl_function.h: In instantiation of 'bool
std::less<_Tp>::operator()(const _Tp&, const _Tp&) const [with _Tp =
S]': /usr/include/g++/bits/stl_tree.h:1324:11: required from
'std::pair<std::_Rb_tree_node_base*, std::_Rb_tree_node_base*>
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_get_insert_unique_pos(const key_type&) [with _Key = S; _Val
= S; _KeyOfValue = std::_Identity<S>; _Compare = std::less<S>; _Alloc =
std::allocator<S>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::key_type = S]'
If that's helpful to you, you're a better man than I. The most
helpful though hardly stellar message is #3:
/usr/include/g++/bits/stl_function.h:235:20: error: no match for
'operator<' (operand types are 'const S' and 'const S')
Only from grisly experience does the programmer know that there is
no error on line 235 of stl_function.h. If you ask me, it's the second
worst blight on C++ (other than missing reflection, of course).
Concepts AIUI would support specification that S be a member of
"sortable" (or something). When the set is instantiated, the compiler
would verify that set::value_type has the property of being sortable,
probably through operator<. We could then look forward to a sane error
message,
foo:4:9: error: std::set template argument S not sortable:
no match for 'operator<' (operand types are 'const S' and 'const S')
something every C++ programmer should wish for and, objectively
speaking, deserves.
--jkl
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-14 17:00 +0000 |
| Message-ID | <nc6qn9$1o63$1@gioia.aioe.org> |
| In reply to | #8155 |
On Mon, 14 Mar 2016 12:16:35 -0400
"James K. Lowden" <jklowden@speakeasy.net> wrote:
>Your criticism could not be more off base. Concepts aren't by any
>means "paradigm-of-the-month", and they could be very helpful with
>regard to compiler error messages.
Decent compiler error messages do not require a change in the language!
>Concepts are a type system for template parameters. Because template
>parameters currently have no type, use of the "wrong" type is invisible
Template parameters have no type , err, because thats the whole point of
generics! If you really need a type for templates then there is specialisation.
>to the template-expansion mechanism, and leads to horrendous compiler
>diagnostics hardly worthy of the name. For example,
>
> #include <set>
>
> struct S { char name[8]; int value; };
> std::set<S> values;
>
> S s = {"a", 1};
>
> void f() {
> values.insert(s);
> }
>
>fails because no operator< is defined for S. And you know what that
>kind of error message looks like. My copy of gcc for the above
>produces as the first of 24 lines (!):
And that needs yet more additions to C++ does it? No, it requires compiler
writers to get their compilers to print saner error messages. Clang is far
better in this respect. Instead of the unintelligable rubbish one gets from
gcc you get this instead:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__functional_base:
63:21: error:
invalid operands to binary expression ('const S' and 'const S')
{return __x < __y;}
~~~ ^ ~~~
:
:
t.cc:9:14: note: in instantiation of member function 'std::__1::set<S,
std::__1::less<S>, std::__1::allocator<S> >::insert' requested here
values.insert(s);
Which neatly explains the issue IMO.
>Only from grisly experience does the programmer know that there is
You mean the programmer using gcc. Gcc is very good at a lot of things, useful
error messages however is not one of them.
--
Spud
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2016-03-14 17:14 +0000 |
| Message-ID | <87shzt7zim.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #8156 |
spud@potato.field writes: > "James K. Lowden" <jklowden@speakeasy.net> wrote: [...] >>Concepts are a type system for template parameters. Because template >>parameters currently have no type, use of the "wrong" type is invisible > > Template parameters have no type , err, because thats the whole point of > generics! If you really need a type for templates then there is specialisation. You're interpreting 'type' to literally here: It's not supposed to mean 'type' as in int or Std::String but really 'abstract property of type', roughly what Java calls 'bounded type parameters'. Eg, the C + operator used earlier as an example requires (simplification) both of it's arguments to be 'arithmetic types'. 'Arithmetic' is a property of some C types, namely, integers and floats. Likewise, 'sortable' could be a property of some types. In C++, this could mean 'supports ==, !=, < and >'.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-14 18:29 +0000 |
| Message-ID | <20160314112738.485@kylheku.com> |
| In reply to | #8157 |
On 2016-03-14, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> spud@potato.field writes:
>> "James K. Lowden" <jklowden@speakeasy.net> wrote:
>
> [...]
>
>>>Concepts are a type system for template parameters. Because template
>>>parameters currently have no type, use of the "wrong" type is invisible
>>
>> Template parameters have no type , err, because thats the whole point of
>> generics! If you really need a type for templates then there is
>> specialisation.
>
> You're interpreting 'type' to literally here: It's not supposed to mean
> 'type' as in int or Std::String but really 'abstract property of type',
> roughly what Java calls 'bounded type parameters'. Eg, the C + operator
> used earlier as an example requires (simplification) both of it's
> arguments to be 'arithmetic types'. 'Arithmetic' is a property of some C
> types, namely, integers and floats. Likewise, 'sortable' could be a
> property of some types. In C++, this could mean 'supports ==, !=, < and
(defmacro lisp-macro (param)
(unless (fooable param)
(error "lisp-macro: param ~s must be fooable" param))
...)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-14 18:46 +0000 |
| Message-ID | <20160314113051.154@kylheku.com> |
| In reply to | #8156 |
On 2016-03-14, spud@potato.field <spud@potato.field> wrote:
> On Mon, 14 Mar 2016 12:16:35 -0400
> "James K. Lowden" <jklowden@speakeasy.net> wrote:
>>Your criticism could not be more off base. Concepts aren't by any
>>means "paradigm-of-the-month", and they could be very helpful with
>>regard to compiler error messages.
>
> Decent compiler error messages do not require a change in the language!
Indeed ...
$ txr
This is the TXR Lisp interactive listener of TXR 135.
Use the :quit command or type Ctrl-D on empty line to exit.
1> (new foobar size 42)
** make-struct: foobar does not name a struct type
** during evaluation of form (make-struct 'foobar (list 'size 42))
** ... an expansion at /usr/local/share/txr/stdlib/struct.tl:205 of (new foobar size
42)
** which is located at expr-1:1
Nicely informative. A form (new foobar 42) was expanded at line 1 within
REPL expression 1. The expansion was performed by a standard macro in
/usr/local/share: programmer can look there, if interested.
The expansion produced (make-struct 'foobar ...) and that experienced
an error.
The new macro could do this check itself instead of delegating to make-struct.
The late binding allows new expressions to occur before the struct type has
been seen.
We can demonstrate the expansion-time check with a simple wrapper for new:
$ cat new-wrap.tl
(defmacro my-new (. args)
(unless (find-struct-type (first args))
(error "my-new: ~s isn't a struct type" (first args)))
^(new ,*args))
$ txr -i new-wrap.tl
1> (my-new passwd uid 42)
#S(passwd name nil passwd nil uid 42 gid nil gecos nil dir nil shell nil)
2> (my-new foobar size 42)
** my-new: foobar isn't a struct type
** during evaluation at new-wrap.tl:3 of form (error "my-new: ~s isn't a struct type"
(first args))
** during expansion at expr-2:1 of form (my-new foobar
size 42)
3>
Now the error is caught at expansion time, just like the template catching
that a parameter isn't "sortable".
Simplicity and clarity: now those are concepts.
[toc] | [prev] | [next] | [standalone]
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-14 18:16 -0400 |
| Message-ID | <20160314181618.13e9aa42616e013bd17cefbf@speakeasy.net> |
| In reply to | #8156 |
On Mon, 14 Mar 2016 17:00:25 +0000 (UTC) spud@potato.field wrote: > On Mon, 14 Mar 2016 12:16:35 -0400 > "James K. Lowden" <jklowden@speakeasy.net> wrote: > >Your criticism could not be more off base. Concepts aren't by any > >means "paradigm-of-the-month", and they could be very helpful with > >regard to compiler error messages. > > Decent compiler error messages do not require a change in the > language! That's a fair point. As you say, Clang does a better job. (Last time I used Microsoft's compiler, its message was no better than gcc's.) Still, concepts have been bandied about for years now, 5 that I know of. I wouldn't say that's a fad. As far as I'm concerned, whether or not they carry their weight depends on the concrete proposal. --jkl
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-03-15 20:45 +1300 |
| Message-ID | <dkpst6FtasnU1@mid.individual.net> |
| In reply to | #8152 |
On 03/14/16 22:43, spud@potato.field wrote: > On Sat, 12 Mar 2016 18:11:42 -0800 > Keith Thompson <kst-u@mib.org> wrote: >> "James K. Lowden" <jklowden@speakeasy.net> writes: >> [...] >>> AIUI C++17 will bring us concepts, a type system for template >>> arguments. I haven't read the draft, but in theory that would >>> encompass int/float types, and could support two templates along the >>> lines you're suggesting. >> >> Apparently they won't be in C++17, but they could be in a later edition. > > Alternatively perhaps C++ has enough kitchen sinks in it already and it > should be considered done. I get the feeling the constant additions to the > C++ spec are not because anyone is asking for them but is more a case of > "because we can". Nope, new features are added because programmers want them. C++11 take-up is probably already higher than C99! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-15 09:25 +0000 |
| Message-ID | <nc8kf0$40o$1@gioia.aioe.org> |
| In reply to | #8162 |
On Tue, 15 Mar 2016 20:45:42 +1300 Ian Collins <ian-news@hotmail.com> wrote: >On 03/14/16 22:43, spud@potato.field wrote: >> On Sat, 12 Mar 2016 18:11:42 -0800 >> Keith Thompson <kst-u@mib.org> wrote: >>> "James K. Lowden" <jklowden@speakeasy.net> writes: >>> [...] >>>> AIUI C++17 will bring us concepts, a type system for template >>>> arguments. I haven't read the draft, but in theory that would >>>> encompass int/float types, and could support two templates along the >>>> lines you're suggesting. >>> >>> Apparently they won't be in C++17, but they could be in a later edition. >> >> Alternatively perhaps C++ has enough kitchen sinks in it already and it >> should be considered done. I get the feeling the constant additions to the >> C++ spec are not because anyone is asking for them but is more a case of >> "because we can". > >Nope, new features are added because programmers want them. C++11 Really? Can't say I'd noticed a grass roots campaign for concepts to be included recently. >take-up is probably already higher than C99! "Probably"? So in other words you're just guessing. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-03-15 22:36 +1300 |
| Message-ID | <dkq3dnFtasnU3@mid.individual.net> |
| In reply to | #8163 |
On 03/15/16 22:25, spud@potato.field wrote: > On Tue, 15 Mar 2016 20:45:42 +1300 > Ian Collins <ian-news@hotmail.com> wrote: >> On 03/14/16 22:43, spud@potato.field wrote: >>> On Sat, 12 Mar 2016 18:11:42 -0800 >>> Keith Thompson <kst-u@mib.org> wrote: >>>> "James K. Lowden" <jklowden@speakeasy.net> writes: >>>> [...] >>>>> AIUI C++17 will bring us concepts, a type system for template >>>>> arguments. I haven't read the draft, but in theory that would >>>>> encompass int/float types, and could support two templates along the >>>>> lines you're suggesting. >>>> >>>> Apparently they won't be in C++17, but they could be in a later edition. >>> >>> Alternatively perhaps C++ has enough kitchen sinks in it already and it >>> should be considered done. I get the feeling the constant additions to the >>> C++ spec are not because anyone is asking for them but is more a case of >>> "because we can". >> >> Nope, new features are added because programmers want them. C++11 > > Really? Can't say I'd noticed a grass roots campaign for concepts to be > included recently. There is strong demand for concepts. Getting them right is the priority. >> take-up is probably already higher than C99! > > "Probably"? So in other words you're just guessing. Well people on c.l.c still bitch about C99 and Microsoft still do their best to ignore it, while all the major vendors support C++11. The C++ committee listen and give up programmers what we need. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-15 10:23 +0000 |
| Message-ID | <nc8nr1$9je$1@gioia.aioe.org> |
| In reply to | #8164 |
On Tue, 15 Mar 2016 22:36:54 +1300 Ian Collins <ian-news@hotmail.com> wrote: >> Really? Can't say I'd noticed a grass roots campaign for concepts to be >> included recently. > >There is strong demand for concepts. Getting them right is the priority. Where is the strong demand? >>> take-up is probably already higher than C99! >> >> "Probably"? So in other words you're just guessing. > >Well people on c.l.c still bitch about C99 and Microsoft still do their >best to ignore it, while all the major vendors support C++11. The C++ >committee listen and give up programmers what we need. If you "need" concepts then you're probably not a very good programmer. I remember how lambda functions were not long ago being extolled as such a wonderful addition to C++. I've yet to ever use one in anger and nor have I seen any in code I've worked on at various companys. As for nonsense like "auto" - if I want a language with dynamic typing I'll use Python. Or BASIC. Concepts sound like yet another tick in a box for language geeks that will almost never be used by 99% of coders other than 2nd hand via a library or framework. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-15 10:11 -0400 |
| Message-ID | <20160315101117.6f3e12f34bc2405b80147827@speakeasy.net> |
| In reply to | #8165 |
On Tue, 15 Mar 2016 10:23:29 +0000 (UTC) spud@potato.field wrote: > On Tue, 15 Mar 2016 22:36:54 +1300 > Ian Collins <ian-news@hotmail.com> wrote: > >> Really? Can't say I'd noticed a grass roots campaign for concepts > >> to be included recently. > > > >There is strong demand for concepts. Getting them right is the > >priority. > > Where is the strong demand? The demand is from experts. Granted, they're self-appointed, but they're also peer-reviewed: inexpert opinions don't travel far in that atmosphere. Every successful programming language is the product of a small group of experts. The only thing harder to imagine than a grass-roots campaign is a good result coming of it. That's not to say the committee perfectly represents its "constituency". C++ has substantially no support for reflection, and its model for concurrency includes no support for CSP, the advantages of which Go is demonstrating. > >Well people on c.l.c still bitch about C99 and Microsoft still do > >their best to ignore it, while all the major vendors support C++11. > >The C++ committee listen and give up programmers what we need. > > If you "need" concepts then you're probably not a very good > programmer. $ cat /dev/null > evidence > As for nonsense like "auto" - if I want a language with dynamic > typing I'll use Python. Or BASIC. I'm not a fan of auto either, because it hides information. IMO it would be more useful if the language also required the compiler to emit metadata (in a standardized way, by definition) that described the location and type of each auto variable. That would make it easier for tools to visualize the metadata that used to be in the source code. > I remember how lambda functions were not long ago being > extolled as such a wonderful addition to C++. I've yet to ever use > one in anger and nor have I seen any in code I've worked on at > various companys. If you're working on a large codebase or have to be compatible with old compilers, you might not be able to use C++11 constructs. I've used lambdas in my work. I like to organize my work around std algorithms, and lambdas sometimes obviate the need for one-time functor classes. Same logic, less typing. --jkl
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-15 14:33 +0000 |
| Message-ID | <20160315073218.363@kylheku.com> |
| In reply to | #8167 |
On 2016-03-15, James K. Lowden <jklowden@speakeasy.net> wrote: > On Tue, 15 Mar 2016 10:23:29 +0000 (UTC) > spud@potato.field wrote: > >> On Tue, 15 Mar 2016 22:36:54 +1300 >> Ian Collins <ian-news@hotmail.com> wrote: >> >> Really? Can't say I'd noticed a grass roots campaign for concepts >> >> to be included recently. >> > >> >There is strong demand for concepts. Getting them right is the >> >priority. >> >> Where is the strong demand? > > The demand is from experts. Granted, they're self-appointed, but > they're also peer-reviewed: inexpert opinions don't travel far in that > atmosphere. > > Every successful programming language is the product of a small group > of experts. But then it sometimes happens that some ISO shitheads get their hands on it.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-15 15:41 +0000 |
| Message-ID | <nc9af9$18ea$1@gioia.aioe.org> |
| In reply to | #8167 |
On Tue, 15 Mar 2016 10:11:17 -0400 "James K. Lowden" <jklowden@speakeasy.net> wrote: >On Tue, 15 Mar 2016 10:23:29 +0000 (UTC) >spud@potato.field wrote: > >> On Tue, 15 Mar 2016 22:36:54 +1300 >> Ian Collins <ian-news@hotmail.com> wrote: >> >> Really? Can't say I'd noticed a grass roots campaign for concepts >> >> to be included recently. >> > >> >There is strong demand for concepts. Getting them right is the >> >priority. >> >> Where is the strong demand? > >The demand is from experts. Granted, they're self-appointed, but >they're also peer-reviewed: inexpert opinions don't travel far in that >atmosphere. If by non-experts you mean programmers on the shop floor who use C++ to do actual work rather than use it as an interesting academic exercise in language design then you're probably right, I doubt the C++ committee listens to any of us. >Every successful programming language is the product of a small group >of experts. The only thing harder to imagine than a grass-roots >campaign is a good result coming of it. ITYM is a product of one person or a small group of experts *initially*. Then a committee tends to get their hands on it and it goes to shit. >That's not to say the committee perfectly represents its >"constituency". C++ has substantially no support for reflection, and Reflection in a compiled language requires a lot of runtime baggage to make it work. No thanks. >its model for concurrency includes no support for CSP, the advantages >of which Go is demonstrating. Concurrency should be the responsibility of the OS, not the language. The language should just provide an API to access the OS facilities. If you want your language to be a mini-OS use a VM based language such as Java or Erlang. >> If you "need" concepts then you're probably not a very good >> programmer. > > $ cat /dev/null > evidence Ok, give me some examples where'd they'd even be useful in C++ (and I don't just mean to get around the poor error reporting of gcc), never mind essential enough to need. >I've used lambdas in my work. I like to organize my work around std >algorithms, and lambdas sometimes obviate the need for one-time functor >classes. Same logic, less typing. Exactly, same logic. They're syntatic sugar, nothing more. Except IMO they're more bitter than sweet - a hideous syntax. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-17 18:18 -0400 |
| Message-ID | <20160317181833.4b90ca9148fbbb2cf4d2fe05@speakeasy.net> |
| In reply to | #8169 |
On Tue, 15 Mar 2016 15:41:29 +0000 (UTC) spud@potato.field wrote: > On Tue, 15 Mar 2016 10:11:17 -0400 > "James K. Lowden" <jklowden@speakeasy.net> wrote: > >On Tue, 15 Mar 2016 10:23:29 +0000 (UTC) > >spud@potato.field wrote: > > > >The demand is from experts. Granted, they're self-appointed, but > >they're also peer-reviewed: inexpert opinions don't travel far in > >that atmosphere. > > If by non-experts you mean programmers on the shop floor who use C++ > to do actual work rather than use it as an interesting academic > exercise in language design then you're probably right, I doubt the C+ > + committee listens to any of us. Half of all C++ programmers "on the shop floor" have a below-average understanding of the language. You would agree that below some percentile of expertise, you wouldn't want their vote. Let's call that the dividing point between experts and non. I'll accept any proportion you assert. Does the ISO process harm the language? Not from what I see. ANSI C is better than K&R C. ANSI C++ created an arbiter of what is and is not C++, and eventually cowed Microsoft into correcting the scope of "I" in "for( int i=-0;...)" "Now, by popular demand" is a terrible model. It's plausible that's what killed Perl. It's definitely what made such an ugly mess of SQL. Users -- the vast majorty, including their management -- didn't appreciate (still don't) the power of the underlying theory. What they wanted was speed and convenience. And vendors delivered! Over the decades SQL has changed quite a bit, but *never* in the direction of addressing acknowledged, well understood flaws in its definition of the relational model. There is a place in language development for academics and people with access to a wide variety of code bases. The academics provide the theory and hopefully prevent ambiguous or redundant constructions. Observation of code bases minimized incompatible changes. C++ has demonstrably benefitted from such people on the committee. > >That's not to say the committee perfectly represents its > >"constituency". C++ has substantially no support for reflection, and > > Reflection in a compiled language requires a lot of runtime baggage > to make it work. No thanks. It all depends what you mean. What *I* mean is to include in the compiled image -- as static data in a new namespace -- structures that describe the compiled program. I want all the data currently supplied to the debugger to be available to the program. No runtime overhead at all. A compiler switch could turn it off. > Concurrency should be the responsibility of the OS, not the language. No. The OS knows nothing of types. Everything is just a bag of bytes. There's no way to say a pipe or a file only takes objects of type X, no support from the compiler in filling or emptying the pipe. The compiler cannot opt to support the same logical separation more efficiently with threads. Compilers prevent errors. If you fix the definitions of "language" and "OS" in 1975, how do you ever progress? --jkl
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <nicolas$george@salle-s.org> |
|---|---|
| Date | 2016-03-17 23:01 +0000 |
| Message-ID | <56eb372c$0$3053$426a74cc@news.free.fr> |
| In reply to | #8180 |
"James K. Lowden" , dans le message <20160317181833.4b90ca9148fbbb2cf4d2fe05@speakeasy.net>, a écrit : > Half of all C++ programmers "on the shop floor" have a below-average > understanding of the language. And half of all statisticians have a below-average understanding of the difference between average and median.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web