which tutorial to use?

[Mark McIntyre]

You mean, "an address is a special kind of value".

Pointers are special kind of variables that can store addresses.

No, as Richard pointed out.

NULL is a special-meaning pointer (address) value.

Question: if (as you assert) all pointers are variables, what is a "null
pointer constant"?

 

[Ian Collins]

And what is a variable ? The Standard doesn't define this term, and,
in fact, doesn't use it (except for rare examples or footnotes).
However, K&R2 heavily makes use of it, i found about 300 instances of
the strings "variable" and "variables".

So please, will you explain what do you mean by this term ?

A variable is something that can appear of the left hand side of an
assignment.

 

[Richard Heathfield]

Ioannis Vranos said:

You mean, "an address is a special kind of value".

No, I don't mean that.

Pointers are special kind of variables that can store addresses.

No, they aren't.

NULL is a special-meaning pointer (address) value.

It's a value. The water is slightly muddied by the fact that NULL can be
defined as 0 (which has integer type), but the more familiar ((void *)0)
makes it clear that NULL is a pointer.

Furthermore, functions don't return objects, but values, and functions can
return pointers. Therefore, pointers are values, not objects.

 

[Richard Heathfield]

candide said:

And what is a variable ?

Who knows?

The Standard doesn't define this term,

Right. It's perhaps best to think of it as a vernacular term for what the C
language describes as an "object".

So please, will you explain what do you mean by this term ?

I reflected the usage suggested by the tutorial on which I was commenting.
I rarely if ever use the term myself when discussing C, but on such
occasions as I do, I think of it as being synonymous with "object".

 

[Richard Heathfield]

Ian Collins said:

A variable is something that can appear of the left hand side of an
assignment.

Yeah, I keep wanting to say that too, but I'm put off by such statements
as:

p[42] = 6;

