From: jklowden@speakeasy.net
On Sat, 14 Apr 2012 11:29:31 -0700 (PDT)
Christopher Creutzig wrote:
> > Dave Abrahams suggests that the this pointer in e.g. list::sort()
> > can be thought of as an i/o parameter in some sense. Down that road
> > lies a long computer science debate that I didn't mean to engage.
>
> But both semantically and from an optimization point of view, his
> argument makes perfect sense. Pointer/reference is just an
> implementation detail when it comes to â??this,â?_ and the syntactic
> sugar of not having to provide this pointer/reference as an argument
> to the function makes code more readable, but does not really change
> anything beyond that.
Recall the OP suggested parameters should have syntax denoting their
i/o status (as apparently Ada has). Things like list::sort() and ++i
have no parameters. Would you suggest adding syntax to them?
I'm not saying anything about optimization, which doesn't interest me.
Far more than better compilers, faster execution derives from better
programs, which come from better programmers, who express their logic
to themselves and to other programmers in source code. The language
serves express logic to the humans first, and to the computer only
secondarily. Were that not true, C++ would never have been invented;
we would all be programming in machine code.
Your point IIUC is that things like list::sort looks something like
qsort(3) under the hood. That's not relevant to the question of i/o
parameters per se. My point was and is that C++ syntax makes the use
of i/o parameters unnecessary in most cases.
> > I would guess parameters are declared 90% by value, 9%
> > output, and 1% i/o. That's what I meant by "rarely used".
>
> Since I don't follow the way you are counting, it is not surprising
> that my guesstimates are very different from yours. To me, modifying
> operations take in/out parameters â?? the jury is still out on
> assignment operators,
(Your message arrives at my computer with a header indicating it's
encoded as Windows-1252, but iconv(1) recognizes it as utf-8.)
Well, clearly if we're talking about different things, we're apt to
have different conclusions about them.
I didn't intend to get into the theory because it's not my strength,
but since you raise the subject of assignment, it seems I have to
explain where I'm coming from for you to make sense of what I'm
saying.
As you may know, there's a body of CS research that says assignment and
functions are fundamental, and that side-effects interfere with both
cognition and optimization. I haven't studied it in detail, but I know
in my own experience -- and, I bet, you in yours -- programs are easier
to understand when the data move basically right-to-left. (I hold
operator>> in std::iostreams as an exception that doesn't contradict
the rule of single output. Maybe Stroustrup's disk was located
somewhere to the left of the caps lock key.)
Functions that have two effects -- a result on the left and an output
among the parameters -- are harder to reason about. Certainly to the
extent we embrace centuries of algebraic notation, we're bound to reap
its benefits.
The trend in computer languages is also toward functions and away from
pass-by-reference. In Fortran everything was by reference.
Classically:
SUBROUTINE F ( I )
I = I + 1
END
CALL F(3)
3 is now 4.
By contrast, the functional approach has brought us languages like
Haskell, in which all calls are by value and even variables don't
vary.
Aside: if lazy evaluation were added to C++, could Haskell programs be
written purely in terms of C++ constructors?
I never said i/o parameters can't be used or should be prohibited by
the language. I said they are rarely used and, with the exception of
low-level buffer manipulation, rarely justified. I hope my meaning and
reasoning are now clear.
--jkl
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
