tutorials

[osmium]

From this, heathfield says I do not explain the difference between passing
by value and passing by address. That is just bad faith, only to be had
from a PEDANT. "Argument" and "parameter" are using interchangeably in
common day language.

I agree, they are used interchangeably by a lot of people, but this is a
problem. They are in fact different things, and even though they blur in
many people's minds, they are different, and a writer of technical documents
*must* keep them straight. Personally, I find it almost impossible to get
something right all by myself, anything serious must be checked by at least
one co-worker. And he must be *told* he is not an expensive spell checker,
otherwise you just get a bottom feeder.

 

[Beej Jorgensen]

"Argument" and "parameter" are using interchangeably in common day
language.

In your defense, they're defined somewhat interchangeably in C89 (as
"formal argument/parameter" and "actual argument/parameter"). In
Heathfield's defense, that interchangeablity is deprecated in C99 even
if you stick to specifying "formal" or "actual".

Personally, I think it's good to have a few strict pedants running
around. Occasionally I have to grit my teeth at some of the things that
are said, but in general they keep people honest. Of course, it's
important to keep a healthy batch of non-pedants around, too, to keep
things friendly to newcomers and act as foils.

-Beej

 

[Nick Keighley]

[stuff about lcc-win32]

Your web site specifies no restrictions on who can download from it,
except for specifying that a license is required for non-commercial use.

"for commercial use" surely?

On what grounds do you deny that he has a right to download them? You
might want to modify your web site to say that "downloading for the
purpose of critiquing this software is strictly prohibited", or whatever
wording you think most accurately conveys your objection.

"downloading is permitted to everyone except Richard Heathfield"

<snip>

 

[Nick Keighley]

"Richard Heathfield"  wrote:

If that doesn't desribe a vendetta, WTF does?

Vendetta \Ven*det"ta\, n. [It.]
1. A blood feud; private revenge for the murder of a kinsman.
[1913 Webster]

2. Any feud or contention that is bitter and prolonged;
however, the deep enmity may be held by only one party to
the dispute; as, the former Mayor nurtured a lifelong
vendetta against the candidate who defeated him.
[PJC]

I would suggest that Jacob fix the parameter/argument thing,  I can't get
very worked up about the other things.

strange! I had the opposite reaction- the parameter/argument thing
seemed
nit-picky and I really can't see how this nice distinction is required
to understand call by value! Language Lawyering it looks to me.

I don't spend all my waking hours obsessing about this stuff, but as I
semi-interested bystander, I thought the vast majority of compilers are not
C compilers by the standards you apply to him.  I know my compiler allows //
comments but if I tried to use the built in complex numbers, I am quite sure
it would barf.  So it is not a C compiler, QED.

I think Richard's Criterion is over harsh. Jocob's compiler is so damn
close
to complianc eit might as well be called a C compiler.

I do find it odd he is so wrigglyin this area. Why not a compliance
statement?

"LCC Win is a conforming implementaion of the 1999 ISO C Standard with
the following exceptions..."

I think even GCC do this


--
Klingon Programming Rules

7. Klingon function calls do not have 'parameters'
- they have 'arguments'
-- and they ALWAYS WIN THEM.

 

[Nick Keighley]

So no different to most google searches then.

well worse than normal I think. There seems to be a real dearth of
decent teaching material for C on the web.

I did check beforehand and there seems to be quite a bit of useful material
out there. Unless you're a discerning connoisseur such as RHe of course then
you might be harder to please.

Usually google definitely isn't my friend and I would not suggest it, but
the amount of C programming material around is huge enough that even google
can hardly miss it. (A lot of it is pretty old though.)

old, and crap.

writing C tutorials seems to be one of things people think will be
easy
but judgeing by the results is not at all easy.

 

[Nick Keighley]

This is not true since the download is without any charge for the user
This is another attempt by heathfield to misrepresent lcc-win.

there *is* (or used to be) a charge for commercial use of the lcc-
win32
compiler.
This isn't a criticism merely a fact.

Sure sure, and heathfield is not a c programmer.
This is just not true