The 42 is on the left side of an assignment, so by that definition it's a
variable. So is the [, of course. And *p = *q; makes * a variable too. The
butcher makes a pertinent comment about this in Henry VI, Act IV scene ii.

 

[Bartc]

Ioannis Vranos said:


No. A pointer is a special kind of value. Objects of proper type can store
such values, but constants (e.g. NULL) can be pointers too.

Perhaps it might be better not to make too much of this sort of thing.

Concepts which have been perfectly obvious to C programmers for years
suddenly are in doubt when you bring up these subtle definitions.

End result: more confusion.

 

[Ioannis Vranos]

Furthermore, functions don't return objects, but values, and functions can
return pointers. Therefore, pointers are values, not objects.

Functions return temporary objects at least in C++. Consider the
following C++03/C95 example:


#include <stdio.h>


struct somestruct
{
int x, y;
};


struct somestruct somefunc(void)
{
struct somestruct x={0};

return x;
}



int main()
{

printf("%d %d\n", somefunc().x, somefunc().y);

return 0;
}


[john@localhost src]$ gcc -ansi -pedantic-errors -Wall main.c -o prog
[john@localhost src]$ ./prog
0 0
[john@localhost src]$



However the following compiles for C++03 but not for C95:


#include <stdio.h>


struct somestruct
{
int x, y;
};


struct somestruct somefunc(void)
{
struct somestruct x={0};

return x;
}



int main()
{
struct somestruct *p= &somefunc();

printf("%d %d\n", p->x, p->y);

return 0;
}

C++:

[john@localhost src]$ g++ -ansi -pedantic-errors -Wall main.cc -o
foobar-cpp
main.cc: In function ‘int main()’:
main.cc:21: warning: taking address of temporary
[john@localhost src]$ ./foobar-cpp
0 0
[john@localhost src]$



C95:

[john@localhost src]$ gcc -std=iso9899:199409 -pedantic-errors -Wall
main.c -o prog
main.c: In function ‘main’:
main.c:21: error: invalid lvalue in unary ‘&’
[john@localhost src]$

 

[Ian Collins]

Ian Collins said:

A variable is something that can appear of the left hand side of an
assignment.

Yeah, I keep wanting to say that too, but I'm put off by such statements
as:

p[42] = 6;

The 42 is on the left side of an assignment, so by that definition it's a
variable. So is the [, of course. And *p = *q; makes * a variable too.

But "p[42]" is.

 

[Ioannis Vranos]

Question: if (as you assert) all pointers are variables, what is a "null
pointer constant"?

What is a double constant?


Anyway, perhaps there is difference between C and C++ here. Functions in
C++ return temporary objects, but in C perhaps they return "values".

 

[Ioannis Vranos]

Functions return temporary objects at least in C++. Consider the
following C++03/C95 example:


#include <stdio.h>


struct somestruct
{
int x, y;
};


struct somestruct somefunc(void)
{
struct somestruct x={0};

return x;
}



int main()
{

printf("%d %d\n", somefunc().x, somefunc().y);

return 0;
}


[john@localhost src]$ gcc -ansi -pedantic-errors -Wall main.c -o prog
[john@localhost src]$ ./prog
0 0
[john@localhost src]$



However the following compiles for C++03 but not for C95:


#include <stdio.h>


struct somestruct
{
int x, y;
};


struct somestruct somefunc(void)
{
struct somestruct x={0};

return x;
}



int main()
{
struct somestruct *p= &somefunc();

printf("%d %d\n", p->x, p->y);

return 0;
}

C++:

[john@localhost src]$ g++ -ansi -pedantic-errors -Wall main.cc -o
foobar-cpp
main.cc: In function ‘int main()’:
main.cc:21: warning: taking address of temporary
[john@localhost src]$ ./foobar-cpp
0 0
[john@localhost src]$



C95:

[john@localhost src]$ gcc -std=iso9899:199409 -pedantic-errors -Wall
main.c -o prog
main.c: In function ‘main’:
main.c:21: error: invalid lvalue in unary ‘&’
[john@localhost src]$

More accurately, the following is *guaranteed* to work in C++ always.
const reference p points to the temporary object returned by the
function call, until the end of its scope, where the temporary object is
destroyed.


#include <stdio.h>


struct somestruct
{
int x, y;
};


struct somestruct somefunc(void)
{
struct somestruct x= {0};

return x;
}



int main()
{
const struct somestruct &p= somefunc();

printf("%d %d\n", p.x, p.y);

return 0;
}

 

[Richard Heathfield]

Ian Collins said:

Ian Collins said:

A variable is something that can appear of the left hand side of an
assignment.

Yeah, I keep wanting to say that too, but I'm put off by such statements
as:

p[42] = 6;

The 42 is on the left side of an assignment, so by that definition it's
a variable. So is the [, of course. And *p = *q; makes * a variable too.

But "p[42]" is.

Agreed. The problem is not that "something that can appear on the left of
an assignment" doesn't describe "variable" (or, as I prefer to call it,
"object"), but that it describes too many other things as well.

 

[Richard Heathfield]

Ioannis Vranos said:

What is a double constant?

3.14 is an example.

Note that doubles are not variables either. They are values.

Anyway, perhaps there is difference between C and C++ here. Functions in
C++ return temporary objects, but in C perhaps they return "values".

You'd best check this in comp.lang.c++ but, according to my reading of
ISO/IEC 14882:1998, C++ functions return the value of the expression
supplied to the return statement. See 6.6.3 for details. Nothing in there
about temporary objects.

 

[Richard Heathfield]

Ioannis Vranos said:

Functions return temporary objects at least in C++.

That may or may not be true. I suggest you check it in comp.lang.c++. But
in C, it is not true.

<snip>

 

[Richard Heathfield]

Bartc said:

Perhaps it might be better not to make too much of this sort of thing.

Concepts which have been perfectly obvious to C programmers for years
suddenly are in doubt when you bring up these subtle definitions.

End result: more confusion.

Personally, I think that, when you have to deal with the real world, the
truth is less confusing than made-up stuff.

YMMV.

 

[Keith Thompson]

You mean, "an address is a special kind of value".

Pointers are special kind of variables that can store addresses.

NULL is a special-meaning pointer (address) value.

It's fairly common to use the unqualified term "pointer" to refer to
an object of pointer type, and the term "address" to refer to a value
of pointer type (though I suppose a null pointer value isn't really an
address). It's a reasonable distinction, one that the quoted tutorial
apparently makes, but it's not one that the standard makes. See, for
example, C99 7.30.3.3p3:

The malloc function returns either a null pointer or a pointer to
the allocated space.

The second occurrence of the word "pointer" is clearly referring to a
pointer *value*, since there's no pointer object to which it could
refer.

To avoid confusion, I suggest avoiding the use of the word "pointer"
without qualification. Call an object of pointer type a "pointer
object", and a value of pointer type either a "pointer value" or an
"address". And be prepared for the fact that others will continue to
use the term ambiguously; you'll just have to glark the meaning from
context.

 

[Keith Thompson]

Ian Collins said:

A variable is something that can appear of the left hand side of an
assignment.

Yeah, I keep wanting to say that too, but I'm put off by such statements
as:

p[42] = 6;

The 42 is on the left side of an assignment, so by that definition it's a
variable. So is the [, of course. And *p = *q; makes * a variable too. The
butcher makes a pertinent comment about this in Henry VI, Act IV scene ii.

The obvious fix is to say that a variable is something that can appear
as the left operand of an assignment operator.

Of course the standard doesn't define the term, so there are a variety
of possible definitions. IMHO saying that it's synonymous with
"object" is too broad. I'd say that, at the least, any declared
object (i.e., not an array element or struct or union member, and not
something allocated dynamically) that isn't const-qualified is a
"variable". I'll use the word "variable" informally for such objects.
As for other objects, maybe they're variables and maybe they're not,
but I'll just call them objects.

 

[Keith Thompson]

Perhaps it might be better not to make too much of this sort of thing.

Concepts which have been perfectly obvious to C programmers for years
suddenly are in doubt when you bring up these subtle definitions.

End result: more confusion.

There's no real ambiguity in the underlying concepts. Objects and
values are clearly different things, and we don't have much trouble
distinguishing between, an object of type int (say, i) and a value of
type int (say, 42 -- you knew I'd pick 42, didn't you?). Even if we
look at ``i'' as an object vs. ``i'' as an expression (that evaluates
to the current value of the object ``i'', which happens to be 42) most
don't have much trouble keeping things straight.

Similarly, there's no real problem distinguishing between an object of
pointer type (say, p) and a value of pointer type (say, &i or
(void*)0). I think the only reason there's any confusion in this area
is that the unqualified phrase "a pointer" is used by some people only
to refer to an object of pointer type, and by others (and by the
standard) to refer to a value of pointer type.

The confusion is unfortunate, but it's really not that hard to avoid.

 

[Jean-Marc Bourguet]

candide said:


Who knows?


Right. It's perhaps best to think of it as a vernacular term for what the C
language describes as an "object".

The definition I use is that a variable is a *named* object.

Yours,

 

[Jean-Marc Bourguet]

A variable is something that can appear of the left hand side of an
assignment.

That's the original meaning of lvalue. Then standardization came in and
blurred the issue (most notably const was added and so the notion of
modiable lvalue, does someone remember or can check in K&R1 if arrays were
lvalue there?)

Note that there are things I consider variable which can't appear at the
left hand side of an assignement:

int const foo = 42;

foo = 43;

Yours,

 

[Bartc]

There's no real ambiguity in the underlying concepts. Objects and
values are clearly different things, and we don't have much trouble
distinguishing between, an object of type int (say, i) and a value of
type int (say, 42 -- you knew I'd pick 42, didn't you?). Even if we
look at ``i'' as an object vs. ``i'' as an expression (that evaluates
to the current value of the object ``i'', which happens to be 42) most
don't have much trouble keeping things straight.

You can also say that 'i' itself is just the 'name' of the object, so is
neither a value nor object.

Crudely, 'i' refers to the address of the object, and has type int* in this
case.

Some magic in the compiler automatically dereferences these names for you,
while &i will cancel that dereference and give you the underlying int*
value.

This would be clearer if C had proper constants, so that in Const int j=43;
'j' is a synonym for the value 43.

My point: it's best to think about this stuff too much. Best to just think
of variables as little boxes to store values, while values can also be
floating around unconfined.

Similarly, there's no real problem distinguishing between an object of
pointer type (say, p) and a value of pointer type (say, &i or
(void*)0). I think the only reason there's any confusion in this area
is that the unqualified phrase "a pointer" is used by some people only
to refer to an object of pointer type, and by others (and by the
standard) to refer to a value of pointer type.

In the tutorial in question (http://crasseux.com/books/ctutorial/) it
seemed to call pointer values 'addresses', and pointer variables 'pointers'.
That seems fair enough, and may have been done deliberately to avoid
confusion.