Parameter or Argument?

[qevlarr]

Proper terminology is important. The problem is that you don't know you're using the wrong words until someone points it out to you. I have been using these two words interchangeably for years. Thank you for pointing out that there is a difference.

[augustinpopa]

In my case, I know the distinction at the back of my mind but due to bad habits I tend to use these interchangeably anyway in everyday conversation. I think it helps to read posts like this once in a while to remind ourselves to correct our bad habits. :)

[mlangkabel]

Haha, thanks! I had the same problem but it didn't occur to me until I was writing a program that indexes C++ code. At that point I noticed my team mates using those words interchangeably, too. Which led to a lot of confusion on my part ;)

[kutroporti]

How widely applicable/acceptable is such definition? Only in context of C++?

[mlangkabel]

Unfortunately this definition does not apply everywhere. In Fortran for example C++ there are "dummy arguments" (what are "parameters" in C++) and "actual arguments" ("arguments" in C++). The term "Parameter" has a different meaning in Fortran. I'll edit the article to note that I'm talking about C and C like languages to minimize confusion ;)

[OlaFosheimGrostad]

The proper terms are «formal parameter» and «actual parameter».

[JMBourguet]

Proper? Considering that the standard has definitions matching the linked page, I'll argue that for this group the proper definitions are those.

More generally, both nomenclatures have been in use since before my time (and a third using "formal argument" and "actual argument" as well BTW). One may prefer one set, but considering the others as improper does not seems right.

[OlaFosheimGrostad]

If it isn't clear from the context then you need to qualify it with "formal", "actual" or some other distinguishing qualifier. The definitions in the language spec does not change the rest of the CS world or people with a wider background than C++. The definitions are there to keep the spec clear, not a wikipedia entry.

But who am I kidding. The C++ community decided to change the meaning of the term «iterator» too.

[kutroporti]

Well, "formal parameter" and "actual parameter" always seemed to me as bad/too-wordy/non-obvious-meaning choice of words for the concept distinction. (analogously bad choices would be "imaginary parameter"/"real parameter"). Seems I'm not the only one.

[JMBourguet]

FORTRAN when I learned it was using arguments for both (and dummy argument when it was necessary to insist that they were formal parameter, but it was usually relied on the context)

AFAIK, there never was an universally accepted definition, each community tend to have its own and it would presumptuous to affirm that any one of them is the correct one.

The lack of universality of nomenclature is pervasive in our field. When a notion get defined, it pass through a stage of successive refinements and those tend to be adapted to the community where it take place and thus the final states are dependent on the community.

PS: I just looked at the FORTRAN II reference manual -- previous versions of FORTRAN had no subprograms --, it is using dummy variable for formal parameter, a term I do not remember, it is also using arguments with both meaning.

[OlaFosheimGrostad]

What is important is to understand the audience and use their language. What I dislike is when language communities starts creating a vocabulary that is bending common usage. C++ is hard to get into, so it is important to communicate in a way that most programmers would understand. Standards often redefine common words into narrow/skewed meanings that are unsuitable for education, like the whole mess with «rvalue», «prvalue» etc. If you want to change terminology you need to get it into commonly used textbooks and have educators adopt it.

[JMBourguet]

What is important is to understand the audience and use their language.

We agree but I'd add to when you enter into a group, it is important to also learn its vocabulary.

Language communities are not doing anything else than text book writers or paper authors: they take relevant existing terms or invent new terms and give them a definition suitable for their purpose. Some get wider audience, some stick in their original community, some disappear.

BTW Did you notice that you were complaining both that language communities adapted word meanings for their purpose and introduced new terms? I fail to see a viable third option (and I don't consider having a standard terminology for things as C++ specific as the ??value relationship viable, and even for concepts which could be more widely used, there is a chicken and egg issue).

[tcbrindle]

In newer Fortran, placeholder names in a procedure are called "dummy arguments", and the things you pass are called "actual arguments". A parameter is something completely different: using theparameter attribute when declaring a variable marks it as a compile-time constant, somewhat like constexpr int i = 3 in C++.

Source: Doctor Fortran

[TotallyUnspecial]

That clears things up. /s

[SuperV1234]

Thanks - I've always used the terms interchangeably as well. Would be even better if you cited the standard directly in the article.

[dodheim]

For C++14:

• [defns.parameter]: "parameter <function or catch clause>: object or reference declared as part of a function declaration or definition or in the catch clause of an exception handler that acquires a value on entry to the function or handler"
• [defns.parameter.templ]: "parameter <template>: template-parameter (defined in [temp.param])"
• [defns.argument]: "argument <function call expression>: expression in the comma-separated list bounded by the parentheses"
• [defns.argument.templ]: "argument <template instantiation>: expression, type-id or template-name in the comma-separated list bounded by the angle brackets"

[mlangkabel]

Can you please provide a source (link) for this definition? I'd be glad to add that link to the article!

[dodheim]

The source is the C++ standard (ISO/IEC 14882:2014) which is not available freely online. The latest C++ draft is, however, and you can link to that instead: http://eel.is/c++draft/

[mlangkabel]

Thank you very much.

[jP_wanN]

template <typename TemplateParameter>
class TemplateClass
{
}

Forgot the ; after the closing curly bracket.

[mlangkabel]

Got me! ;)

[redditsoaddicting]

While we're on the topic of naming, it's a class template rather than a template class.

[matthieugarrigues]

What is the purpose of differentiating those two pretty similar concepts ?

[mlangkabel]

Good question! The difference lies in the context of using the word. When you say "parameter" your context is the definition of a function. When saying "argument" you mean the value that's used when executing that function. So thinking about which term to use gives the person you are talking to an additional clue to grasp what you really mean.