I'm sympathetic with Jacob on this. It's an almost-compliant C
compiler
(nice to know which bits were not compliant though...).

Avoid sarcasm, Jacob, you're no good at it.

Contrary to heathfield, I do not say:

"This book is the best of the best, The first and final stop for all
your readings"

Richard never said that

This is not true

which bit?

You have no right to download or use my book, nor my compiler.

I thought it was a free to download?


<snip>

 

[James Kuyper]

[stuff about lcc-win32]

Your web site specifies no restrictions on who can download from it,
except for specifying that a license is required for non-commercial use.

"for commercial use" surely?

Sorry - typo!

"downloading is permitted to everyone except Richard Heathfield"

Do you think he'd be any happier to have someone other than Richard
Heathfield download the material and publicly criticize it? I can't
remember ever seeing a calm response to criticism from Jacob - though
that may just be because his other responses are so noticeable that they
blot out the memory of the calm ones. I would guess that the idiot
Teapot chose his pseudonym to refer to the "tempest in a teapot" that he
finds so easy to trigger in Jacob.

 

[Dik T. Winter]

> The distinction between "parameter" and "argument" is one that has
> indeed been blurred over time, and it's unfortunate because
> maintaining a clear distinction does have clear exegetic benefits.

I think that distinguishing them is more recent than blurring them. I have
a Fortran reference from about 1977 where the disctinction is between
"actual argument" and "formal argument". And in the Algol 60 reference
(1964) they are called "actual parameter" and "formal parameter".

 

[BartC]

...

I think that distinguishing them is more recent than blurring them. I
have
a Fortran reference from about 1977 where the disctinction is between
"actual argument" and "formal argument". And in the Algol 60 reference
(1964) they are called "actual parameter" and "formal parameter".

Yes that's what I normally use; argument and parameter are interchangeable.

Trying to assign specific meanings to them, in the context of a beginner's C
tutorial, sounds a waste of time; much better to keep such things informal.

 

[Keith Thompson]

I think that distinguishing them is more recent than blurring them. I have
a Fortran reference from about 1977 where the disctinction is between
"actual argument" and "formal argument". And in the Algol 60 reference
(1964) they are called "actual parameter" and "formal parameter".

The terminology has changed over time and from one programming
language to another. The distinction, and the importance of making
it, has not.

 

[Ben Bacarisse]

Yes that's what I normally use; argument and parameter are
interchangeable.

But note that the distinction is still made but using extra words.
The complaint was that the distinction was blurred. Exactly what
words a writer chooses to explain the calling mechanism is not really
important. I doubt RH would have written what he did had JN written
about actual arguments and formal arguments.

Trying to assign specific meanings to them, in the context of a
beginner's C tutorial, sounds a waste of time; much better to keep
such things informal.

The trick is to keep things clear and accurate with being wordy. The
modern usage does that better than the old one. You don't need formal
definitions since people pick up on definition by usage. For example:

"Here is a function with a single parameter called p:

int f(int p) { return p * p; }

When a function is called, the arguments you supply are used to
initialise the function's parameters. For example, in the call
f(x+3), the value of the argument expression is used to initialise
the function's sole parameter, p."

I think this sort of thing is more confusing when the distinction is
lost.

 

[Keith Thompson]

Yes that's what I normally use; argument and parameter are interchangeable.

Trying to assign specific meanings to them, in the context of a
beginner's C tutorial, sounds a waste of time; much better to keep
such things informal.

I absolutely disagree. A beginner's tutorial is exactly where it's
most important to make a clear distinction. You don't have to use the
terms "argument" and "parameter"; you can use "actual parameter" and
"formal parameter" if you like. But since the C standard uses the
terms "argument" and "parameter", using the same terms in a tutorial
is easier and less likely to lead to future confusion.

Here's an example I posted earlier in this thread:

#include <stdio.h>

void func(int x)
{
printf("x = %d\n", x);
x ++;
}

int main(void)
{
int x = 42;
func(x);
printf("x = %d\n", x);
return 0;
}

