I know that there is no Call by reference in C language.
but, Some people say that there is a Call by reference in C.
I'm confused.
As far as I know, when handing over the factor to the function in C, I know that the value transferred to the function is received by making a local copy as a parameter.
However, in C++, "Call by reference" is possible because "the same element that differs only from the factor and name" is created by the reference "&". Is that true?
I know that there is no Call by reference in C language.
Correct. C always passes by value.
Some people say that there is a Call by reference in C. I'm confused.
They are wrong. This is very easy to test.
Let's start by looking at this small Perl program.
use 5.014;
sub f {
$_[0] = 456; # $_[0] is the first argument.
}
my $x = 123;
f( $x );
say $x; # 456
Changing the parameter changed the argument. This is an example of pass by reference. Perl arguments are passed by reference.
Now let's do the same thing in C.
#include <stdio.h>
void f( int x ) {
x = 456;
}
int main( void ) {
int x = 123;
f( x );
printf( "%d\n", x ); // 123
}
Changing the parameter had no effect on the argument. This is an example of pass by value. C's arguments are passed by value.
You can use pointers to achieve a similar result.
#include <stdio.h>
void f( int *xp ) {
*xp = 456;
}
int main( void ) {
int x = 123;
f( &x );
printf( "%d\n", x ); // 456
}
Note that the argument (the pointer) is still passed by value. Changing xp itself (as opposed to *xp) has no effect on the caller.
Same goes for arrays. The degenerate into a pointer which is passed by value.
#include <stdio.h>
void f( char a[] ) {
a = "def";
}
int main( void ) {
char a[] = "abc";
f( a );
printf( "%s\n", a ); // abc
}
This could be called passing a reference. It is not passing by reference, however.
However, in C++, "Call by reference" is possible
Correct.
C++ normally uses pass by value.
#include <iostream>
using namespace std;
void f( int x ) {
x = 456;
}
int main( void ) {
int x = 123;
f( x );
cout << x << endl; // 123
}
But pass by reference can be requested using &.
#include <iostream>
using namespace std;
void f( int &x ) {
x = 456;
}
int main( void ) {
int x = 123;
f( x );
cout << x << endl; // 456
}
I know that there is no Call by reference in C language. but, Some people say that there is a Call by reference in C. I'm confused.
Your confusion is, I'm afraid, inevitable, but it's not your fault.
People have been arguing about this question for a long time. (There's an FAQ list entry on the question that dates to the 1990's.) I didn't realize it was still a matter of debate, but evidently it is, because the same confusion you've experienced has been repeated (which is to say, validated) in the answers posted right here on this Stack Overflow question, where you hoped you'd get a definitive answer.
Depending on how you define your terms, all of the following statements are more or less true:
C does not have pass by reference. C always passes arguments by value.
C lets you simulate pass by reference, by passing a pointer instead. But the pointer is passed by value.
Arrays in C are passed by reference, because the array reference in the function call decays into a pointer to the array's first element. (But the pointer is passed by value.)
C++ has reference parameters, meaning that the programmer doesn't have to explicitly use the & operator in the call, or the * operator in the function. (But the implementation of that reference involves something very much like a pointer which is, again, passed by value.)
Or, in other words, for a sufficiently formal and restrictive definition of the term "pass by reference", C does not have it. But it has a couple of things that are pretty close, perhaps close enough to satisfy a less-formal definition, or to let you say, "You can get something a lot like call-by-reference in C, if you want."
C sometimes appears to pass by reference. The detail is that the argument goes through automatic conversions and that argument is passed by value. The effect is that the original argument experiences a pass-by-reference.
When an argument is a function, it may look/act like it is pass by reference. Functions are converted to the address of a function. The function sqrt is not passed by value. foo() receives the address of the function as a function pointer.
foo(sqrt);
An array looks like it is passed by reference in that bar() does not receive the value of the array. What happened under the table is that the array is converted to the type and address of the first element and bar() receives a pointer to a char. bar() may do things that change s[], exactly what pass by refence does in other languages, yet in C there is a technical under-the-table conversion that maintains the idea of pass only by value.
char s[1];
bar(s);
I know that there is no Call by reference in C language. but, Some
people say that there is a Call by reference in C. I'm confused.
The traditional definition of "pass by reference" is an aspect of subprogram calling semantics providing that the subprogram's parameters are bound to the same objects that are designated by the caller as the corresponding subprogram arguments.1,2 This has the effect that if the subprogram modifies the object identified by one of its parameters, including by assignment, then the caller can observe that modification (provided that the caller retains a way to examine that object). This is the typical implementation of Fortran's call semantics, among others.
For example, consider a program of this form (expressed in a polyglot pseudocode):
subprogram sub1(x)
x = 0
end
integer a
a = 42
call sub1(a)
print(a)
In a language with pass-by-reference semantics, the assignment to x in sub1 will modify the value of a in the caller, with the result that the program prints "0".
Pass-by-value is the main alternative: the names of subprogram parameters are not bound to the objects specified by the caller. They are instead bound to different objects with (initially) the same values as those presented by the caller. In a language with pass-by-value semantics, a program such as the above would be expected to print "42", as the subprogram's parameter x refers to a different object than the caller's a, therefore the subprogram's assignment to x is not visible to the caller.
As far as I know, when handing over the factor to the function in C, I
know that the value transferred to the function is received by making
a local copy as a parameter.
Yes, this is mandated by the C language specification:
An argument may be an expression of any complete object type. In
preparing for the call to a function, the arguments are evaluated, and
each parameter is assigned the value of the corresponding argument.
(C17 6.5.2.2/4; emphasis added)
As judged via the definitions above, this is unequivocally pass-by-value in all cases. However, there are a couple of cases that require special attention in this context:
One can pass the address of an object to a function -- for example, by means of the unary & operator. In that case, the function can modify the pointed-to object via the pointer it receives. Some people are inclined to characterize this as pass-by-reference, but it does not satisfy the definition above, because the argument was never the pointed-to object in the first place. Moreover, assignment to the received pointer itself does not modify the argument presented by the caller or the object to which it points.
The arguments presented by the caller are the results of evaluating the expressions presented, and C has some cases where the effect of that may be surprising to the uninitiated, especially
functions. Wherever the name of a function appears in a valid expression that is evaluated, it is automatically converted to a pointer.3 In particular, when the name of a function appears in the argument list of a function call, the corresponding parameter receives a pointer to the function. The called function can use that pointer to call the function it points to, even if that function's identifier is not in scope. But the function has not been passed by reference (by the above definition), for if the called function assigns a new value to the parameter, that does not modify the function it originally pointed to (nor the caller's copy of the function pointer, if it retains one).
arrays. C specifies that with only a few, narrow exceptions, expressions of array type are automatically converted to pointers. I think it's fair and consistent to describe that as the result of evaluating a (sub)expression of array type being a pointer to the first element of the array. The argument lists to function calls are no exception, so when you specify an array as a function argument, the corresponding function parameter receives a pointer to the first array element.
As a result, the called function can modify the array's elements via the pointer it receives. Some people describe that effect as the array having been passed by reference, but it doesn't actually satisfy the above definition. The parameter doesn't even have the same type as the caller's array, and moreover, if you assign a new value to the parameter itself then the effect is visible only in the function. In this sense, modifying array elements via a pointer received as a parameter is analogous to calling a function via a function pointer received as a parameter.
However, in C++, "Call by reference" is possible because "the same
element that differs only from the factor and name" is created by the
reference "&". Is that true?
Yes, one of the things that C++ has that C does not is references, and one of the major uses of references is providing pass-by-reference semantics that satisfy the above definition. It's not quite pass-by-reference in the Fortran sense because the parameter has a different type than the corresponding argument, but for most purposes, the parameter can be used in the same ways, and with the same effects, as the argument to which it is bound. In particular, assignment to a reference does affect the referenced object.
C++ references have some additional properties that differentiate them from pointers, among them:
A reference can be created only from another, valid object, either as a reference to that object or, if that object is itself a reference, as a copy of that reference (referring to the same object).
References cannot be rebound to different objects.
These play well with using C++ references for pass-by-reference.
Until now I have grounded my discussion in the definition given above, but it will be clear from the answers and comments given that there is a controversy here over whether that remains an appropriate definition. Some claim that the language has moved on, and in particular that in the context of C, the term "pass by reference" has become accepted as including passing a pointer. To be sure, some do use the term that way. On the other hand, "accepted" is clearly too strong a term, because plenty of others, including some voicing their opinions here, insist that it is is imprecise, sloppy, or simply wrong to describe passing a pointer to an object as passing that object by reference.
One thing to consider here is that the conventional meaning of these terms in context of most programming languages other than C has not appreciably moved from the traditional ones, even for much younger languages. C++ in particular is relevant because of the shared history and strong interoperability of these, and no C++ programmer would characterize passing a pointer as pass by reference. But the terminology is also well established in Java, which has only pass by value, including passing references by value, but not pass by reference. It also comes up in Python, which is like Java but more so, because all argument passing there is passing references by value. The distinction is important for explaining the semantics of those languages, as indeed it is for C, too.
Therefore, at present, if
you are engaging in comparative analysis of computer languages,
you want to express your ideas with maximum precision, or
you want to avoid, in many cases, earning a point of disrespect from a portion of your audience
then you will avoid conflating passing pointers with pass by reference. But if you do conflate the two then you can reasonably expect to be understood, at least in C-specific context.
1 Wikipedia definition
2 Strongly supported Stack Overflow definition
3 Including in their most common context, function calls: "The expression that denotes the called function shall have type pointer to function" (C17 6.5.2.2/1).
But, Some people say that there is a Call by reference in C. I'm confused.
This depends on how you define the term "call by reference":
Three years ago, I worked for a company in the automotive industry:
Pointer arguments that were pointing to a (single) variable (and not to an array) of the type someType were neither defined as "arguments of the type someType *" nor as "pointers to a someType" but as "'call by reference' arguments of the type someType".
You could also see this at the "[out]" or "[inout]" tag in the doxygen comments:
/*! \brief Example function (non-AUTOSAR)
* \param[in] foo Value of the "foo" force
* \param[out] bar Value of the "bar" speed
* \param[inout] foobar Current value of the "foobar" state
* \return True if calculating "bar" succeeded */
bool someFunction(someType foo, someType * bar, someType * foobar)
{
...
}
Microsoft's documentation of the Windows API seems to see this in a similar way - for example here:
BOOL GetExitCodeProcess(
[in] HANDLE hProcess,
[out] LPDWORD lpExitCode
);
“Pass by reference”1 is an old computer programming phrase that antedates the “reference” feature built into C++. It means providing a pointer to an object. The C standard says a pointer “provides a reference” (C 2018 6.2.5 20). References can be provided either manually by a programmer writing some explicit notation or by a feature built into a programming language.
When C++ developers named a new feature a “reference,” that did not change the prior usage of the term. When discussing “passing by reference” in languages other than C++ or others that provide built-in references, the phrase has its classic meaning.
C supports passing by reference (manually) but does not provide it as a built-in feature, except to the extent that arrays and functions undergo automatic conversions and adjustments that effect passing by reference. Programmers understand from context that “pass by reference” refers to passing a pointer in C and passing a built-in reference type in C++.
Footnote
1 The question uses the phrase “call by reference,” but this is an imprecise use of terminology. Whether we are discussing C++ or C, the issue is how arguments are passed, not how functions are called.
In C, all function arguments are passed by value, meaning each argument expression in the function call is fully evaluated and the result of that evaluation is passed to the function:
#include <stdio.h>
void swap( int a, int b )
{
int tmp = a;
a = b;
b = tmp;
}
int main( void )
{
int x = 10, y = 10;
printf( "Before swap: x = %d, y = %d\n" );
swap( x, y );
printf( " After swap: x = %d, y = %d\n" );
return 0;
}
The formal parameters a and b in the definition of swap are different objects in memory from the actual parameters x and y in main. The expressions x and y are fully evaluated, and the results of those evaluations (the values 10 and 20) are copied to a and b. Changing the values of a and b has no effect on x or y, and the output of the program will be
Before swap: x = 10, y = 20
After swap: x = 10, y = 20
We can fake pass-by-reference semantics by passing pointer values:
#include <stdio.h>
void swap( int *a, int *b )
{
int tmp = *a;
*a = *b;
*b = tmp;
}
int main( void )
{
int x = 10, y = 10;
printf( "Before swap: x = %d, y = %d\n" );
swap( &x, &y );
printf( " After swap: x = %d, y = %d\n" );
return 0;
}
Instead of passing the values of x and y, we're passing the results of the expressions &x and &y, which evaluate to the addresses of x and y.
a and b are still separate objects in memory from x and y, but instead of receiving the values of x (10) and y (20), they receive the addresses of x and y.
The expressions *a and *b can kinda-sorta be thought of as aliases for x and y, such that writing a new value to *a is the same as writing a new value to x and writing a new value to *b is the same as writing a new value to y. But this is not true pass-by-reference - it's passing pointers by value and manually dereferencing the pointers. The output of this program will be
Before swap: x = 10, y = 20
After swap: x = 20, y = 10
Switching to C++:
#include <iostream>
void swap( int &a, int &b )
{
int tmp = a;
a = b;
b = tmp;
}
int main( void )
{
int x = 10, y = 20;
std::cout << "Before swap: x = " << x << ", y = " << y << std::endl;
swap( x, y );
std::cout << " After swap: x = " << x << ", y = " << y << std::endl;
return 0;
}
The parameter declarations int &a and int &b declare a and b as references - a and b are not separate objects in memory, but rather they are alternate names or aliases for the objects designated by x and y1. You do not need to explicitly dereference a or b in the C++ code the way you have to in the C code. Like the second C example, the output will be:
Before swap: x = 10, y = 20
After swap: x = 20, y = 10
Logically speaking, anyway - the compiler may be using pointers under the hood to accomplish this, but that's hidden from you. As far as the behavior of the code is concerned, a and b are not independent objects from x and y.
Suppose we declare a variable
int i = 10;
And we have these 2 statements-
printf("%d",i);
printf("%d",*(&i));
These two statements print the same value, i.e. 10
From my understanding of pointers, not just their output is same, but the above two statements mean exactly the same. They are just two different ways of writing the same statement.
However, I came across an interesting code-
#include <stdio.h>
int main(){
const int i = 10;
int* pt1 = &i;
*pt1 = 20;
printf("%d\n", i);
printf("%d\n", *(&i));
return 0;
}
To my surprise, the result is-
10
20
This suggests that i and *(&i) don't mean the same if i is declared with the const qualifier. Can anyone explain?
The behavior of *pt1 = 20; is not defined by the C standard, because pt1 has been improperly set to point to the const int i. C 2018 6.7.3 says:
If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined…
Because of this, the behavior of the entire program is not defined by the C standard.
In C code with defined behavior, *(&i) is defined to produce the value of i. However, in code with behavior not defined by the C standard, the normal rules that would apply to *(&i) are canceled. It could produce the value that the const i was initialized to, it could produce the value the program attempted to change i to, it could produce some other value, it could cause the program to crash, or it could cause other behavior.
Think of what it means to declare something as const - you're telling the compiler you don't want the value of i to change, and that it should flag any code that has an expression like i = 20.
However, you're going behind the compiler's back and trying to change the value of i indirectly through pt1. The behavior of this action is undefined - the language standard places no requirements on the compiler or the runtime environment to handle this situation in any particular way. The code is erroneous and you should not expect a meaningful result.
One possible explanation (of many) for this result is that the i in the first printf statement was replaced with the constant 10. After all, you promised that the value of i would never change, so the compiler is allowed to make that optimization.
But since you take the address of i, storage must be allocated for it somewhere, and in this case it apparently allocated storage in a writable segment (const does not mean "put this in read-only memory"), so the update through pt1 was successful. The compiler actually evaluates the expression *(&i) to retrieve the current value of i, rather than replacing it with a constant. On a different platform, or in a different program, or in a different build of the same program, you may get a different result.
The moral of this story is "don't do that". Don't attempt to modify a const object through a non-const expression.
This code prints 5 even though I am not returning anything in m().
#include <stdio.h>
int abc();
int main(){
printf("%d", m());
}
int abc(){
return 5;
}
void m(){
abc();
}
The function is void as well. So can someone explain why 5 is being printed?
It is common in C implementations for functions to return a value by placing the value in a processor register designated for that value. So what can happen is:
To return 5, abc puts 5 in that register.
Since m does not return a value, it does not change the register.
When main attempts to get the return value of m, it reads the register where the return value should be. Since abc put 5 there and m did not change it, main gets 5 and prints it.
None of the above is guaranteed by the C standard, and it is easily disrupted when a compiler performs optimization, so it is not behavior you can rely on in any way.
That said, a C implementation of any quality would report that there are conflicting types for m, because its use in main either:
causes an implicit declaration of a function returning int, and its explicit declaration later on conflicts with that (for versions of C before 1999 and non-standard versions of C), or
is a use of an undeclared function name which is not allowed (by later C standards).
From the point of view of the C standard, your code invokes undefined behavior (you're calling a function using a different type signature than the one with which it was defined) and could produce any possible output (or crash or otherwise act unexpectedly).
From the point of view of the implementation, ints are presumably returned via a register on your platform / calling convention. So abc puts its value into that register. m does not touch that register because m is void and does not return anything. main then looks into the register to find the return value of m (because main thinks m is an int function) and finds the 5 there.
I just stumbled upon a behavior which surprised me:
When writing:
int x = x+1;
in a C/C++-program (or even more complex expression involving the newly created variable x) my gcc/g++ compiles without errors. In the above case X is 1 afterwards. Note that there is no variable x in scope by a previous declaration.
So I'd like to know whether this is correct behaviour (and even might be useful in some situation) or just a parser pecularity with my gcc version or gcc in general.
BTW: The following does not work:
int x++;
With the expression:
int x = x + 1;
the variable x comes into existence at the = sign, which is why you can use it on the right hand side. By "comes into existence", I mean the variable exists but has yet to be assigned a value by the initialiser part.
However, unless you're initialising a variable with static storage duration (e.g., outside of a function), it's undefined behaviour since the x that comes into existence has an arbitrary value.
C++03 has this to say:
The point of declaration for a name is immediately after its complete declarator (clause 8) and before its initializer (if any) ...
Example:
int x = 12;
{ int x = x; }
Here the second x is initialized with its own (indeterminate) value.
That second case there is pretty much what you have in your question.
It's not, it's undefined behavior.
You're using an uninitialized variable - x. You get 1 out of pure luck, anything could happen.
FYI, in MSVS I get a warning:
Warning 1 warning C4700: uninitialized local variable 'i' used
Also, at run-time, I get an exception, so it's definitely not safe.
int x = x + 1;
is basically
int x;
x = x + 1;
You have just been lucky to have 0 in x.
int x++;
however is not possible in C++ at a parser level! The previous could be parsed but was semantically wrong. The second one can't even be parsed.
In the first case you simply use the value already at the place in memory where the variable is. In your case this seems to be zero, but it can be anything. Using such a construct is a recipe for disaster and hard to find bugs in the future.
For the second case, it's simply a syntax error. You can not mix an expression with a variable declaration like that.
The variable is defined from the "=" on, so it is valid and when it is globally defined, it is initialized as zero, so in that case it is defined behavior, in others the variable was unintialized as as such still is unitialized (but increased with 1).
Remark that it still is not very sane or useful code.
3.3.1 Point of declaration 1 The point of declaration for a name is immediately after its complete declarator (clause 8) and before its
initializer (if any), except as noted below. [ Example: int x = 12; {
int x = x; } Here the second x is initialized with its own
(indeterminate) value. —end example ]
The above states so and should have indeterminate value, You are lucky with 1.
Your code has two possiblities:
If x is a local variable, you have undefined behavior, since you use the value of an object before its lifetime begins.
If x has static or thread-local lifetime, it is pre-initialized to zero, and your static initialization will reliably set it to 1. This is well-defined.
You may also wish to read my answer that covers related cases, including variables of other types, and variables which are written to before their initialization is completed
This is undefined behaviour and the compiler should at least to issue a warning. Try to compile using g++ -ansi .... The second example is just a syntax error.
If dot_product is declared as
float dot_product(const float* restrict a, const float* restrict b, unsigned n);
would calling it with
dot_product(x, x, x_len)
be "undefined", according to the C99 standard?
Edit
x is a pointer, of course, pointing to sizeof(float) * x_len bytes of memory, x_len is unsigned. This question is about aliasing.
I do not have the original C99 (that is, ISO9899:1999) text; I only have a copy of ISO9899:2007:TC3. I expect this text, taken from page 111 of that document, is very similar to the text in the C99 standard.
6.7.3.1 Formal definition of restrict
...
10. EXAMPLE 3
The function parameter declarations
void h(int n, int * restrict p, int * restrict q, int * restrict r)
{
int i;
for (i = 0; i < n; i++)
p[i] = q[i] + r[i];
}
illustrate how an unmodified object can be aliased through two restricted
pointers. In particular, if a and b are disjoint arrays, a call of the form
h(100, a, b, b) has defined behavior, because array b is not modified within
function h.
This seems to clearly call out functions of the form you asked about as having defined behavior, provided the aliased pointers are used for read-only access. Writing through either of the aliased pointers would invoke undefined behavior.
First I don't think that the call itself is UB, UB can only occur inside the function, if the pointers that are passed as parameters are used in a way that conflicts with the specification of restrict. (UB makes not much sense for the call, if that (w/sh)ould be forbidden, this should have been made a constraint violation and not UB.)
Then, UB related to restrict can only appear, if the pointed to object is modified "in any way". So as long as your vectors aren't modified, everything is fine. Inside your function this shouldn't happen, because of the const qualification. And if something outside (say a different thread or a signal handler) modifies your vectors, you are screwed, anyhow.
Yes. It will invoke undefined behavior.
If the restrict keyword is used and the function is declared as :
float dot_product(const float* restrict a, const float* restrict b, unsigned n);
then the compiler is allowed to assume that a and b point to different locations and updating one pointer will not affect the other pointers. The programmer, not the compiler, is responsible for ensuring that the pointers do not point to identical locations.
Since your function call is
dot_product(x, x, x_len)
which is passing the same pointer x to the function, updating any of a or b will affect other causing undefined behavior.