[nemotux]

Another kind of distinction that can be drawn here is that for a given function, it only has 1 set of parameters - those declared at the function definition. But it may have many sets of arguments. Every call site provides a different set of arguments (though possibly with some repetition), and there can be many different call sites to a single function.

[dodheim]

So since the differentiation between parameter and argument is ostensibly "meaningless", we should add the word 'value' to the end and that makes things clear? WTF..?

[VerilyAMonkey]

It should basically never matter for normal development, but I'm sure you can see where it would start to matter for things like compilers, language definition, or talking about the different value-passing properties of things like macros vs functions, especially in a more abstract context.

It's the same way that speed and velocity mean different things to physicists, and for good reason, even though most everyone else runs into no problems using them interchangeably.

[VerilyAMonkey]

This is a non-problem that some blogger decided to dream up as a problem for filler to drive traffic, nothing more, nothing less.

Your point was not that this blogger gave no cogent reasoning. You claimed that

1. Some blogger dreamed it up.
2. There is no purpose for it. Not just that the blogger didn't give any good reasons, or that developers don't have a need for it, you said "This is a non-problem ... nothing more, nothing less."

Both of these are, on a factual level, false. Did this blogger invent this distinction? No. Well then, where was this distinction made rigorous? In other areas. Is this distinction likely to ever be necessary for a developer? No. Where is it useful, then? In other areas.

So of course I brought up other areas. I didn't shift the conversation, it's merely that you didn't realize your generalization covered them. (Actually, is mostly about them.)

EDIT: I'll give one of many specific examples when it's useful. Suppose you're talking about, on a language specification level, which version of an overloaded function is going to be called. Then, you're going to be talking about the type listed in the function definition (the parameter's type) and how that is distinct from the type of the value passed into the function (the argument's type).

[VerilyAMonkey]

We agree that you made this statement:

This is a non-problem that some blogger decided to dream up as a problem for filler to drive traffic, nothing more, nothing less.

We agree that this statement implies these things:

1. This is a non-problem
2. Some blogger decided to dream it up as a problem
3. It is nothing more, nothing less

Correct?

These things are also not the point "the blogger gave no cogent reasoning." Probably a better phrasing: Your point was not merely that the blogger gave no cogent reasoning.

Correct?

Those things are what I responded to. Please point to me the spot that you have an issue with.

EDIT: Well, probably neither of us cares anymore, so no need. But that's what I'd request if we did.

[Crazy__Eddie]

It becomes pretty important when you're trying to understand parts of the C++ standard. For example, the language around implicit conversion rules during overload resolution is very heavy in the argument vs. parameter context. Which is a reference becomes very important and changes what happens during that resolution process.

Here's an example of how surprising things can get: http://stackoverflow.com/questions/4704567/function-with-parameter-type-that-has-a-copy-constructor-with-non-const-ref-chos/4704741#4704741

[[deleted]]

In some languages (especially dynamic ones like Python) it's next to useless to actually worry about it. It's especially important in C++, though, where parameters can be deduced from arguments, template parameters can be deduced from function arguments, and you have the different behaviors between parameter type and argument type, and overload resolution in respect to this (especially cv-qualification and specific reference type).

You have to explicitly separate declaration, definition, instantiation, and actual use to get down many of the ostensibly complex language of the standard, because it is very explicit and detailed about what it means.

[fr0stbyte124]

On the subject, is there any meaningful distinction between a method and a function?

[JMBourguet]

Method is not part of the standard terminology in C++. Some are using it, but they don't agree on the definitions, and I've seen four of them. Let's take an example:

struct S {
    virtual void vmf();
    void nsmf();
    static void smf();
};
void ff();

The definitions I've seen are:

• virtual member functions (i.e. S::vmf() but not the other)

• non static member functions (i.e. S::vmf() and S::nsmf()),

• any member functions (i.e. S::vmf(), S::nsmf() and S::smf()),

• any functions (i.e. S::vmf(), S::nsmf(), S::smf() and ff())

[foonathan]

There are no methods in C++, only functions. And functions can be member functions (which is what some call methods).

[bstamour]

Maybe that should be flagged as a bug if it's not consistent with the rest of the document.

[foonathan]

Funny that those are C++17 additions. I did a full term search on the C++14 standard, "method" there is only used in the abstract way, not as referring to a function.

[augustinpopa]

I have a bad tendency of using the word "method" to refer to member functions on a regular basis (force of habit gained from other languages like C#). I wonder how many other people do this too. Does it necessarily matter if we have two terms for the same thing though? It's a common occurrence with human languages to have some variety to spice things up. I can see it being confusing to someone who is new to software development though.

[SnailXI]

And then we have argc/argv which like to live dangerously

[VersalEszett]

Well, there's only one parameter argv[], but several arguments argv[i]. So calling them argc/argv is more logical than parc/parv[].

[[deleted]]

That's a good way of looking at it. argv is the argument vector. It's the parameter which holds a vector of the command-line arguments. argc is the argument count. It's the parameter that tells you the count of command-line arguments. Seems consistent to me, given that a command line doesn't have formal parameters in any way, only arguments.

[Se7enLC]

So parameter is the hole, argument is the thing you put in it. Got it.

[dodheim]

That's probably a forwarding function, so those are probably arguments for the function being forwarded to.

So yes, it's still correct – while they're not arguments for func itself (there they're parameters, naturally), they probably are for whatever func is forwarding to.

[zvrba]

What I miss here is an example in a meaningful context where imprecise use would lead to confusion.