How do you distinguish between the x that appears as a subexpression
in the function call and the x declared in func? How would you
explain the distinction to a beginner if you use the same term for
both? "The value of the parameter x is copied to the parameter x"?

 

[Beej Jorgensen]

Here's a curiosity: "The absence of a zero byte in a string is fatal
for any C program." But that's nonsense, because the absence of a
zero byte in a string is *impossible*.

I'd argue that his presentation is good for teaching, though.

"Why did strlen crash?"
"You didn't pass it a string."

Compare to:

"Why did strlen crash?"
"You don't have a '\0' on the end of the string."

Sure, you could get all Socratic with the first example, but it's a long
way to go for the same answer with limited room for additional learning
in the middle (other than the reiteration of the definition of a
string.) The user is calling strlen(); the user already "knows" the
argument is a string.

In any case, free accuracy feedback is a gift and has some serious
value (especially given the surprising number of defects that make it
into a large document, no matter how well-edited.)

Note to JN: just fix the little crap and maybe you'll even get an
endorsement out of these guys. You might feel like they're picking on
you, but you spent all that time on that document and you might as well
make it as correct as you can.

There can be absolutely valid reasons for inexactitude or incompleteness
(sometimes being exact destroys clarity), but in most cases repairs can
be made without hassle or loss.

-Beej

 

[Beej Jorgensen]

it may be helpful [...] to refer to arguments as ARGUMENT EXPRESSIONS,
as the word "expression" helps us to remember that we're not passing
objects to the function - we're just passing the results of evaluating
expressions.

I really like this approach, moreso than my example demonstration of
passing a constant and a variable with a different name than the
parameter. And then combining it with the idea of assignment into
parameters helps hammer it home:

argument expression Bar + Baz is evaluated and the resulting value
is stored in m. The argument expression Quux is evaluated and the
resulting value is stored in n.

The key points you've made, IMO, are:

1. The arguments are expressions
2. The arguments are evaluated before the function is called
3. The results of the argument evaluation are assigned to the parameters

Keith described the most confusing situation earlier when the argument
name is the same as that of the parameter, and I think what you have is
a good approach to sidestepping that issue. (It's a false issue--it
shouldn't exist when described in the right light. The fact that it
persists shows how difficult it is to obtain that "right light"!)

The casual use of the word "passed" is probably also confusing to
beginners. They understand assignment--but is this something else like
some kind of magical reference passing? One sentence could clarify
that.

It is not intended to be harsh.

It being perceived as harsh is entirely a bonus...?

-Beej

 

[Beej Jorgensen]

Trying to assign specific meanings to them, in the context of a
beginner's C tutorial, sounds a waste of time; much better to keep such
things informal.

No one likes informality more than I do, but this is a case where one
can be exact with no particular loss. There's no gain here in playing
fast-and-loose, especially when so many people already think of the
terms interchangeably--you might as well say "parameter" when that's
what you mean.

I do, however, agree that simply stressing that "these are arguments,
and these are parameters" is not particular useful or vital information
on its own, and fixating on the details of the definitions can be
counter-productive. It's the behavior that's important, and it would
not surprise me one bit to find C programmers who are 100% clear on the
distinction between arguments and parameters without knowing the
difference between the two terms.

-Beej

 

[jameskuyper]

Yes that's what I normally use; argument and parameter are interchangeable.

That's a workable alternative, but only so long as you remember to use
the "actual" / "formal" distinction to keep track of the difference.

Trying to assign specific meanings to them, in the context of a beginner's C
tutorial, sounds a waste of time; much better to keep such things informal.

I thin it's beginners who need most strongly that distinction made.
Experienced programmers will usually be able to figure out what you
meant, even if you don't use quite the right words.

 

[Keith Thompson]

No one likes informality more than I do, but this is a case where one
can be exact with no particular loss. There's no gain here in playing
fast-and-loose, especially when so many people already think of the
terms interchangeably--you might as well say "parameter" when that's
what you mean.

