Creating a variable inside a function arguments

[Anmol444]

In the following code:

#include <iostream>                              // For stream I/O
using namespace std;

int function(int a)
{
	return a;
}

int main()
{
	function(int b);
}

Why is creating a variable inside the function argument list not allowed. Any reason other then for the language syntax or just for the language syntax?

[Bourgond Aries]

int f(int a)
{
    return a;
}
int main()
{
    f(int(32));
    //return 0; // Can be omitted
}

This compiles fine for me. Would it make sense to give the variable (temporary) a name?

[Anmol444]

Same, I guess giving it a name gives a error, but why?

[Bourgond Aries]

Perhaps because there is no logical reason to give it a name, I mean, can you access it in any way?

[Anmol444]

I guess you could access it if it had a name, it just wont let you?

[Bourgond Aries]

But would it not be confined to the function call scope?

[Anmol444]

Oh maybe that is, but you are not defining it in the function, just the function call, and the function call is in a bigger block in which it should be accessible.

But I believe you are correct because that is the only logical reason behind it.

[Anmol444]

But why would it be confined to the function call scope?

Does the function call even have its on scope? lol

[Anmol444]

Can anyone please answer why it would be confined in the function call scope?

[naraku9333]

@Bourgond Aries
f(int(32)); You are casting 32 to an int and passing it to the function, this isn't the same as what Anmol444s code is doing.

@Anmol444
function(int b); Is invalid because it would probably be parsed as a function definition which isn't allowed within another function. It also doesn't make sense to pass a temporary uninitialized variable to a function.

[MikeyBoy]

@Anmol444

In addition to what others have said... what purpose would it serve to add the ability do create a local named variable within a function call? What would it allow you to do that you can't do already?

C and C++ already provide you with many, many ways to write horrible, obfuscated code by cramming many operations into a small amount of text. Do we really need one more?

@naraku9333

It also doesn't make sense to pass a temporary uninitialized variable to a function.

For basic types, it doesn't make sense. For a class that has a constructor that initializes it, it might be meaningful. Which is not to say that I think it would be a good thing :)

[andywestken]

I'm with MikeyBoy -- I don't see the point of this syntax for function calls.

function(int b);// function call

What do expect it to do?

If it was possible, b in unititialized in your example, and the trivial case

function(int b = 3); // set b to 3, call function with b (= 3)l

would be the same as

function(3);

and a less trivial case

function(int b = 2 * other_funct(5));

the same as

function(2 * other_funct(5));

So I really don't see why the syntax is needed (or is needed to be valid).

As it stands, when you have a function declared as int f(int a);, when you call it, the parameter (a in this case) is set to the contents of the brackets (similarly for other parameters, it present). And a is at function scode, unless it's a reference parameter. So doesn't that do what you require?

And function(int b = 3); still looks like a function declaration to the compiler (one which is missing it's return type). But now the parameter b has a default value.

And, while function definitions aren't allowed at function scope, forward declarations are.

#include <iostream> // For stream I/O
using namespace std;

int main()
{
    int times_two(int b = 2); // forward declaration

    cout << times_two() << endl;
    cout << times_two(3) << endl;

    return 0;
}

int times_two(int a /*= 2*/)
{
    return 2 * a;
}

It's not something I've seen very ofter outside of examples. But it is a way of controlling which functions can use another one.

Andy

[ETAkoG1T]

why would you ever want to declare something inside of the function call? :)

[Anmol444]

Alright makes sense, there is no need to declare it inside. Thanks

[ne555]

> It also doesn't make sense to pass a temporary uninitialized variable to a function.
>> For basic types, it doesn't make sense.
>> For a class that has a constructor that initializes it, it might be meaningful.
If the constructor initializes it, then it is not uninitialized.

[Anmol444]

@ne555
You could initialize it then xD with a = and a value on the right side.
Yea it doesnt make much sense, also if it was allowed would it be confined in the function call scope?
Why for a class?

[MikeyBoy]

Well, OK, yes, but the pont is that that syntax could have been meaningful if Stroustrup had decided to allow it, even if it would only have been meaningful for types with default constructors.

It's still probably for the best that he didn't, IMHO, if only because it looks too similar to a function declaration.

[Anmol444]

Yea I guess that makes sense, I shall just leave it at that, just asking though, if it was allowed with the current rules, would it be confined to the function call scope?

Also it couldn't be a function declaration if the function is already defined/declared above.

[MikeyBoy]

if it was allowed with the current rules, would it be confined to the function call scope?

*Shrug* That would depend entirely on what those people with responsibility for defining the standards decided.

[Anmol444]

And does a function call have a "scope"?