I do, however, agree that simply stressing that "these are arguments,
and these are parameters" is not particular useful or vital information
on its own, and fixating on the details of the definitions can be
counter-productive. It's the behavior that's important, and it would
not surprise me one bit to find C programmers who are 100% clear on the
distinction between arguments and parameters without knowing the
difference between the two terms.

I think you'd agree that it's important to distinguish between the
expression that appears in a function call and the local object that
appears in the function declaration. Given that it's an important
distinction (especially in C with its pass-by-value semantics where
changes in the latter don't affect the former), why not use the same
terminology used by the standard to explain that distinction?

I just can't think of any valid reason, in a C tutorial, *not* to use
the terms "argument" and "parameter" consistently and correctly.

And I'm sure there are plenty of C programmers who understand the
distinction without necessarily knowing the correct terms. Surely
they'd benefit from learning the correct terms.

The point is that I disagree with your assertion that

... simply stressing that "these are arguments, and these are
parameters" is not particular useful or vital information ...

In my opinion, it's both useful and vital.

Now you *could* use different terminology, like "actual parameters"
and "formal parameters", but why? It might be worth mentioning the
alternatives in a footnote.

 

[Beej Jorgensen]

No one likes informality more than I do, but this is a case where one
can be exact with no particular loss. There's no gain here in playing
fast-and-loose, especially when so many people already think of the
terms interchangeably--you might as well say "parameter" when that's
what you mean.

I think you'd agree that it's important to distinguish between the
expression that appears in a function call and the local object that
appears in the function declaration. Given that it's an important
distinction (especially in C with its pass-by-value semantics where
changes in the latter don't affect the former), why not use the same
terminology used by the standard to explain that distinction?

I don't think we're so far off from one another in the above paragraphs.
In this case, like I said, I can't see any drawback to using the proper
terminology.

I just can't think of any valid reason, in a C tutorial, *not* to use
the terms "argument" and "parameter" consistently and correctly.

Me either.

The point is that I disagree with your assertion that

... simply stressing that "these are arguments, and these are
parameters" is not particular useful or vital information ...

I also disagree with that assertion... but that's not my assertion.

In my assertion I had appended "on its own". I'm saying that simply
nitpicking the definition for its own sake is not something that's
useful to a newbie. For example, no amount of clarification of
"parameter" and "argument" will help solve this problem:

"When I pass the parameter y to sqrt(), I get a domain error."

If you want to use the definition to clarify a point, then I'd say the
definition becomes useful and/or vital.

(And this should NOT be construed as an argument for using the terms
interchangeably in a tutorial.)

It might be worth mentioning the alternatives in a footnote.

Agreed, especially considering common and historic usage. This is
perfect sidebar material.

-Beej

 

[BartC]

I absolutely disagree. A beginner's tutorial is exactly where it's

void func(int x)
{
}

int x = 42;
func(x);

How do you distinguish between the x that appears as a subexpression
in the function call and the x declared in func? How would you
explain the distinction to a beginner if you use the same term for
both? "The value of the parameter x is copied to the parameter x"?

"The value of the argument x" doesn't sound right either. The argument is
the value of x, not x. This is where you can get tied up in knots. Best to
change the example to use different names for the formal parameter and the
local variables of the caller.

I will admit that googling for ""keyword arguments"" gets more than double
the number of hits than ""keyword parameters"", but I also admit I've never
really thought about it up to now, using mainly "parameter" for both.
Either: context will tell you whether formal or actual parameters or
arguments are being talked about, or "formal"/"actual" qualifiers can be
used.

And this common example:

int main(int argc, char *argv[]) { ... }

does suggest argument/parameters are interchangeable; inside the function
argc and argv should be parameters, not arguments.

 

[lawrence.jones]

And this common example:

int main(int argc, char *argv[]) { ... }

does suggest argument/parameters are interchangeable; inside the function
argc and argv should be parameters, not arguments.

They are, but argc is the parameter that contains the number of command
line arguments (which has nothing to do with the number of function
parameters) and argv is the parameter that contains the values of those
command line arguments, so the names simply represent their contents.